问一个奇怪的 K8S 集群网络问题

[zhoudaiyu]

先说一下一下 K8S 用的是 1.13 版本的，网络插件用的 Calico 3.1.3，连接模式是 IPIP 模式（ IP 隧道模式），禁用 VxLAN 。
集群的拓扑如图所示，其实原来没有物理机 A 这个机器，最近加上的，但是有很多和物理机 B 、C 的 CIDR 相同的机器，如 10.237.79.4x 、10.237.79.5x 等，无论是任意物理机上 POD （也就是图中的虚拟机）相互 PING，还是 POD 和物理机之间相互 PING 都是没有问题的，举个例子：虚拟机 B1 -> 虚拟机 C1，虚拟机 C1 -> 虚拟机 B1 相互 PING 都是通的。但对于物理机 A，这台物理网卡只能 PING 通其他物理机的物理网卡，但没法 PING 通其他机器上的 POD，反过来从 POD 中访问物理机 A 的物理网卡是没有问题的。举个例子：物理网卡 A -> 虚拟机 B1 不通，但虚拟机 B1 -> 物理网卡 A 通。还有一点，从物理网卡 A 上 PING 虚拟机 B1 时抓包发现：物理网卡 B 没有收到来自物理网卡 A 或虚拟网卡 A 的包。现在我怀疑未知网络拓扑那块可能过了某个路由器，它不支持或者没有配置 IP 隧道。大家怎么看呢？

[wd]

少一天物理机到 pod 路由吧

[zhoudaiyu]

@wd 物理机 A 的虚拟网卡有到物理机 B 物理网卡的路由，物理机 B 的物理网卡也有到虚拟机 B1 的路由

[defunct9]

开 ssh，让我上去看看

[zhoudaiyu]

@defunct9 你远程我吧 狗头

[defunct9]

@zhoudaiyu pod 主动出去没问题，pod 的大广场也没问题。进来有问题，还有路由，不好猜

[ujued]

未知网络对 192.168.2.0/24 和 192.168.3.0/24 段的 IP 没有路由配置，或未路由到图中的交换机

[ujued]

A 机器上 traceroute 192.168.2.1 就能看个大概吧

[zhoudaiyu]

@ujued #7 traceroute 全是 *

[zhoudaiyu]

@ujued #6 我觉得路由器应该不用配两个 192.168 网段的路由，因为 tunl 网卡会把发出去的包外面再套一个从物理网卡 A 到物理网卡 B 的包头

[ujued]

tun 只是虚拟个网卡。又没做 NAT，虚拟网卡发出的包交给协议栈，怎会改 source ip 为物理机了呢？

就算 A 网卡给 tun 网卡数据包做了 NAT，又怎知道给 192.168.2.0/24 的包发给物理网卡 B 就可以呢？

[ujued]

traceroute 都是*那可能防火墙封了 ICMP 报文，那 ping 不同正常！

[zhoudaiyu]

@ujued 但是物理机之间 ping 是没问题的，做了 NAT 啊，要不哪来的 192.168.x.x 的容器 IP 呢

[ujued]

物理机能 ping，可能是放开了那些网段的 ICMP 包限制。

你看看 traceroute 10.237.79.44 的路径，然后到各个路由器添加相关路由。

防火墙放开 192.168.0.0/16 的 ICMP 报文

大概是这样。

[wangyzj]

检查路由

或者清空 iptables
然后重新装一下 kube proxy

[ujued]

哦，对了，traceroute 10.237.79.44 应该也还是*，因为与目标机器间的设备不响应 ICMP 。

不过问题还是这个问题，缺少正确的路由，你的 A 机器发给 192.168.2.0/24 的数据包路由不到图中的交换机。

[zhoudaiyu]

@wangyzj 你是说本机的 ip route 吧？我试试重新生成 iptabels

[zhoudaiyu]

@ujued #15 我也怀疑路由最开始，但那为什么反过来从虚拟机 B1 到物理机 A 是没问题的呢

[twl007]

重启一下 kube-proxy 看看 不知道你用的是 iptables 模式还是 ipvs 模式 不论用那个的话都建议手动查看一下生成的列表对不对 另外检查一下 kube-proxy 的日志 看看有没有什么异常报错

[zhoudaiyu]

@twl007 好的我试试 我们用的 iptabels 模式

[twl007]

@zhoudaiyu 那估计问题原因跟我们不太一样 我们是 ipvs 建议还是手动追查一下规则 看看 iptablea 规则是不是最新的 然后再去查路由 如果路由器配置 ACL 的确是会拦住 IPIP 的