这是一个创建于 1976 天前的主题，其中的信息可能已经有所发展或是发生改变。/div>
先说一下一下 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 隧道。大家怎么看呢？
集群的拓扑如图所示，其实原来没有物理机 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 隧道。大家怎么看呢？
 | 1 wd 2020-07-05 12:00:11 +08:00 via iPhone 少一天物理机到 pod 路由吧 |
 | 2 zhoudaiyu OP PRO @wd 物理机 A 的虚拟网卡有到物理机 B 物理网卡的路由，物理机 B 的物理网卡也有到虚拟机 B1 的路由 |
 | 3 defunct9 2020-07-05 12:28:08 +08:00 开 ssh，让我上去看看 |
 | 6 ujued 2020-07-05 12:44:31 +08:00 via iPhone 未知网络对 192.168.2.0/24 和 192.168.3.0/24 段的 IP 没有路由配置，或未路由到图中的交换机 |
| 7 ujued 2020-07-05 12:47:33 +08:00 via iPhone A 机器上 traceroute 192.168.2.1 就能看个大概吧 |
| 9 zhoudaiyu OP PRO @ujued #6 我觉得路由器应该不用配两个 192.168 网段的路由，因为 tunl 网卡会把发出去的包外面再套一个从物理网卡 A 到物理网卡 B 的包头 |
| 10 ujued 2020-07-05 13:09:43 +08:00 via iPhone tun 只是虚拟个网卡。又没做 NAT，虚拟网卡发出的包交给协议栈，怎会改 source ip 为物理机了呢？ 就算 A 网卡给 tun 网卡数据包做了 NAT，又怎知道给 192.168.2.0/24 的包发给物理网卡 B 就可以呢？ |
| 11 ujued 2020-07-05 13:12:26 +08:00 via iPhone traceroute 都是*那可能防火墙封了 ICMP 报文，那 ping 不同正常！ |
| 12 zhoudaiyu OP PRO @ujued 但是物理机之间 ping 是没问题的，做了 NAT 啊，要不哪来的 192.168.x.x 的容器 IP 呢 |
| 13 ujued 2020-07-05 13:25:12 +08:00 via iPhone 物理机能 ping，可能是放开了那些网段的 ICMP 包限制。 你看看 traceroute 10.237.79.44 的路径，然后到各个路由器添加相关路由。 防火墙放开 192.168.0.0/16 的 ICMP 报文 大概是这样。 |
 | 14 wangyzj 2020-07-05 13:42:23 +08:00 检查路由 或者清空 iptables 然后重新装一下 kube proxy |
| 15 ujued 2020-07-05 13:42:43 +08:00 via iPhone 哦，对了，traceroute 10.237.79.44 应该也还是*，因为与目标机器间的设备不响应 ICMP 。 不过问题还是这个问题，缺少正确的路由，你的 A 机器发给 192.168.2.0/24 的数据包路由不到图中的交换机。 |
| 16 zhoudaiyu OP PRO @wangyzj 你是说本机的 ip route 吧？我试试重新生成 iptabels |
 | 18 twl007 2020-07-05 14:37:15 +08:00 via iPhone 重启一下 kube-proxy 看看 不知道你用的是 iptables 模式还是 ipvs 模式 不论用那个的话都建议手动查看一下生成的列表对不对 另外检查一下 kube-proxy 的日志 看看有没有什么异常报错 |
| 20 twl007 2020-07-05 14:43:38 +08:00 via iPhone @zhoudaiyu 那估计问题原因跟我们不太一样 我们是 ipvs 建议还是手动追查一下规则 看看 iptablea 规则是不是最新的 然后再去查路由 如果路由器配置 ACL 的确是会拦住 IPIP 的 |
| 21 zhoudaiyu OP PRO @twl007 #20 ACL 这个我们看不到，因为部署在母公司的私有云上，但是我觉得有可能是这个，十分感谢 |
| 22 twl007 2020-07-05 15:15:00 +08:00 via iPhone @zhoudaiyu 验证这个问题很简单 其实这个跟 k8s 也没啥关系 你就手动在这两个机器上创建个 ipip 测试一下就知道了 如果你手动创建的能工作 那就不是这个问题 再去找别的去 |
| 23 ujued 2020-07-05 16:46:16 +08:00 via iPhone |
| 24 zhoudaiyu OP PRO B1 到 A 没问题，B1 到 A1 不可以，B 和 C 直接无论虚拟机还是服务器的物理网卡都可以相互 ping 通的 |
Select Language