Связь microk8s — vxlan.calico, мост и вет

Question

Связь microk8s — vxlan.calico, мост и вет

Я настроил свой экземпляр 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 НЕ работает, и к нему ничего не подключено, например, Calico Veths.

Итак, я начал прослушивать трафик наvxlan.calicovxlan, когда я скручиваю некоторые рабочие нагрузки между собой. Ничего там (на этом устройстве). Трафик не найден. Насколько я знаю и проверял, чтобы общаться с ветеринарами, нужен мост. Чтобы запустить через него vxlan, вам нужно, чтобы vxlan был подключен к мосту... Но, как вы видите, здесь ничего нет.

Единственное общение, которое я вижу, - это на ветах, но как же так, что два непарных вета разговаривают друг с другом?

2

microk8s vxlan

Источник

Maciek Leks 03 апр '23 в 10:50

1 ответ

Другие вопросы по тегам microk8s vxlan

Maciek Leks 05 апр '23 в 06:59 2023-04-05 06:59 · Answer 1 · 2023-04-05 06:59

Хорошо, правда довольно проста. Для связи между модулями с одним узлом нет необходимости использовать мост, поэтому мост НЕ работает (я полагаю), в то время как вся связь основана на маршрутах маршрутизации.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 в корневом пространстве имен имеют одинаковые MAC-адреса:ee:ee:ee:ee:ee:ee, пока

$ ips ржать

показывает парные MAC-адреса Veth в пространствах имен контейнеров

      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.