共计 1666 个字符，预计需要花费 5 分钟才能阅读完成。
环境
服务器：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
