kube-proxy

我们在集群中只要访问servie的IP+Port就可以代理到后端的Pod，在它们之前的请求转发离不开每个Node节点上的kube-proxy组件。

kube-proxy的模式有以下三种：

• Userspace
• iptables
• ipvs

kube-proxy的主要作用是：

1. 监听kube-api，获取Service相关的所有信息；
2. 修改所有node上的转发规则，维护路由信息；
3. 将请求转发到对应的Pod上；

一、Userspace

其工作流程为：请求到达Service IP的内核空间，然后回到当前组件的用户空间kube-proxy，然后生成相应的规则再到内核空间，再由iptables规则代理到请求的Pod。

在这整个过程中，kube-proxy起到代理的作用，整个调度都要经过它。

二、iptables

其工作流程为：请求到达内核空间service IP，直接由其iptables规则转发到相应Pod。

相比于userspace，iptables模式全工作在内核态，不用经过用户态kube-proxy中转。

三、ipvs

与iptables相比，IPVS拥有以下明显优势：

◎ 为大型集群提供了更好的可扩展性和性能；

◎ 支持比iptables更复杂的复制均衡算法（最小负载、最少连接、加权等）；

◎ 支持服务器健康检查和连接重试等功能；

◎ 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。

由于IPVS无法提供包过滤、airpin-masquerade tricks（地址伪装）、SNAT等功能，因此在某些场景（如NodePort的实现）下还要与iptables搭配使用。在IPVS模式下，kube-proxy又做了重要的升级，即使用iptables的扩展ipset，而不是直接调用iptables来生成规则链。

 

其工作流程：请求到达内核空间Service IP，然后由ipvs规则转发到相应的Pod。

四、包转发路径

从网络的角度看kube-proxy的包转发路径：

 

步骤：

1. 网卡收到一个包（通过 DMA 放到 ring-buffer）。
2. 包经过 XDP hook 点。
3. 内核给包分配内存，此时才有了大家熟悉的 skb（包的内核结构体表示），然后 送到内核协议栈。
4. 包经过 GRO 处理，对分片包进行重组。
5. 包进入 tc（traffic control）的 ingress hook。接下来，所有橙色的框都是 Netfilter 处理点。
6. Netfilter：在 PREROUTING hook 点处理 raw table 里的 iptables 规则。
7. 包经过内核的连接跟踪（conntrack）模块。
8. Netfilter：在 PREROUTING hook 点处理 mangle table 的 iptables 规则。
9. Netfilter：在 PREROUTING hook 点处理 nat table 的 iptables 规则。
10. 进行路由判断（FIB：Forwarding Information Base，路由条目的内核表示，译者注） 。接下来又是四个 Netfilter 处理点。
11. Netfilter：在 FORWARD hook 点处理 mangle table 里的iptables 规则。
12. Netfilter：在 FORWARD hook 点处理 filter table 里的iptables 规则。
13. Netfilter：在 POSTROUTING hook 点处理 mangle table 里的iptables 规则。
14. Netfilter：在 POSTROUTING hook 点处理 nat table 里的iptables 规则。
15. 包到达 TC egress hook 点，会进行出方向（egress）的判断，例如判断这个包是到本 地设备，还是到主机外。
16. 对大包进行分片。根据 step 15 判断的结果，这个包接下来可能会：发送到一个本机 veth 设备，或者一个本机 service endpoint， 或者，如果目的 IP 是主机外，就通过网卡发出去。