储备知识：四表五链，表里有链，链里有规则
四表：raw>mangle>nat>filter
五链：input、output、forward、prerouting、postrouting
https://www.cnblogs.com/linhaifeng/p/15979888.html
概念
kube-proxy 实际上并不起一个 proxy 的作用，而是 watch 变更并更新 iptables，也就是说，client 的请求直接通过 iptables 路由。
如果kube-proxy通过iptables 转发。会修改filter和nat表
filter表
filter表通过OUTPUT链规定所有的出报文都要经过KUBE-SERVICES，如果一个Service没有对应的endpoint，则拒绝将报文发出。
例如,创建一个service,下图的frontend,没有对应的endPoint
查看filter:iptables -L -n -t filter
filter表中会将访问172.18.13.31的请求拒绝。
nat表
nat表中设置的规则比较多，查看nat表命令:iptables -L -n -t nat
1、在PREROUTING阶段，将所有报文转发到KUBE-SERVICES
2、在OUTPUT阶段，将所有报文转发到KUBE-SERVICES
3、在POSTROUTING阶段，将所有报文转发到KUBE-POSTROUTING
nat表中主要增加了如下几个链-规则
1）KUBE-SERVICES
每个Service的每个服务端口都会在Chain KUBE-SERVICES中有一条对应的规则，发送到clusterIP的报文，将会转发到对应的Service的规则链，没有命中ClusterIP的，转发到KUBE-NODEPORTS。
只有发送到被kubernetes占用的端口的报文才会进入KUBE-MARK-MASQ打上标记，并转发到对应的服务规则链。例如第一条划线的KUBE-MARK-MASQ这里分配给SERVICE的端口是3306，该端口的包由kuberentes管理.
2）KUBE-SVC-YG65S75AKNCDZRSF (2 references) 
而每一个SERVICE，又将报文提交到了各自的KUBE-SEP-XXX。
3）KUBE-SEP-VFIT54JSXZ4WRSH5 (1 references)
最后在KUBE-SEP-XX中完整了最终的DNAT，将目的地址转换成了POD的IP和端口。
这里的KUBE-MARK-MASQ为报文打上了标记，表示这个报文是由kubernetes管理的，Kuberntes将会对它进行NAT转换。
4）KUBE-NODEPORTS (1 references)
KUBE-NODEPORT中，根据目的端口，将报文转发到对应的Service的规则链，然后就如同在“Chain KUBE-SERVICES”中的过程，将报文转发到了对应的POD。
5）KUBE-POSTROUTING (1 references)
这里表示k8s管理的报文(也就是被标记了0x4000的报文)，在离开Node（物理机）的时候需要进行SNAT转换。
也就是POD发出的报文。
报文处理流程图
集群内部通过clusterIP访问到pod的流程
(KUBE-SVC@nat) (KUBE-SERVICES +->SVC1 OUTPUT @filter,nat) | (KUBE-SEP@nat) PKT ----->命中ClusterIP ----------+->SVC2 -->SEP1,Mark0x0400,DNAT | | | | +->SVC3 | | | | | | +-----------------+ | +------------> | POSTROUTING | <----------+ +--------+--------+ | | match 0x0400，SNAT@nat | | 网卡 ————————————————
也可以理解为从Node发出的报文的处理过程。因为这个数据包是通过本地协议发出的，然后需要更改NAT表，那么k8s就在OUTPUT这个链上来动手。
例1：在集群内部通过ClusterIP:pod端口访问相应的pod
本例子中ClusterIP为172.18.13.113，对应的pod容器的端口为8080，对应两个pod。
访问命令为curl 172.18.13.113:8082
1、经过OUTPUT链时指出报文要经过KUBE-SERVICES
2、在KUBE-SERVICES链查找到ClusterIP-172.18.13.113，于是转发到链KUBE-SVC-YG65S75AKNCDZRSF
3、在KUBE-SVC-YG65S75AKNCDZRSF链中，因为该clusterIP对应两个pod,所有该链下有两条规则，同时实现第一条规则的概率为0.5。
4、假设我们转到了链KUBE-SEP-3BN22EQZG75AYFUY，在该链中对这个包进行了一次DNAT转换,转到172.17.9.2中，即pod的ip地址。
通过外部nodeport访问后端pod的流程
(KUBE-SVC@nat) +->SVC1 (KUBE-SERVICES@nat) | (KUBE-SEP@nat) +--->命中ClusterIP --------------------+->SVC2 -->SEP1,Mark0x0400,DNAT PREROUTING | ^ | | PKT -->| | +->SVC3 | | | | +--->未命中ClusterIP --->命中服务端口 | | | +->未命中服务端口 | | | | | +-----------------------------+ | INPUT |--> END +-----------------------------+
也可以理解为发送到Node的报文的处理过程
例2：我们在集群外的机器通过pod暴露的端口30002访问相应的pod.
其中集群外机器IP为172.18.52.170，pod所在机器为192.168.204.144，暴露在该机器的端口为30002。
访问命令为curl 192.168.204.144:30002
1、集群外机器172.18.52.170根据路由规则将数据包发送到pod所在机器192.168.204.144。
2、数据包进入了pod所在的机器，所以k8s对该机器nat表的PREROUTING链做规则。链时指出报文要经过KUBE-SERVICES。
3、把数据包转到KUBE-SERVICES这个链之后，因为我们是通过nodeport访问的，所有没有匹配到clusterIP，转到KUBE-NODEPORTS链上。
4、KUBE-NODEPORTS还是将数据包转到KUBE-SVC-VZEERQ5BHBSZ5PRL上，打上标签。再转到KUBE-SVC-YG65S75AKNCDZRSF链中，DNAT转换。
转载：https://blog.csdn.net/qq_36183935/article/details/90734847