Просмотр кода страницы Flannel Kubernetes the hard way v2

Материал из noname.com.ua

← Flannel Kubernetes the hard way v2

У вас нет прав на выполнение действия «редактирование этой страницы» по следующей причине:

---

Вы можете просмотреть и скопировать исходный код этой страницы.

[[Категория:K8s]] [[Категория:Networking]] [[Категория:Linux]] [[Категория:Kubernetes the hard way v2]] =Flannel= <code>Flannel</code> - один из способов организации оверлейной сети =Зачем это нужно= * В частных случаях когда сеть полностью контролируема и можно назначать любые маршруты и адреса на всех устройствах - не нужно строить никаких оверлейных сетей * Если сеть не контролируется (например в арендованном датацентре или облаке, и не возможно создание маршрутов между worker-nodes то это один из множества возможных способов обеспечить оверлейную сеть =Как это устроено= "под капотом" используется <code>VxLAN</code> * https://community.fs.com/ru/blog/what-is-evpn-vxlan.html =Подробнее про VxLAN= "<code>VxLAN</code> это не только тунель но и свитч" =) точнее сказать распределенный свитч <BR> <code>VxLAN</code> инкапсулирует кадры Ethernet уровня 2 в пакеты UDP уровня 3, что означает, что виртуальные подсети уровня 2 могут охватывать базовые сети уровня.<BR> Другими словами, это дает возможность строить "продолжение" 2 уровня поверх третьего, <BR> например соединить 2 географически разнесенных сегмента сети, между которыми нет физического <BR> соединения (а только логическое, через интернет или другую сеть с маршрутизацией а не коммутацией) <BR> так, что бы с точки зрения подключенных устройств это выглядело бы как-будто они включены в <BR> один сегмент (например в один свитч, или для бытового уровня - в один домашний роутер). <BR> <BR> <code>VxLAN</code> помешает кадры etherneth внутрь пакета UDP который в свою очередь инкапсулируется (помещается внутрь) в пакет IP. <BR> Результирующий пакет IP может быть передан далее по IP-сетям, в том числе и через интернет. На стороне получателя устройство с <BR> настроенной поддержкой VxLAN производит обратную процедуру - деинкапсуляцию<BR> <br> Впрочем, процесс инкапсуляция/деинкапсуляция применяется весьма широко и ничего нового в нем нет. ==Терминология== ===VNI=== Идентификатор сети <code>VxLAN</code> (VNI) используется для сегментации каждой подсети уровня 2 аналогично традиционным идентификаторам VLAN. ===VTEP=== Конечная точка туннеля <code>VxLAN</code> (VTEP, VxLAN Tunnel End Point) — это устройство с поддержкой VXLAN, которое инкапсулирует и деинкапсулирует пакеты. <BR> Это может быть как программная реализация (Linux или OpenVSwitch в котором есть свой механизм для работы с <code>VxLAN</code>) или аппаратная (Коммутаторы с поддержкой <code>VxLAN</code>). <BR> =Схема лабы (несколько упрощенная)= На схеме не изображены мастер-ноды так как они в данном случае не участвуют в процессе передачи траффика. * '''Worker1''' - <code>192.168.122.88 </code> (физическая сетевая карта) * '''Worker3''' - <code>192.168.122.114</code> (физическая сетевая карта) Адреса остальных нод на схеме значения не имеют Для POD выделено адресное пространство (первый адрес зарезервирован за шлюзом на интерфейс cni0) * '''Worker1''': <code>10.244.1.0/24</code> * '''Worker2''': <code>10.244.2.0/24</code> (не участвует) * '''Worker3''': <code>10.244.3.0/24</code> ==Схема== <PRE> +-------------------------+ +-------------------------+ +-------------------------+ +-------------------------+ | 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) ..... | +------------------------------------------------------------------+-------------------- ----------+----+ </PRE> =='''veth/cni0'''== Для каждой ноды (это делается при создании POD, точно так же делает <code>docker</code>) * Для простоты изображен только один POD (их может быть любое количество) * При создании POD создается "виртуальный патч-корд", <code>veth</code>, это особый тип виртуального etherneth - два интерфейса соединенных между собой * Один из пары виртуальных интерфейсов <code>veth</code> помещается в сетевое пространство имен POD (network namespace, так жи иногда используется термин vrf) * Внутри POD он именуется как <code>eth0</code> (именовать интерфейсы можно любым способом, уникальным имя должно быть только в пределах namespace) * Таким образом, так как виртуальный патч-корд ведет из POD в сетевую подсистему хост-машины * Второй конец випртуального патч-корда включен в бридж <code>cni0</code> =='''Flannel'''== Интерфейс flannel это <code>VxLAN</code>, проверить это можно командой: <PRE> ip -d link show dev flannel.1 </PRE> В примере показан интерфейс для ноды '''worker3''' <PRE> 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 </PRE> Тут нужно обратить внимание на следующие настройки: * <code>vxlan id 1 </code> VNI=1 (идентификатор сети, нужен если нужно более больше VxLAN) * <code>local 192.168.122.114 dev enp1s0 </code> Адрес и интерфейс которые используются для отправки пакетов. Так как тут не указан параметр remote то он будет взят из таблицы "коммутации" (условно) * <code>srcport 0 0 dstport 8472 </code> Порт куда отправлять пакеты UDP * <code>nolearning </code> Адреса в таблицу "коммутации" добавляются в ручном режиме (в случае с Flannel - как раз процессом flanneld) <BR> Остальное менее значимо : <code>ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 </code> <BR> <BR> Для простоты восприятия <code>VxLAN</code> можно думать о нем как о виртуальном свитче распределённом по нескольким физическим нодам, при ээтом в таблице "коммутации" этого "свитча" вместо портов, куда отправлять пакеты для известных адресов, содержаться IP адреса нод <BR> Таблица заполняется статически, таким образом эта схема похожа на ситуацию когда на коммутаторе выключен <code>mac-learning</code> и для каждого мака рукам (или сторонним ПО, но не средствами коммутатора) создается запись в таблице коммутации. <BR> Для сравнения <code>VxLAN</code> и классического коммутатора рассмотрим их таблицы коммутации (<code>fdb</code>, forwarding data base): <BR> ==VxLan FDB== Просмотр таблицы коммутации (fdb): <PRE> bridge fdb show dev flannel.1 </PRE> Для простоты оставлена одна запись (на самом деле их может быть много). <PRE> a2:99:54:8b:35:bd dst 192.168.122.88 self permanent </PRE> Запись следует читать так: для отправки кадра мак адресу <code>a2:99:54:8b:35:bd</code> в UDP пакете указать получателя <code>dst 192.168.122.88</code> и порт <code>dstport 8472 </code> (порт взят из <code> ip -d dev show .. </code> ==Cisco (или любой другой коммутаор) FDB== Просмотр таблицы коммутации: <PRE> #show mac address-table </PRE> Для простоты оставлена одна запись (на самом деле их может быть много). <PRE> Unicast Entries vlan mac address type protocols port ---------+---------------+--------+---------------------+------------------------- 123 00cc.3444.b074 dynamic ip,ipx,assigned,other TenGigabitEthernet1/50 </PRE> Для сравнения, на физическом коммутаторе запись читать так:<BR> для отправки кадра на мак <code> 00cc.3444.b074 </code> в <code>Vlan 123</code> использовать физический порт <code>TenGigabitEthernet1/50</code> <BR> В целом аналогия достаточно близкая. =Разбор прохождения пакетов между двумя POD запущенными на разных нодах= Далее разберем работу Flannel на примере прохождения пакетов из одного POD запущенного на worker3 на другой запущенный на ноде worker1 Для простоты буду называть * pod запущенный на ноде worker3 - '''pod3''' * pod запущенный на ноде worker1 - '''pod1''' <BR> ==Маршрут от pod3 к pod2== Проверяем как идет маршрутизация из '''pod3''' к адресу '''pod1''': 10.244.1.34 <PRE> # traceroute 10.244.1.34 </PRE> <PRE> 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 </PRE> Из этого маршрута видно три "маршрутизатора" 1 - это шлюз для POD (согласно схеме это обычно интерфейс <code>cni0</code> ==Таблица маршрутизации pod3== Проверяем таблицу маршрутизации внутри '''pod3''' <PRE> # ip route show </PRE> <PRE> 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 </PRE> Из этого видно что первый хоп (первый адрес в трейсе) это адрес шлюза для '''pod3''' (10.244.3.1), это адрес интерфейса cni0 на ноде '''worker3''', на которой и запущен pod <BR> ==Шлюз для pod3== В этом можно убедиться, запустив <code>ifconfig</code>на ноде '''worker3''' за пределами контейнера <PRE> root@worker3:/home/ubuntu# ifconfig cni0 </PRE> <PRE> 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 </PRE> После получения пакета на интерфейсе <code>cni0</code> он будет передан дальше согласно имеющимся записям в таблице маршрутизации. ==Таблица маршрутизации на worker3== После получения пакета нодой '''worker3''' далее он следует согласно ее таблице маршрутизации: <PRE>ip route show</PRE> <PRE> 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 </PRE> Здесь видно что пакет попадает под строку <code>10.244.1.0/24 via 10.244.1.0</code><BR> Тот же результат можно получить воспользовавшись командой <code>ip route get <IP адрес></code> ==Маршруты с флагом <code> onlink</code>== Найденный в таблице маршрутизации маршрут (с некоторыми особенностями) <PRE> 10.244.1.0/24 via 10.244.1.0 dev flannel.1 onlink </PRE> '''Внимание нужно обратить на то что у маршрута есть флаг <code>onlink</code>'''<BR> Вот цитата из руководства <code>iproute2</code> https://man7.org/linux/man-pages/man8/ip-route.8.html <PRE> onlink pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix. </PRE> <BR> Это означает что для маршрутов с таким флагом '''onlink''' не обязательно иметь адрес назначенный на интерфейсе (в примере это '''flannel.1''')<BR> который находился бы в одной сети с шлюзом, через которые отправлять пакеты<BR> ==Получение ARP-записи для адреса 10.244.1.0== Очевидно, что для того что бы отправить пакет далее на шлюз с адресом <code>10.244.1.0</code><br> необходимо иметь запись в таблице <code>arp</code>. <BR> Проверить такое наличие можно командой <code>arp</code> на ноде '''worker3''' (за пределами контейнеров) <PRE> # arp -n </PRE> <PRE> Address HWtype HWaddress Flags Mask Iface 10.244.1.0 ether a2:99:54:8b:35:bd CM flannel.1 </PRE> Далее пакет отправляется через устройство <code>flannel.1</code>, для этого есть все необходимые данные: * мак-адрес получателя (что бы сформировать etherneth-кадр) * физический или виртуальный интерфейс через который отправлять сформированный кадр ==Отправка пакета через VxLAN интрерфейс== <BR> Так как устройство <code>flannel.1</code> является <code>VxLAN</code> то далее работает в чем-то похоже на виртуальный коммутатор, <br> таблицу коммутации которого можно просмотреть (оставлена только значимая запись для нужного МАК-адреса, остальные пропущены): <PRE> bridge fdb show dev flannel.1 </PRE> <PRE> ... a2:99:54:8b:35:bd dst 192.168.122.88 self permanent ... </PRE> Тут есть некоторые отличия от обычной таблицы коммутации * "обычные" классические свитчи ищут в таблице какой мак был изучен на каком порту и в каком VLAN * тут таблицу следует читать так: '''что бы отправить кадр на мак получателя (<code>a2:99:54:8b:35:bd</code>) нужно в IP пакете, в который будем инкапсулировать этот кадр, в качестве получателя указать адрес <code>192.168.122.88</code>''' * <code>192.168.122.88</code> - это адрес ноды '''worker1''' на которой и расположен нужный POD <BR> Повторю, что записи таблице "коммутации" в реализации <code>Flannel</code> возникают не магическим образом, а их добавляет демон <code>flanneld</code>, который в свою очередь, имея доступ к API <code>kube-apiserver</code> имеет информацию для заполнения таблички, а именно * MAC-адреса POD-ов запущенных на ноде * IP-адрес ноды (<code>kubelet</code>) Соответственно таблица коммутации на каждой ноде выглядит так (с допущением что на каждой ноде запущен только один POD) <PRE> [Мак адрес POD1 на ноде 1] dst [IP адрес ноды 1] [Мак адрес POD2 на ноде 2] dst [IP адрес ноды 2] [Мак адрес POD2 на ноде 3] dst [IP адрес ноды 3] ... [Мак адрес POD2 на ноде N] dst [IP адрес ноды N] </PRE> '''Важное замечание''': * Такой способ заполнения таблицы не единственно возможный, есть и другие реализации * Ручное удаление записей из таблицы приводит к тому что данные перестают передаваться (что совершенно ожидаемо) * Простейший способ восстановить связь после ручного удаления записей - это рестарт пода <code>flanneld</code>на ноде, где были удалены записи. При старте POD актуализирует таблицу "коммутации" интерфейса <code>flannel.1</code> ===Немного детальнее про формат <code>VxLAN</code>=== Выше есть некоторое упрощение - инкапсуляция проходит в несколько этапов * фрейм etherneth помещается в UPD * UDP помещается в IP Формат пакета <code>VxLAN</code> (https://www.routexp.com/2019/02/vxlan-encapsulation-and-packet-format.html)<BR> [[Image:VxlanFormat.png|600px]] ==Передача между нодами== Далее пакет (с инкапсулированным фреймом) должен быть отправлен на адрес <code>192.168.122.88 </code> (как было выяснено из таблицы "коммутации" интерфейса <code>flannel.1</code>)<BR> <BR> Для этого снова обращаемся к таблице маршрутизации хоста '''worker3''': <PRE> ip route show </PRE> <PRE> 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 </PRE> Здесь видно что сеть <code>192.168.122.0/24</code>, а значит и адрес <code>192.168.122.88</code> доступны через интерфейс <code>enp1s0</code> <BR> Это видно из строки <code>192.168.122.0/24 dev enp1s0 proto kernel scope link src 192.168.122.114 </code> или воспользоваться командой <code>ip route get ...</code> <BR> Далее происходит классическая отправка пакета через ethernet (без подробностей) * Выяснить мак получателя (arp) * сформировать кадр, инкапсулировав в него пакет * отправить через интерфейс <code>enp1s0 </code> ==Получение пакета на ноде worker1== Пакет попадает на ноду '''worker1''' так как в сформированном IP , UDP пакет деинкапсулируется и результирующий кадр доставляется на интерфейс <code>flannel.1</code> <PRE> ifconfig flannel.1 </PRE> <PRE> 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 </PRE> Далее оригинальный пакет извлекается из кадра etherneth и маршрутизируется согласно таблице маршрутизации на '''ноде worker1''' ==Маршрутизация на ноде worker1== <PRE> ip route show </PRE> <PRE> 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 </PRE> Тут видно что сеть <code>10.244.1.0/24</code> и в том числе и адрес назначения <code>10.244.1.34</code> доступны через интерфейс <code>cni0</code> <BR> То же самое можно подтвердить командой: <PRE> ip route get 10.244.1.34 </PRE> <PRE> 10.244.1.34 dev cni0 src 10.244.1.1 uid 0 cache </PRE> Зная интерфейс, далее пакет отправляется через него так как через обычный ethernet * Выясняем мак получателя с помощью <code>arp</code> * Формируем и отправляем кадр <code>etherneth</code> конечному получателю =Результат= Оригинальный пакет через оверлейную сеть доставлен получателю. =Что дальше= <code>Calico</code> ?

Возврат к странице Flannel Kubernetes the hard way v2.