kube-proxy的三种代理模式

前言

Service是k8s中资源的一种，也是k8s能够实现减少运维工作量，甚至免运维的关键点，我们公司的运维都要把服务搭在我们集群里，接触过的人应该都能体会到其方便之处。Service能将pod的变化屏蔽在集群内部，同时提供负载均衡的能力，自动将请求流量分布到后端的pod，这一功能的实现靠的就是kube-proxy的流量代理，一共有三种模式，userspace、iptables以及ipvs。

1、userspace

网上的图是这样的：

没大理解，自己画的一下：

1、为每个service在node上打开一个随机端口（代理端口）

2、建立iptables规则，将clusterip的请求重定向到代理端口

3、到达代理端口（用户空间）的请求再由kubeproxy转发到后端pod。

这里为什么需要建iptables规则，因为kube-proxy 监听的端口在用户空间，所以需要一层 iptables 把访问服务的连接重定向给 kube-proxy 服务，这里就存在内核态到用户态的切换，代价很大，因此就有了iptables。

2、iptables

这里以我们集群的iptables规则为例介绍数据包的迁移规则：

PREROUTING和OUTPUT两个检查点：即入链和出链都会路由到KUBE-SERVICE这个全局链中

接着我们可以看下这个全局链的路由过程，这里只筛选部分规则说明：

1、-A KUBE-SERVICES -d 10.96.0.1/32 -p tcp -m comment --comment "default/kubernetes:https cluster IP" -m tcp --dport 443 -j KUBE-SVC-NPX46M4PTMTKRN6Y

2、-A KUBE-SVC-NPX46M4PTMTKRN6Y -m comment --comment "default/kubernetes:https" -m recent --rcheck --seconds 10800 --reap --name KUBE-SEP-VFX5D4HWHAGOXYCD --mask 255.255.255.255 --rsource -j KUBE-SEP-VFX5D4HWHAGOXYCD

3、-A KUBE-SEP-VFX5D4HWHAGOXYCD -p tcp -m comment --comment "default/kubernetes:https" -m recent --set --name KUBE-SEP-VFX5D4HWHAGOXYCD --mask 255.255.255.255 --rsource -m tcp -j DNAT --to-destination 172.22.44.62:6443

10.96.0.1为clusterip，发往目的地为clusterip的数据包会被转发由KUBE-SVC-NPX46M4PTMTKRN6Y规则处理，接着我们依次找下去，可以看到最后路由到了172.22.44.62:6443，这就是后端的pod服务的对应ip:port。

不同于userspace，iptables由kube-proxy动态的管理，kube-proxy不再负责转发，数据包的走向完全由iptables规则决定，这样的过程不存在内核态到用户态的切换，效率明显会高很多。但是随着service的增加，iptables规则会不断增加，导致内核十分繁忙（等于在读一张很大的没建索引的表）。

测试环境80多个service就有1601条了，而且基本都还是单pod。

3、IPVS

一张图说明，用ipset存储iptables规则，这样规则的数量就能够得到有效控制，而在查找时就类似hash表的查找。