环境
服务器：172.17.17.20-22 三个服务器 （深服气aCloud虚拟化平台）
操作系统版本：CentOS 7.8
内核版本：3.10
景象
在20-22三台上装置K8S集群（通过rancher的rke装置），装置结束后，发现拜访各个节点的80端口，只有20服务器可能失常返回，其余的都是Gateway Timeout。应用Rancher的提供的这个方法得悉Overlay网络不通。
排查过程
排查网络通性
依据Rancher文档上提到的，Host的8472/udp端口是Flannel/Calico的VXLAN Overlay网络专用端口，即所有跨Host的容器间网络通信都走这个端口。因而：
在172.17.17.22上，用tcpdump抓收回的包：
tcpdump -nn 'udp and src host 172.17.17.22 and dst port 8472'另开一个22的终端，执行 curl http://localhost 可能看到 22->20 的UDP包，见下图：
在172.17.17.20上，用tcpdump抓收到的包：
tcpdump -nn 'udp and src host 172.17.17.22 and dst port 8472'后果是没有抓到任何包。
排查虚拟机网络安全组
正当狐疑虚拟机网络安全组没有放开8472/udp端口的拜访权限，在22上应用netcat发送数据：
nc -u 172.17.17.20 8472轻易打点字回车传输，如下图：
后果在20上可能抓到收到的包：
这阐明网络安全组并没有拦截8472/udp端口的拜访。
初步假如
狐疑这些数据在深服气aCloud虚拟化平台的网络中被过滤掉了。基于以下理由：
- k8s应用的是基于VXLAN的Overlay network，VNI=1，并且是基于UDP协定。而深服气aCloud高概率也应用VXLAN做Overlay网络。
- 一般的udp协定数据传输tcpdump可能抓到包（见后面）
- tcpdump在网络栈中的地位inbound在iptables之前，outbound在iptables之后（材料）。如果tcpdump可能抓到收回的包，那么阐明是真的收回了。如果inbound没有抓到承受的包，那么就阐明这个包没有达到网卡。
解决办法
和深服气的同学沟通后，其确认是物理机也是用了8472/udp端口做Overlay网络，两者抵触了，因而当UDP包内蕴含了OTV数据内容后，先一步被aCloud拦挡，后果就是虚拟机的8472/udp端口收不到数据。
将物理机的8472/udp端口改掉后，问题解决。
PS. 8472/udp还是一个驰名端口
解决办法2
也能够在rke创立k8s集群的时候批改flannel的端口，须要批改cluster.yml（参考文档）。
如果你用的是canal网络插件（默认）：
...network: plugin: canal options: canal_flannel_backend_type: vxlan canal_flannel_backend_port: "8872" ...如果用的是flannel网络插件：
...network: plugin: flannel options: flannel_backend_type: vxlan flannel_backend_port: "8872" ...在Rancher中创立自定义集群的时候，须要自定义集群参数来批改端口（参考文档）。
如果用的是canal网络插件（默认）：
rancher_kubernetes_engine_config: ... network: options: flannel_backend_type: vxlan flannel_backend_port: "8872" plugin: canal如果用的是flannel网络插件：
rancher_kubernetes_engine_config: ... network: options: flannel_backend_type: vxlan flannel_backend_port: "8872" plugin: flannel