Networking 库伯内特斯+；Oracle云虚拟机上的印花布

[免责声明：此问题最初发布。但是，由于官方K8s声明“询问有关StackOverflow的问题”，我也将其添加到此处]

我正在尝试使用OCI VM实例在Oracle云上部署一个测试Kubernetes集群——但是，我在pod网络方面遇到了问题

网络插件是Calico——它似乎安装正确，但没有流量通过隧道从一个主机到另一个主机。例如，这里我尝试访问另一个节点上运行的nginx：

root@kube-01-01:~# kubectl get pod -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP              NODE              NOMINATED NODE
nginx-dbddb74b8-th9ns   1/1     Running   0          38s   192.168.181.1   kube-01-06   <none>
root@kube-01-01:~# curl 192.168.181.1
[ ... timeout... ]

到目前为止，我已经检查了：

印花布的布孔很好。我可以看到数据包捕获上的BGP流量，并且我可以使用Calicotl将所有节点视为“向上”

root@kube-01-01:~#./calicoctl节点状态 印花布流程正在运行

IPv4 BGP status
+--------------+-------------------+-------+----------+-------------+
| PEER ADDRESS |     PEER TYPE     | STATE |  SINCE   |    INFO     |
+--------------+-------------------+-------+----------+-------------+
| 10.13.23.123 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.124 | node-to-node mesh | up    | 09:12:49 | Established |
| 10.13.23.126 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.129 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.127 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.128 | node-to-node mesh | up    | 09:12:50 | Established |
| 10.13.23.130 | node-to-node mesh | up    | 09:12:52 | Established |
+--------------+-------------------+-------+----------+-------------+

子网的安全规则允许所有通信。所有节点都在同一子网中，我有一个无状态规则，允许来自子网内其他节点的所有流量（我还尝试添加一个规则，明确允许IP中的IP流量-相同的结果）

在K8s节点上的所有VNIC上禁用源/目标检查

我注意到的其他事情：

如果我为相同的子网流量禁用IP-in-IP封装，并在子网内使用常规路由（如AWS所述），我可以让calico工作

其他网络插件（如weave）似乎工作正常

所以我的问题是-IP封装流量中的IP发生了什么？还有什么我能查出来的吗

是的，我知道我可以直接使用托管Kubernetes引擎，但其中的乐趣（和学习机会）在哪里D

编辑以解决Rico的以下回答：

1） 我也没有让任何吊舱到吊舱的流量通过（不同主机上的吊舱之间没有通信）。但我无法捕获该流量，所以我使用节点到pod作为示例

2） 如果我在运行pod的另一个节点上点击NodePort svc，我也会得到类似的结果-我在第一个节点的IP数据包中看到传出的IP，但它们从未出现在第二个节点上（实际运行pod的节点）：

第二个节点上没有任何内容（

kube-01-06

，即实际运行nginx pod的节点）：

为了便于演示，我使用了127.0.0.1——当然，当我从外部主机点击节点端口时，也会发生同样的情况：

20:25:17.653417 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.654371 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.667227 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.653656 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.654577 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.668595 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)

3） 据我所知（如果我在这里错了，请纠正我），节点知道到pod网络的路由，并且pod到节点的流量也封装在IP中（注意上面第一次捕获中的协议4数据包）

root@kube-01-01:#kubectl获得吊舱-o宽
名称就绪状态重新启动老化IP节点指定节点
alpine-9d85bf65c-2wx74 1/1运行1 23m 192.168.82.194 kube-01-08
nginx-dbddb74b8-th9ns 1/1运行0 10h 192.168.181.1 kube-01-06
root@kube-01-01:~#路线-n
内核IP路由表
目标网关Genmask标志度量参考使用Iface
192.168.181.0 10.13.23.127 255.255.255.192 UG 0 0 tunl0

从一个吊舱到另一个吊舱的连接是否存在问题

这里的简短回答似乎是，当PodCidr数据包与同一节点或另一节点上的另一个pod通信时，它们正在被封装

注:

默认情况下，Calico的IPIP封装适用于所有容器到容器的通信

因此，如果您在pod内，您将能够连接到另一个节点上的pod。例如，如果您使用

kubectl exec-it

连接

这就是您无法从

root@kube-01-01:~#

，因为您的节点/主机对PodCidr一无所知。它通过默认节点/主机路由发送192.168.x.x数据包，但是，您的物理网络不是192.168.x.x，因此它们会丢失，因为没有其他节点/主机能够物理地理解这一点

连接到nginx服务的方式是通过，这与网络覆盖不同，允许连接到PodCidr之外的pod。请注意，这些服务规则由管理，通常是规则。此外，使用iptables，您可以明确地执行以下操作：如果您想与IP A.A.A.A.通话，则需要通过物理接口（即tun0）或必须通过IP B.B.B.B

---

希望有帮助

可能是MTU问题：

通常，工作负载接口的MTU应与网络MTU匹配。如果在IP中需要IP，则工作负载和隧道接口的MTU大小应比网络的MTU小20字节。这是由于隧道将向每个数据包添加额外的20字节头

---

阅读更多。

我只是使用了节点到机架的通信，因为它更容易演示。但是，如果我尝试点对点通信，或者如果我点击一个节点端口svc转到另一个节点上的一个点，也会发生完全相同的情况。我看到IP中的IP流量离开第一个节点，但它似乎从未到达第二个节点。我将编辑这个问题来澄清这一点。另外，有一件事我在这里不明白——根据文档（），“所有节点都可以在没有NAT的情况下与所有容器通信（反之亦然）”。因此，节点应该能够通过网络覆盖层与POD通信。在裸金属上（也使用印花布），节点能够与豆荚对话。正是这种云部署让我无法工作……tunl0接口的MTU设置为1440，物理接口上的MTU为1500：

tunl0正在运行NOARP MTU:1440

。此外，默认nginx网页的大小为612字节，远低于MTU限制。。。

root@kube-01-01:~# tcpdump -i ens3 proto 4 &
[1] 6499
root@kube-01-01:~# tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes
root@kube-01-01:~# curl 127.0.0.1:32137
20:24:08.460069 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444115 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:09.459768 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444365 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:11.463750 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19444866 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)
20:24:15.471769 IP kube-01-01 > kube-01-06: IP 192.168.21.64.40866 > 192.168.181.1.http: Flags [S], seq 3175451438, win 43690, options [mss 65495,sackOK,TS val 19445868 ecr 0,nop,wscale 7], length 0 (ipip-proto-4)

root@kubespray-01-06:~# tcpdump -i ens3 proto 4
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens3, link-type EN10MB (Ethernet), capture size 262144 bytes

20:25:17.653417 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.654371 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:17.667227 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.653656 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56630 > 192.168.181.1.http: Flags [S], seq 980178400, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.654577 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56631 > 192.168.181.1.http: Flags [S], seq 3932412963, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)
20:25:20.668595 IP kube-01-01 > kube-01-06: IP 192.168.21.64.56632 > 192.168.181.1.http: Flags [S], seq 2017119223, win 64240, options [mss 1440,nop,wscale 8,nop,nop,sackOK], length 0 (ipip-proto-4)

root@kube-01-01:~# kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP               NODE              NOMINATED NODE
alpine-9d85bf65c-2wx74   1/1     Running   1          23m   192.168.82.194   kube-01-08   <none>
nginx-dbddb74b8-th9ns    1/1     Running   0          10h   192.168.181.1    kube-01-06   <none>

root@kube-01-01:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
<snip>
192.168.181.0   10.13.23.127    255.255.255.192 UG    0      0        0 tunl0