Kubernetes Service原理解析

Service 是为一组具有相同功能的Pod提供一个统一的入口地址，并将请求进行负载均衡地分发到各个Pod上。

Service 类型

ClusterIP

ClusterIP类型的Service是Kubernetes集群默认的Service, 它只能用于集群内部通信。不能用于外部通信。K8s会为每个Service分配一个虚拟IP，即ClusterIP。这个虚拟IP只能在集群内部访问。

clusterIP.png

NodePort

。NodePort类型的Service会在集群内部的所有Node节点打开一个指定的端口。之后所有的流量直接发送到这个端口之后，就会转发的Service去对真实的服务进行访问。

nodeport.png

LoadBalancer

LoadBalancer类型的Service通常和云厂商的LB结合一起使用，用于将集群内部的服务暴露到外网，云厂商的LoadBalancer会给用户分配一个IP,之后通过该IP的流量会转发到你的Service。

loadbalancer.png

Ingress

Ingress 其实不是Service的一个类型，但是它可以作用于多个Service，作为集群内部服务的入口。Ingress 能做许多不同的事，比如根据不同的路由，将请求转发到不同的Service上等等。

ingress.png

Service 服务发现的方式

虽然Service解决了Pod的服务发现问题，但不提前知道Service的IP，怎么发现service服务呢？k8s提供了两种方式进行服务发现：

• 环境变量： 当创建一个Pod的时候，kubelet会在该Pod中注入集群内所有Service的相关环境变量。需要注意的是，要想一个Pod中注入某个Service的环境变量，则必须Service要先比该Pod创建。这一点，几乎使得这种方式进行服务发现不可用。
• DNS：可以在集群中部署CoreDNS服务(旧版本的kubernetes集群使用的是kubeDNS)， 来达到集群内部的Pod通过DNS的方式进行集群内部各个服务之间的通讯。

服务发现原理

Endpoint

endpoint是k8s集群中的一个资源对象，存储在etcd中，用来记录一个service对应的所有pod的访问地址。service配置selector，endpoint controller才会自动创建对应的endpoint对象；否则，不会生成endpoint对象。
例如，k8s集群中创建一个名为k8s-classic-1113-d3的service，就会生成一个同名的endpoint对象，如下图所示。其中ENDPOINTS就是service关联的pod的ip地址和端口。

endpoint.png

endpoint controller是k8s集群控制器的其中一个组件，其功能如下：

• 负责生成和维护所有endpoint对象的控制器
• 负责监听service和对应pod的变化
• 监听到service被删除，则删除和该service同名的endpoint对象
• 监听到新的service被创建，则根据新建service信息获取相关pod列表，然后创建对应endpoint对象
• 监听到service被更新，则根据更新后的service信息获取相关pod列表，然后更新对应endpoint对象
• 监听到pod事件，则更新对应的service的endpoint对象，将podIp记录到endpoint中

负载均衡

kube-proxy负责service的实现，即实现了k8s内部从pod到service和外部从node port到service的访问。
kube-proxy作为一个控制器，作为k8s和Linux kernel Netfilter交互的一个枢纽。监听kubernetes集群Services和Endpoints对象的变化，并根据kube-proxy不同的模式(iptables or ipvs), 对内核设置不同的规则，来实现路由转发。

如果kube-proxy采用iptables的方式配置负载均衡，基于iptables的kube-proxy的主要职责包括两大块：一块是侦听service更新事件，并更新service相关的iptables规则，一块是侦听endpoint更新事件，更新endpoint相关的iptables规则（如 KUBE-SVC-链中的规则），然后将包请求转入endpoint对应的Pod。如果某个service尚没有Pod创建，那么针对此service的请求将会被drop掉。

iptable的使用

在Iptables模式下，kube-proxy通过在目标node节点上的Iptables中的NAT表的PREROUTIN和POSTROUTING链中创建一系列的自定义链(这些自定义链主要是”KUBE-SERVICE”链， “KUBE-POSTROUTING”链，每个服务对应的”KUBE-SVC-XXXXXX”链和”KUBE-SEP-XXXX”链)，然后通过这些自定义链对流经到该Node的数据包做DNAT和SNAT操作从而实现路由，负载均衡和地址转化。

NAT（Network Address Translation，网络地址转换）是将IP 数据包头中的IP 地址转换为另一个IP 地址的过程。SNAT: Source Network Address Translation，是修改网络包源ip地址的。DNAT: Destination Network Address Translation,是修改网络包目的ip地址的。

kube-proxy中，客户端的请求数据包在Iptables规则中具体的匹配过程为:

1. PREROUTING链或者OUTPUT链(集群内的Pod通过clusterIP访问Service时经过OUTPUT链， 而当集群外主机通过NodePort方式访问Service时，通过PREROUTING链，两个链都会跳转到KUBE-SERVICE链)

2. KUBE-SERVICES链(每一个Service所暴露的每一个端口在KUBE-SERVICES链中都会对应一条相应的规则，当Service的数量达到一定规模时，KUBE-SERVICES链中的规则的数据将会非常的大，而Iptables在进行查找匹配时是线性查找，这将耗费很长时间,时间复杂度O(n))。

3. KUBE-SVC-XXXXX链 (在KUBE-SVC-XXXXX链中(后面那串 hash 值由 Service 的虚 IP 生成)，会以一定的概率匹配下面的某一条规则执行，通过statistic模块为每个后端设置权重，已实现负载均衡的目的，每个KUBE-SEP-XXXXX链代表Service后面的一个具体的Pod(后面那串 hash 值由后端 Pod 实际 IP 生成),这样便实现了负载均衡的目的)

4. KUBE-SEP-XXXX链 (通过DNAT，将数据包的目的IP修改为服务端的Pod IP)

通过上面的这个设置便实现了基于Iptables实现了负载均衡。但是Iptbles做负载均衡存在一些问题:

• 规则线性匹配时延: KUBE-SERVICES链挂了一长串KUBE-SVC-*链,访问每个service,要遍历每条链直到匹配，时间复杂度O(N)
• 规则更新时延: 非增量式,需要先iptables-save拷贝Iptables状态，然后再更新部分规则，最后再通过 iptables-restore写入到内核。当规则数到达一定程度时，这个过程就会变得非常缓慢。
• 可扩展性: 当系统存在大量的Iptables规则链时，增加/删除规则会出现kernel lock,这时只能等待。
• 可用性: 服务扩容/缩容时， Iptables规则的刷新会导致连接断开，服务不可用。

更多iptable的实现，请参考：https://xigang.github.io/2019/07/21/kubernetes-service/

为了解决Iptables当前存在的这些问题，华为开源团队的同学为社区贡献了IPVS模式。请参考：https://xigang.github.io/2019/07/21/kubernetes-service/

参考文章

• https://zhuanlan.zhihu.com/p/39909011
• https://xigang.github.io/2019/07/21/kubernetes-service/