本文主要整理一下与k8s-service资源相关联的面试题，不足之处望各位大佬多多补充...
1. 简述kube-proxy的作用
kube-proxy运行在所有节点上，它监听apiserver中service和endpoint的变化情况，创建路由规则以提供服务IP和负载均衡功能。其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
2. 简述kube-proxy的工作原理
kube-proxy主要有两个版本的实现：基于iptables的k8s1.2版本 和 基于 ipvs的k8s1.8版本。
1）kube-proxy iptables原理
k8s1.2 版本将iptables作为kube-proxy的默认模式。iptables模式下的kube-proxy不再起到Proxy的作用，其核心功能：通过API Server的Watch接口实时跟踪Service与Endpoint的变更信息，并更新对应的iptables规则，Client的请求流量则通过iptables的NAT机制“直接路由”到目标Pod。
2）kube-proxy ipvs原理
- IPVS在k8s 1.8版本中引入，并在k8s 1.11中升级为GA稳定版；
- IPVS则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张，因此被kube-proxy采纳为最新模式；
- 在IPVS模式下，使用iptables的扩展ipset，而不是直接调用iptables来生成规则链，可以大大减少iptables规则的数量，减少性能损耗。【iptables规则链是一个线性的数据结构，ipset是带索引的数据结构，因此当规则很多时，也可以很高效地查找和匹配】；
3）ipvs和iptables的异同
- 共同点：都是基于Netfilter实现
- 不同点：iptables是为防火墙而设计的；ipvs则专门用于高性能负载均衡，并使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。
- ipvs的优势：
- 为大型集群提供了更好的可扩展性和性能；
- 支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；
- 支持服务器健康检查和连接重试等功能；
- 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。
3. Service如何与Pod相关联？
标签选择器
4. Service有哪几种类型？
- ClusterIP：表示service仅供集群内部使用，默认使用【ClusterIP + Ingress接入外部流量】；
- NodePort：表示service可对外访问，会在每个节点暴露一个端口，通过【节点IP：NodePort】连接service；
- LoadBalancer：表示service可对外访问，一般在公有云环境下配置，需要外部云厂商的支持；
- ExternalName：这种类型的service会把集群外部的服务引入集群内部，这样集群内直接访问service就可以间接的使用集群外部服务；
5. Pod与Service是如何通信的？
1）k8s在创建服务时为服务分配一个虚拟IP，客户端通过该IP访问服务，服务则负责将请求转发到后端Pod上；
2）Service是通过kube-proxy服务进程实现，该进程在每个Node上均运行可以看作一个透明代理兼负载均衡器；
3）对每个TCP类型Service，kube-proxy都会在本地Node上建立一个SocketServer来负责接受请求，然后均匀发送到后端Pod默认采用Round Robin负载均衡算法；
4）Service的Cluster IP与NodePort等概念是kube-proxy通过Iptables的NAT转换实现，kube-proxy进程动态创建与Service相关的Iptables规则；
5）kube-proxy通过查询和监听API Server中Service与Endpoints的变化来实现其主要功能，包括为新创建的Service打开一个本地代理对象，接收请求针对针对发生变化的Service列表，kube-proxy会逐个处理；
6. 简述Kubernetes Service分发后端的策略
Service负载分发的策略有：RoundRobin和SessionAffinity
- RoundRobin：默认为轮询模式，即轮询将请求转发到后端的各个Pod上。
- SessionAffinity：基于客户端IP地址进行会话保持的模式，即第1次将某个客户端发起的请求转发到后端的某个Pod上，之后从相同的客户端发起的请求都将被转发到后端相同的Pod上。
7. 简述service,endpoints,kube-proxy三者的关系service：service是一种为一组功能相同的pod提供单一不变的接入点的资源。
service被建立后，其IP和端口不会改变，这样外部的客户端（也可以是集群内部的客户端）通过service的IP和端口来建立链接，这些链接会被路由到提供该服务的任意一个pod上。通过这样的方式，客户端不需要知道每个单独提供服务的pod地址，这样pod就可以在集群中随时被创建或销毁。
endpoint：service维护一个叫endpoint的资源列表，endpoint资源对象保存着service关联的pod的ip和端口。
- 当有pod删除时：endpoints controller会从service关联的endpoint列表中对应pod的ip:port;
- 当有pod加入时: endpoints controller 会将该pod的ip:port加入到service关联的endpoint列表；
kube-proxy：运行在node节点上，在Node节点上实现Pod网络代理，维护iptables和负载均衡工作。
kube-proxy是Service的透明代理兼负载均衡器。kube-proxy会监听api-service以获取service和endpoints的变化情况，创建并维护路由规则以提供服务IP和负载均衡功能，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
)
