这是一个创建于 1605 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说一下一下 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 @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 @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 @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 的数据包路由不到图中的交换机。 |
 |
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 的
|
|
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 B1 到 A 没问题，B1 到 A1 不可以，B 和 C 直接无论虚拟机还是服务器的物理网卡都可以相互 ping 通的
|
Select Language