iptables的知识回顾看这:https://blog.csdn.net/huakai_sun/article/details/88837105

kube-proxy 到 路由表 （flannel，calico）是怎么玩的

首先kube-proxy是产生iptables规则的工具，实际工作的是iptables的规则，然后iptables是工作在网络层，处理完数据后，要交给上层的传输层进行路由寻址

而k8s的iptables经过好几条链找到Pod IP

所有流量都交给KUBE-SERVICES,具体走向简略如下：（详细可以看https://www.jianshu.com/p/1be9b096a691）
[nat]->[PREROUTING]->[KUBE-SERVICES]

>[KUBE-SVC-7RUAH544RSSBQYKK]

>[KUBE-SEP-IWORYNCAYHBSQHXU

>[DNAT ]

DNAT    tcp -- 0.0.0.0/0      0.0.0.0/0      /* ms-test/flask-ui:http */ tcp to:172.16.225.112:80

到达dnat就找到了pod的ip，iptables也就结束了，继续往上到传输层就是flannel，calico生成的路由表起作用了,

[root@node8 ~]# route -n

Kernel IP routing table

Destination   Gateway     Genmask     Flags Metric Ref  Use Iface

0.0.0.0     192.168.11.1  0.0.0.0     UG  100  0    0 ens33

172.16.3.64   192.168.11.54  255.255.255.192 UG  0   0    0 tunl0

172.16.104.0  192.168.11.52  255.255.255.192 UG  0   0    0 tunl0

172.16.135.0  192.168.11.53  255.255.255.192 UG  0   0    0 tunl0

172.16.166.128 192.168.11.51  255.255.255.192 UG  0   0    0 tunl0

172.16.225.64  0.0.0.0     255.255.255.192 U   0   0    0 *

...

172.16.225.112 0.0.0.0     255.255.255.255 UH  0   0    0 cali71ca141a178

...

172.17.0.0   0.0.0.0     255.255.0.0   U   0   0    0 docker0

192.168.11.0  0.0.0.0     255.255.255.0  U   100  0    0 ens33

从上图可以看出，路由表会将报文交给cali71ca141a178 这种虚拟的网络接口，这种是pod在本机的情况，如果在另一台机器上，比如192.168.11.54，则会走tunl0到达目的地，这也看出来是使用了calico的ipip 模式

cali71ca141a178 其实这个虚拟设备就是veth pair的一端

tunl0 这个就是为IPIP报文解封包的 设备