为什么需要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的增加而增加。