【摘要】 上次我发了“几个容器网络相关问题的分析和解决总结”后，有的童鞋已经能照猫画虎地解决容器网络问题了，我心甚慰。前几天我又不务正业地帮忙分析解决了几个影响版本发布的网络问题。其中一个还比较复杂，我记录下来备忘。
目录
7. 主机防火墙iptables、跨节点通信Overlay网络flannel和主机安全组Security Group多种因素导致的网络不通 - iptables&flannel&security group
8. ping稳定概率丢包 - route
上次我发了“几个容器网络相关问题的分析和解决总结”后，有的童鞋已经能照猫画虎地解决容器网络问题了，我心甚慰。
前几天我又不务正业地帮忙分析解决了几个影响版本发布的网络问题。其中一个还比较复杂，我记录下来备忘。
7. 主机防火墙iptables、跨节点通信Overlay网络flannel和主机安全组Security Group多种因素导致的网络不通 - iptables&flannel&security group
问题现象：
某类生产环境，要开放K8s原生API。其中有一项功能是从K8s api Server代理(Proxy)流量到后端Pods。因为K8s Master到K8s Node的网络不通，导致版本发不出去。
跨节点通信使用Flannel，backend是VXLAN。据说backend是UDP的时候可以通信。
分析排查：
整个排障过程如下图所示，这是一个由主机防火墙iptables、跨节点通信Overlay网络flannel和主机安全组Security Group多种因素导致的网络不通的问题。比较复杂和典型。
首先，根据“几个容器网络相关问题的分析和解决总结”中的“6. K8s Master主机上ping不通Node节点上的docker0和容器，但在Node上可以ping通 - iptables”，移除K8s Master上的主机防火墙的INPUT和FORWARD链上对icmp的限制reject-with icmp-host-prohibited，还是不通。（注：此乃网络不通原因之一）
在K8s Master上查看路由，发现这个网络环境和其它的不一样，多了一个网络172.16.0.0/24，而且使用了eth0。如下：
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 172.16.0.1 0.0.0.0 UG 100 0 0 eth0
169.254.169.254 172.16.0.2 255.255.255.255 UGH 100 0 0 eth0
172.16.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 flannel.1
172.18.100.0 0.0.0.0 255.255.255.0 U 0 0 0 docker0
192.168.0.0 0.0.0.0 255.255.255.0 U 100 0 0 eth1
经询问172.16.0.0/24网络是deploy-mgr连接K8s Master的网络。因此排查重点放在此网络不一致上。尝试更改此默认路由到gw 192.168.0.1和eth1（flannel的通信网络），结果导致K8s Master不可访问。通过VNC连接上恢复。
使用journalctl -u flanneld查看flannel的日志，发现如下异常：
Using 172.16.0.4 as external interface
Using 172.16.0.4 as external endpoint
因为缺省flannel的出口网络会使用default路由的接口，而default路由的接口不在flannel的向外通信的网络上，因此肯定这个是错误的。（注：此乃网络不通原因之二）
--public-ip="":
IP accessible by other nodes for inter-host communication. Defaults to the IP of the interface being used for communication.
--iface="":
interface to use (IP or name) for inter-host communication. Defaults to the interface for the default route on the machine.
按照以上描述，修改/etc/default/flanneld中flannel的启动参数如下（-iface和-public-ip），并重启flanneld服务：
FLANNEL_OPTS="-etcd-endpoints=https://192.168.0.15:4003
-iface=eth1 -public-ip=192.168.0.15
-etcd-cafile=/var/paas/srv/kubernetes/ca.crt
-etcd-certfile=/var/paas/srv/kubernetes/kubecfg.crt
-etcd-keyfile=/var/paas/srv/kubernetes/kubecfg.key"
这块感谢丁姝洁童鞋一起头脑风暴。
查看flannel参数启动正常后，验证K8s Master到K8s Node网络还是不通！
问题解决：
百思不得其姐，几近黔驴技穷。
随后要求再次确认K8s Master上的安全组对UDP协议的8472端口的出方向和入方向是打开的，并要求设置此规则。（注：此乃网络不通原因之三）
Port (number): UDP port to use for sending encapsulated packets. Defaults to kernel default, currently 8472
注意：RFC的VXLAN协议默认端口是4789，但是flannel默认使用8472
如下打开后，网络通了！
我再次得到的教训是对诸如“我在别的地方也是这么配的，但是正常的”、“两个节点之间的通信我已经全部开放了”之类的说法要赔持怀疑态度，一定要亲自查看和确保。
8. ping稳定概率丢包 - route
问题现象：
某环境两台主机之间ping的时候稳定概率丢包50%。
图示如下：
分析排查：
怀疑是多（两）网卡和路由问题导致的一半ping包丢失。查看路由如下：
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.175.100.1 0.0.0.0 UG 0 0 0 eth2
0.0.0.0 9.91.17.59 0.0.0.0 UG 0 0 0 eth0
9.91.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
9.91.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
10.175.100.0 0.0.0.0 255.255.252.0 U 0 0 0 eth2
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
很明显地可以看出前4条路由明显不对，default有两条路由且出口完全不一样，到9.91.0.0/24有两条路由且出口完全不一样。
问题解决：
删掉错误的路由，ping就正常了。
来源：华为云社区 作者：乔雷