我已经配置了我的 microk8s 实例(一个节点)。运行良好。我开始深入研究一些 Linux 网络内部,看到这个我惊呆了:
$ ip -c -br 链接
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp0s3 UP 08:00:27:ad:36:a3 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp0s8 UP 08:00:27:86:35:40 <BROADCAST,MULTICAST,UP,LOWER_UP>
enp0s9 UP 08:00:27:25:c8:6d <BROADCAST,MULTICAST,UP,LOWER_UP>
br-e6dc1065d537 DOWN 02:42:92:65:b3:c3 <NO-CARRIER,BROADCAST,MULTICAST,UP>
vxlan.calico UNKNOWN 66:57:ed:b9:9c:1c <BROADCAST,MULTICAST,UP,LOWER_UP>
cali9e5a2199a75@if3 UP ee:ee:ee:ee:ee:ee <BROADCAST,MULTICAST,UP,LOWER_UP>
caliec07808c9ad@if3 UP ee:ee:ee:ee:ee:ee <BROADCAST,MULTICAST,UP,LOWER_UP>
calid39e8c9a8ec@if3 UP ee:ee:ee:ee:ee:ee <BROADCAST,MULTICAST,UP,LOWER_UP>
cali6a901a5bd4a@if3 UP ee:ee:ee:ee:ee:ee <BROADCAST,MULTICAST,UP,LOWER_UP>
$ brctl 显示 br-e6dc1065d537
bridge name bridge id STP enabled interfaces
br-e6dc1065d537 8000.02429265b3c3 no
正如您所看到的,linux bridge 处于 DOWN 状态,并且没有任何东西与其连接,例如 calico veths。
因此,当我在彼此之间卷曲一些工作负载时,我开始嗅探vxlan.calico
vxlan 上的流量。那里什么都没有(在那个设备上)。没有发现流量。据我所知,我已经测试过要通信 veths,您需要一个网桥。要通过它运行 vxlan,您需要将 vxlan 连接到网桥,……但正如您所见,这里什么都没有。
我看到的唯一通信是在 veth 上,但是两个未配对的 veth 怎么能互相通信呢?
答案1
好吧,事实很简单。对于单节点情况下的 pod 到 pod 通信,不需要使用桥接,因此桥接处于 DOWN 状态(我猜),而整个通信基于路由。ip -br -c route
显示了真相以及 calico 动态管理路由的方式。
$ ip -br -c 路线
default via 10.0.2.2 dev enp0s3 proto dhcp src 10.0.2.15 metric 100
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15 metric 100
10.0.2.2 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100
10.0.2.3 dev enp0s3 proto dhcp scope link src 10.0.2.15 metric 100
blackhole 10.1.238.128/26 proto 80
10.1.238.138 dev cali6a901a5bd4a scope link
10.1.238.142 dev caliec07808c9ad scope link
10.1.238.146 dev cali9e5a2199a75 scope link
10.1.238.149 dev cali00db5abf42d scope link
192.168.57.0/24 dev enp0s9 proto kernel scope link src 192.168.57.4 metric 100
192.168.59.0/24 dev enp0s8 proto kernel scope link src 192.168.59.118 metric 100
有一件事让我很困惑。如果我们查看接口,根命名空间中的所有 calico veth 都具有相同的 MAC:,ee:ee:ee:ee:ee:ee
而
$ ips 邻居
显示容器命名空间中的配对 veth MAC
10.1.238.149 cali00db5abf42d 2e:b1:c3:59:e4:09
10.1.238.138 cali6a901a5bd4a a6:b8:a9:c3:e7:77
10.1.238.146 cali9e5a2199a75 6e:c4:7d:a1:3b:d2
10.1.238.142 caliec07808c9ad 32:dc:93:ed:eb:51
因此,这意味着根 ns 中的设备不需要“正确的” MAC,因为我们有路由和 IP 解析表。