Kubernetes Service工作原理分析
Kubernetes Service工作原理分析
为什么需要Service？
我们的Pod通常会由Deployment进行管理，而Pod的IP是不固定的，另外我们一个服务通常会有多个Pod，在多个Pod之间进行负载均衡也是一个很正常的需求，因为上述两个原因，从而诞生了Service。
什么是Endpoint？
在Service的资源清单文件，我们通常会定义selector，被selector选中的Pod，则被称之为Service的Endpoint。
kubectl get endpoints -n application-test
如上图，可以看到endpoint就是Pod的IP加端口，但这里的Pod是有一定要求的，这里的Pod状态必须是Running状态，且redinessProbe检查通过。
Service的具体实现原理？
Service的具体实现主要依赖kube-proxy组件和iptables共同实现，下面我会以我们的一个具体服务来进行讲解：
kubectl get svc -n application-test
当我们创建上述的Service时，Kubernetes会通过Service的Informer感知到一个Service对象的添加，Kubernets会在集群的主机上增加一条路由表规则，内容如下：
-A KUBE-SERVICES -d 172.20.56.180/32 -p tcp -m comment --comment "application-test/xxxx-internal cluster IP" -m tcp --dport 80 -j KUBE-SVC-2EMIR6LPM5AZ4JMB
上述规则的含义是，凡是目的地址172.20.56.180且目的端口是80的IP包都会被转到KUBE-SVC-2EMIR6LPM5AZ4JMB的iptables链进行处理，172.20.56.180只是集群的ClusertIP，通过该IP我们可以访问到该Service选中的Pod，上述规则可以通过以下命令获取到：
iptables -t nat -S
可以看到红框中的部分就是我们的xxxx-internal service创建的路由规则。
KUBE-SVC-2EMIR6LPM5AZ4JMB作用是？
KUBE-SVC-2EMIR6LPM5AZ4JMB是一组规则的集合，我们可以通过以下命令看一下这组规则：
iptables -t nat -S | grep ' KUBE-SVC-2EMIR6LPM5AZ4JMB'
可以看到红框中的部分就是这个规则集合，该规则集合其实是一组随机模式（--mode random）的iptables链，而这组iptables链转发的目的是KUBE-SEP-GOEEZVEMW3QWTC5O和KUBE-SEP-CN2K35O3DNJ5KDGR，这两条链其实就是最终的两个Pod，由于iptables规则匹配是自上而下匹配的，为了保证每条规则被选中的几率（负载均衡），因此在在第一条规则中我们通过--probability 0.5指定其被选中的几率是50%，第一条规则没有选中以后，由于我们只剩下一条规则因此必须设置为1，这里没有设置默认为1。
KUBE-SEP-GOEEZVEMW3QWTC5O作用？
我们在看一下规则集中其中一条规则（另一条规则类似），获取命令如下：
iptables -t nat -S | grep 'KUBE-SEP-GOEEZVEMW3QWTC5O'
iptables -t nat -S | grep "\-A KUBE-MARK-MASQ"
在上图中我们可以看到一个DNAT规则，该规则的作用就是在PREROUTING检查点之前（也就是在路由之前）将流入的IP包的目的地址和端口改成–to-destination所指定的新的目的地址和端口，该新的目的地址和端口即Pod的IP和端口，通过这样的操作，访问Service的VIP最后变成了访问具体的Pod的IP包了。
上述工作模式的缺点？
通过上述分析我们可以看出，kube-proxy通过iptables处理Service的过程实际上就是通过在宿主机上设置iptables规则来实现，当然为了保证这些iptables规则的正确性，kube-proxy需要在控制循环里面不断的刷新这些规则以确保其正确性，因此随着宿主机Pod大量增加的时候，会有大量的iptables规则被刷新，会占用宿主机大量的CPU资源。
为了解决上述模式的缺点，Kubernetes会通过IPVS模式来支持，该模式的开启需要为kube-proxy设置–proxy-mode=ipvs来进行开启。
谈谈IPVS模式的Service
由于作者本人的集群中的Pod并没有达到很大的量，因此线上集群并没有开启IPVS，所以有些参数来源于网络，如果大家有线上集群采用该模式的话可以互相交流，下文的描述中如果有问题的也可私信我进行更正。
ipvs模式下，kube-proxy会在宿主机上创建一个虚拟网卡（kube-ipvs0），并为他分配Service IP作为IP地址：
# ip addr
73：kube-ipvs0：<BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
link/ether 1a:ce:f5:5f:c1:4d brd ff:ff:ff:ff:ff:ff
inet 10.0.1.175/32 scope global kube-ipvs0
valid_lft forever preferred_lft forever
接下来kube-proxy会通过Linux的IPVS模块，为这个IP地址设置三个IPVS虚拟主机，并为这三个虚拟主机之间设置使用轮询模式（rr）进行访问，通过ipvsadm可以查看：
# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 10.102.128.4:80 rr
-> 10.244.3.6:9376 Masq 1 0 0
-> 10.244.1.7:9376 Masq 1 0 0
-> 10.244.2.3:9376 Masq 1 0 0
三个虚拟机主机的IP地址和端口对应的是被代理的三个Pod，因此任何一个被转往Service的请求最终都会被发到对应的一个Pod上。
IPVS并不需要在宿主机上为每个Pod设置 iptables规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低了维护这些规则的代价。IPVS只负责负载均衡和代理，没办法进行包过滤、SNAT等操作，这些无法进行的操作还是依赖iptables，但是这些iptables规则数量有限，不会随着Pod的增加而增加。