Flannel Kubernetes the hard way v2: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| Строка 67: | Строка 67: | ||
| | | | | | | | | | | | ..... | | | | |
| | | | | | | | | | | | ..... | | | | |
||
| | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | | |
| | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | | |
||
| + | | | 10.244.1.1/24 | | | | 10.244.2.1/24 | | | | 10.244.3.1/24 | | | | 10.244.X.1/24 | | |
||
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ | |
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ | |
||
| | | | | | | | |
| | | | | | | | |
||
Версия 12:32, 22 ноября 2022
Flannel
Flannel - один из способов организации оверлейной сети
Зачем это нужно
- В частных случаях когда сеть полностью контролируема и можно назначать любые маршруты и адреса на всех устройствах - не нужно строить никаких оверлейных сетей
- Если сеть не контролируется (например в арендованном датацентре или облаке, и не возможно создание маршрутов между worker-nodes то это один из множества возможных способов обеспечить оверлейную сеть
Как это устроено
"под капотом" используется VxLAN
Подробнее про VxLAN
"VxLAN это не только тунель но и свитч" =) точнее сказать распределенный свитч
VXLAN инкапсулирует кадры Ethernet уровня 2 в пакеты UDP уровня 3, что означает, что виртуальные подсети уровня 2 могут охватывать базовые сети уровня.
Другими словами, это дает возможность строить "продолжение" 2 уровня поверх третьего,
например соединить 2 географически разнесенных сегмента сети, между которыми нет физического
соединения (а только логическое, через интернет или другую сеть с маршрутизацией а не коммутацией)
так, что бы с точки зрения подключенных устройств это выглядело бы как-будто они включены в
один сегмент (например в один свитч, или для бытового уровня - в один домашний роутер).
VxLAN помешает кадры etherneth внутрь пакета UDP который в свою очередь инкапсулируется (помещается внутрь) в пакет IP.
Результирующий пакет IP может быть передан далее по IP-сетям, в том числе и через интернет. На стороне получателя устройство с
настроенной поддержкой VxLAN производит обратную процедуру - деинкапсуляцию
Впрочем, процесс инкапсуляция/деинкапсуляция применяется весьма широко и ничего нового в нем нет.
Терминология
VNI
Идентификатор сети VXLAN (VNI) используется для сегментации каждой подсети уровня 2 аналогично традиционным идентификаторам VLAN.
VTEP
Конечная точка туннеля VXLAN (VTEP) — это устройство с поддержкой VXLAN, которое инкапсулирует и деинкапсулирует пакеты.
Это может быть как программная реализация (Linux или OpenVSwitch в котором есть свой механизм для работы с VxLAN) или аппаратная (Коммутаторы с поддержкой VxLAN).
Схема лабы (несколько упрощенная)
На схеме не изображены мастер-ноды так как они в данном случае не участвуют в процессе передачи траффика.
- Worker1 - 192.168.122.88 (физическая сетевая карта)
- Worker3 - 192.168.122.114 (физическая сетевая карта)
Адреса остальных нод на схеме значения не имеют
Схема
+-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+
| node: worker1 | | node: worker2 | | node: worker3 | | node: workerN |
| | | | | | | |
| +------------+ | | +------------+ | | +------------+ | | +------------+ |
| | POD 1 | | | | POD 2 | | | | POD 3 | | | | POD N | |
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
| +--eth0------+ | | +--eth0------+ | | +--eth0------+ | | +--eth0------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| +--vethX---------+ | | +--vethX---------+ | | +--vethX---------+ | | +--vethX---------+ |
| | | | | | | | | | | | ..... | | | |
| | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | | | | cni0 (bridge) | |
| | 10.244.1.1/24 | | | | 10.244.2.1/24 | | | | 10.244.3.1/24 | | | | 10.244.X.1/24 | |
| +----------------+ | | +----------------+ | | +----------------+ | | +----------------+ |
| | | | | | | |
| | | | | | | |
| +-------------------+ | | +-------------------+ | | +-------------------+ | | +-------------------+ |
| | flannel.1 (VxLan) | | | | flannel.1 (VxLan) | | | | flannel.1 (VxLan) | | | | flannel.1 (VxLan) | |
| +------+------------+ | | +------+------------+ | | +------+------------+ | | +-------+-----------+ |
| | | | | | | | | | | |
| | | | | | | | | | | |
| +------------------------------+------------------------------+------------------- ..... -------------+ |
| | | | | | | |
| | | | | | | |
+----- enp1s0--------------+ +----- enp1s0-------------+ +----- enp1s0-------------+ +----- enp1s0-------------+
192.168.0.88 192.168.0.XX 192.168.122.114 192.168.122.YY
| | | |
+----+------------------------------+------------------------------+-------------------- ----------+----+
| L2 connected network (switch or virtual switch) ..... |
+------------------------------------------------------------------+-------------------- ----------+----+
veth/cni0
Для каждой ноды (это делается при создании POD, точно так же делает docker)
- Для простоты изображен только один POD (их может быть любое количество)
- При создании POD создается "виртуальный патч-корд",
veth, это особый тип виртуального etherneth - два интерфейса соединенных между собой - Один из пары виртуальных интерфейсов
vethпомещается в сетевое пространство имен POD (network namespace, так жи иногда используется термин vrf) - Внутри POD он именуется как eth0 (именовать интерфейсы можно любым способом, уникальным имя должно быть только в пределах namespace)
- Таким образом, так как виртуальный патч-корд ведет из POD в сетевую подсистему хост-машины
- Второй конец випртуального патч-корда включен в бридж
cni0
Flannel
Интерфейс flannel это VxLAN, проверить это можно командой:
ip -d link show dev flannel.1
В примере показан интерфейс для ноды worker3
flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 86:df:93:cc:8e:62 brd ff:ff:ff:ff:ff:ff promiscuity 0
vxlan id 1 local 192.168.122.114 dev enp1s0 srcport 0 0 dstport 8472 nolearning ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Тут нужно обратить внимание на следующие настройки:
vxlan id 1VNI=1 (идентификатор сети, нужен если нужно более больше VxLAN)local 192.168.122.114 dev enp1s0Адрес и интерфейс которые используются для отправки пакетов. Так как тут не указан параметр remote то он будет взят из таблицы "коммутации" (условно)srcport 0 0 dstport 8472Порт куда отправлять пакеты UDPnolearningАдреса в таблицу "коммутации" добавляются в ручном режиме (в случае с Flannel - как раз процессом flanneld) (???? проверить)
Остальное менее значимо : ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
Для простоты восприятия VxLAN можно думать о нем как о виртуальном свитче распределённом по нескольким физическим нодам, при ээтом в таблице "коммутации" этого "свитча" вместо портов, куда отправлять пакеты для известных адресов, содержаться IP адреса нод
Таблица заполняется статически, таким образом эта схема похожа на ситуацию когда на коммутаторе выключен mac-learning и для каждого мака рукам (или сторонним ПО, но не средствами коммутатора) создается запись в таблице коммутации.
Для сравнения VxLAN: запись следует читать так: для отправки кадра мак адресу a2:99:54:8b:35:bd в UDP пакете указать получателя dst 192.168.122.88 и порт dstport 8472 (порт взят из ip -d dev show ..
a2:99:54:8b:35:bd dst 192.168.122.88 self permanent
Для сравнения, на физическом коммутаторе запись читать так: для отправки кадра на мак 00cc.3444.b074 в Vlan 123 использовать физический порт TenGigabitEthernet1/50
#show mac address-table Unicast Entries vlan mac address type protocols port ---------+---------------+--------+---------------------+------------------------- 123 00cc.3444.b074 dynamic ip,ipx,assigned,other TenGigabitEthernet1/50
В целом аналогия достаточно близкая.
Разбор прохождения пакетов между двумя POD запущенными на разных нодах
Далее разберем работу Flannel на примере прохождения пакетов из одного POD запущенного на worker3 на другой запущенный на ноде worker1 Для простоты буду называть
- pod запущенный на ноде worker3 - pod3
- pod запущенный на ноде worker1 - pod1
Маршрут от pod3 к pod2
Проверяем как идет маршрутизация из pod3 к адресу pod1: 10.244.1.34
# traceroute 10.244.1.34
traceroute to 10.244.1.34 (10.244.1.34), 30 hops max, 60 byte packets 1 10.244.3.1 (10.244.3.1) 0.156 ms 0.048 ms 0.040 ms 2 10.244.1.0 (10.244.1.0) 2.451 ms 2.340 ms 2.239 ms 3 10.244.1.34 (10.244.1.34) 2.143 ms 2.051 ms 1.954 ms
Из этого маршрута видно три "маршрутизатора"
1 - это шлюз для POD (согласно схеме это обычно интерфейс cni0
Таблица маршрутизации pod3
Проверяем таблицу маршрутизации внутри pod3
# ip route show
default via 10.244.3.1 dev eth0 10.244.0.0/16 via 10.244.3.1 dev eth0 10.244.3.0/24 dev eth0 proto kernel scope link src 10.244.3.254
Из этого видно что первый хоп (первый адрес в трейсе) это адрес шлюза для pod3 (10.244.3.1), это адрес интерфейса cni0 на ноде worker3, на которой и запущен pod
Шлюз для pod3
В этом можно убедиться, запустив ifconfigна ноде worker3 за пределами контейнера
root@worker3:/home/ubuntu# ifconfig cni0
cni0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.244.3.1 netmask 255.255.255.0 broadcast 10.244.3.255
inet6 fe80::f8c6:3aff:fe2b:8a prefixlen 64 scopeid 0x20<link>
ether fa:c6:3a:2b:00:8a txqueuelen 1000 (Ethernet)
RX packets 112 bytes 6220 (6.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 76 bytes 6164 (6.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Таблица маршрутизации на worker3
После получения пакета нодой worker3 далее он следует согласно ее таблице маршрутизации:
ip route show
default via 192.168.122.1 dev enp1s0 proto dhcp src 192.168.122.114 metric 100 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 10.244.3.0/24 dev cni0 proto kernel scope link src 10.244.3.1 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.122.0/24 dev enp1s0 proto kernel scope link src 192.168.122.114 192.168.122.1 dev enp1s0 proto dhcp scope link src 192.168.122.114 metric 100
Здесь видно что пакет попадает под строку
Маршруты с флагом onlink
10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink
Внимание нужно обратить на то что у маршрута есть флаг onlink
Вот цитата из руководства iproute2 https://man7.org/linux/man-pages/man8/ip-route.8.html
onlink pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix.
Это означает что для маршрутов с таким флагом onlinkне обязательно иметь адрес назначенный на интерфейсе (в примере это flannel.1)
который находился бы в одной сети с шлюзом, через которые отправлять пакеты
Получение ARP-записи для адреса 10.244.1.0
Очевидно, что для того что бы отправить пакет далее на шлюз с адресом 10.244.1.0
необходимо иметь запись в таблице arp.
Проверить такое наличие можно командой arp на ноде worker3 (за пределами контейнеров)
# arp -n
Address HWtype HWaddress Flags Mask Iface 10.244.1.0 ether a2:99:54:8b:35:bd CM flannel.1
Далее пакет отправляется через устройство flannel.1
Отправка пакета через VxLAN интрерфейс
Так как устройство flannel.1 является VxLAN то далее работает в чем-то похоже на виртуальный коммутатор,
таблицу коммутации которого можно просмотреть (оставлена только значимая запись, остальные пропущены):
bridge fdb show dev flannel.1
... a2:99:54:8b:35:bd dst 192.168.122.88 self permanent ...
Тут есть некоторые отличия от обычной таблицы коммутации
- "обычные" классические свитчи ищут в таблице какой мак был изучен на каком порту и в каком VLAN
- тут таблицу следует читать так: что бы отправить кадр на мак получателя (a2:99:54:8b:35:bd) нужно в UDP пакете в который будем инкапсулировать этот кадр в качестве получателя указать адрес 192.168.122.88
- 192.168.122.88 - это адрес ноды worker1
Получение пакета на ноде worker1
Пакет попадает на ноду worker1, UDP пакет деинкапсулируется и результирующий кадр доставляется на интерфейс flannel.1
ifconfig flannel.1
flannel.1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1450
inet 10.244.1.0 netmask 255.255.255.255 broadcast 0.0.0.0
inet6 fe80::a099:54ff:fe8b:35bd prefixlen 64 scopeid 0x20<link>
ether a2:99:54:8b:35:bd txqueuelen 0 (Ethernet)
RX packets 38 bytes 2424 (2.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 24 bytes 2088 (2.0 KB)
TX errors 0 dropped 16 overruns 0 carrier 0 collisions 0
Далее оригинальный пакет извлекается из кадра эзернет и маршрутизируется согласно таблице маршрутизации на ноде worker1
Маршрутизация на ноде worker1
root@worker1:/home/ubuntu# ip r default via 192.168.122.1 dev enp1s0 proto dhcp src 192.168.122.88 metric 100 10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink 10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink 10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.122.0/24 dev enp1s0 proto kernel scope link src 192.168.122.88 192.168.122.1 dev enp1s0 proto dhcp scope link src 192.168.122.88 metric 100
root@worker1:/home/ubuntu# ip r get 10.244.1.34
10.244.1.34 dev cni0 src 10.244.1.1 uid 0
cache
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/ether 86:df:93:cc:8e:62 brd ff:ff:ff:ff:ff:ff promiscuity 0
vxlan id 1 local 192.168.122.114 dev enp1s0 srcport 0 0 dstport 8472 nolearning ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
