梳理kube-proxy中iptables转发规则

kube-proxy目前转发面有几种实现，主要包括了通过Go语言实现的用户态转发、iptables转发、ipvs、eBPF转发。其中ipvs的方案中，SNAT的部分也是依赖iptables实现。

本篇文章主要大家一起梳理iptables转发的实现，整体转发流行如下图所示：

其中最重要的就是左侧的KUBE-SERVICES这条链路。如果是计算节点访问服务IP的时候会经过nat_OUTPUT这个hook，如果是节点上的Pod访问会经过nat_PREROUTING这个hook他们都汇总到KUBE-SERVICES，然后匹配具体的某个服务IP（clusterIP），如果匹配成功，会转入到具体某个服务的链 KUBE-SVC-*；这里会判断是否开启session粘连，如果没有开启则会走到random模块，将流量平均分配到每个后端KUB-SEP-*。这里会判断源IP是否就是目的IP（发夹网络，需要做一次SNAT），如果不是可以直接执行最后的DNAT将流量直接转发到对应的Pod上面。

核心的规则截图如下，以coreDNS举例，访问10.96.0.10这个IP 53端口的流量都流入KUBE-SVC-TCOU7JCQXEZGVUNU。

-A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU

random模块转发到两个后端的KUBE-SEP-*。

-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-72DVLVDEPQREGQRI
-A KUBE-SVC-TCOU7JCQXEZGVUNU -m comment --comment "kube-system/kube-dns:dns" -j KUBE-SEP-5CT2GQMTG66JFKUC

分别做DNAT，转发到10.85.0.133 和10.85.0.134的53端口。

-A KUBE-SEP-72DVLVDEPQREGQRI -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.85.0.133:53
-A KUBE-SEP-5CT2GQMTG66JFKUC -p udp -m comment --comment "kube-system/kube-dns:dns" -m udp -j DNAT --to-destination 10.85.0.134:53

至此完成了请求sevice IP到真实后端流量的转发过程。关于发夹流量和SNAT等细节部分，后面文章再详细解说。