Maciej[cc] » kubernetes

Debugowanie kontenerów w kubernetesie – część 2

maciej — Tue, 12 Mar 2024 10:02:11 +0000

Po poprzedniej części zapraszam na kolejną, pokazującą jak poradzić sobie z ograniczeniami które wprowadza Kubernetes podczas debugowania aplikacji sieciowych.

Wykonanie pojedynczego polecenia/shelll

kubectl -n my_namespace exec -it pod -- /bin/some_command

Gdzie zwykle /bin/some_command można zastąpić /bin/bash

Kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest /bin/bash

Powyższe spowoduje uruchomienie nowego kontenera w tym samym podzie. Dzięki temu możemy połączyć się do localhost (127.0.0.1) i sprawdzić jak działają nasze serwisy za pomocą curl/wget. W trybie debug mamy też dostęp do roota, dzięki czemu hardening właściwej aplikacji nie jest aż tak straszny i nie ogranicza nas, np. w zainstalowaniu nowych paczek. Taki kontener nie współdzieli też systemu plików z oryginalnymi kontenerami z poda, dzięki temu nie namieszamy zbyt dużo.

Lepszy kontener do debugowania

kubectl debug my_pod_name -n my_namespace -it --image=ubuntu:latest --share-processes -c container_name --copy-to=mg-debug

Jest to trochę bardziej rozbudowana wersja poprzedniego polecenia. Odpalając taki kontener do debugowania możemy wybrać jeden z istniejących kontenerów i kubectl skopiuje jego konfiguracje (zamontowane volumes, sieć i przestrzeń procesów). Zabawa w takim środowisku daje już dość duże możliwości interakcji z innymi kontenerami. Można wysłać przyjacieski sygnał -KILL do procesów, pogrzebać w podmontowanych wolumenach lub sprawdzić sieć, również bez ograniczeń hardeningu.

Shell noda

Link dla zdesperowanych: https://github.com/kvaps/kubectl-node-shell. Skrypt potrafi uruchomić shell na nodzie kubernetesa. Dzięki niemu możemy dostać się jako root na dowolnego noda z klastra jako root i wprost pogrzebać w systemie. Chyba najbardziej “wszechmocna” opcja do zabawy w szukanie dziury w całym.

Miłego debugowania!

Kubernetes – jak działa cluster IP

maciej — Sun, 29 Dec 2019 13:27:08 +0000

Niedawno pisałem o implementacji sieci opartej o Flannel. Zabrakło tam jednak jednej istotnej rzeczy – clusterIP. W tym poście przeczytasz jak dokładnie jest to zaimplementowane.

Jeśli patrzyłeś na organizację interfejsów, adresów itd., to pewnie rzuciło Ci się w oczy, że nigdzie nie było routingu ani żadnego innego śladu po adresach IP przydzielonych do serwisów. Jeśli korzystasz z domyślnej konfiguracji, jaką Kubernetes daje, to jest to pula 10.96.0.0/16. Z niej można wybrać dowolny adres IP który będzie dostępny w całym klastrze Kubernetesa i routowany do konkretnego serwisu:

apiVersion: v1
kind: Service
metadata:
 name: dinemic-io
 labels:
 app: dinemic-io
spec:
 ports:
 - port: 80
 selector:
 app: mnabozny-pl
 clusterIP: 10.96.0.123

Serwis za pomocą definicji z pola selector wyszukuje odpowiednie aplikacje, do których będzie przekierowany ruch na port 80. Będąc w dowolnym miejscu klastra (node lub K8s master) zawsze będziemy mogli połączyć się z tym adresem, na port 80. Patrząc natomaist w tablicę routingu, nie znajdziemy ani jednego wpisu wskazującego na taką pulę adresów:

maciek> ip route show
default via 192.168.1.1 dev eth0 onlink 
10.0.0.0/24 dev eth1 proto kernel scope link src 10.0.0.1 
10.244.0.0/24 dev cni0 proto kernel scope link src 10.244.0.1 
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 via 10.244.3.0 dev flannel.1 onlink 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
...

Pula adresów 10.0.0.0/24 to fizyczna sieć klastra, w którym działa Kubernetes. 10.244.X.0/24 to pula adresów, które Kubernetes przydziela poszczególnym podom na nodach (gdzie X odpowiada nodowi, a konkretny numerek podowi).

Traceroute do adresu powyższego serwisu wychodzi zawsze poza moją sieć, zgodnie z tym, co mówi tablica routingu. Wget na http://10.96.0.123:80 zawsze magicznie dociera do celu. Gdzie więc czai się ta magia?

Iptables dla clusterIP

Popatrzmy w ipsables. Za pomocą sudo iptables-save można wylistować wszystkie regułki, które są aktualnie załadowane do jądra. Jest tego dość sporo, dla tego można wspomóc się grepem:

maciek> sudo iptables-save | grep 10.96.0.123
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.96.0.123/32 -p tcp -m comment --comment "cloudover/dinemic-io: cluster IP" -m tcp --dport 80 -j KUBE-SVC-AA7UXNSLITSSEFAY

Do łańcucha KUBE-SERVICES jest przekierowywany cały ruch z łańcucha INPUT. Pierwsza z powyższych reułek oznacza pakiety, które mają być oznaczone do MASQUERADE. Druga natomiast przekazuje je do konkretnego łańcucha – KUBE-SVC-AA7UXNSLITSSEFAY. Obie reguły działają dla docelowego adresu 10.96.0.123, na docelowym porcie 80.

Łańcuch dla konkretnego serwisu

W powyższym outpucie z iptables-save można zobaczyć, że druga regułka przekierowuje druch do konkretnego łańcucha, odpowiadającego serwisowi – KUBE-SVC-AA7UXNSLITSSEFAY. Przyjżyjmy się mu bliżej:

maciek> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0

Powyższy serwis przekierowuje cały ruch (100%) do łańcucha odpowiadającemu konkretnemu podowi, na port 80, robiąc przy okazji DNAT:

maciek> sudo iptables -nL KUBE-SEP-Q3TQA7ZS25JCTF3F -t nat
Chain KUBE-SEP-Q3TQA7ZS25JCTF3F (1 references)
target prot opt source destination 
KUBE-MARK-MASQ all -- 10.244.3.115 0.0.0.0/0 
DNAT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp to:10.244.3.115:80

Czyli, podsumowując, dowolny pakiet wchodzący do noda (INPUT) lub wychodzący z niego (OUTPUT) jest procesowany przez łańcuch KUBE-SERVICES. W nim natomiast K8S dodaje pojedyncze regułki, które wyłapują ruch kierowany do poszczególnych clusterIP przydzielonych do serwisów. Każdy serwis i clusterIP posiada swój osobny łańcuch KUBE-SVC-…, w którym jest rozdzielany ruch do poszczególnych podów i ich łańcuchów, w których jest realizowany DNAT.

Serwis dla wielu podów

Powyższy przykład pokazywał wpisy dla serwisu, który przekazuje ruch do jednego poda. Co jeśli przeskalujemy go do dwóch instancji? Szybkie kubectl apply -k . i po chwili mamy kilka zmian! Chwila oznacza dokładnie tyle, ile trzeba aby nowy pod się uruchomił i zaczął działać. Popatrzmy jeszcze raz w całe iptables. KUBE-SYSTEM pozostaje bez zmian, dalej kieruje ruch dla clusterIP 10.96.0.123 do naszego serwisu, w łańcuchu KUBE-SVC-AA7UXNSLITSSEFAY.

Natomiast sam łańcuch KUBE-SVC-AA7UXNSLITSSEFAY ma już nowe wpisy:

> sudo iptables -nL KUBE-SVC-AA7UXNSLITSSEFAY -t nat
Chain KUBE-SVC-AA7UXNSLITSSEFAY (1 references)
target prot opt source destination 
KUBE-SEP-Q3TQA7ZS25JCTF3F all -- 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.50000000000
KUBE-SEP-OCALVIKCSC2PZKNJ all -- 0.0.0.0/0 0.0.0.0/0

Dodana została na początku nowa regułka kierująca 50% ruchu (popatrz na komentarz – statistic mode, z probability 0.5) do nowego poda, którego ruch jest kształtowany przez łancuch KUBE-SEP-Q3TQA7ZS25JCTF3F. Pozostałe 50% ruchu wpada w ostatnią regułkę, która jest tam od początku. Jeśli przeskalujemy nasz deployment do większej ilości podów, to udział procentowy odpowiednio spadnie do 100/N.

Skalowalność samego cluster IP

Można mieć wrażenie, że każdy pod w klastrze K8S jest w pewnym stopniu single point of failure i jest to prawdą. Natomiast dołożenie nad podami i naszymi aplikacjami abstrakcyjnej warstwy serwisów, które są czymś w rodzaju load balancera, pozwala bardzo łatwo ograniczyć ten słaby punkt. Jeśli nasze pody z aplikacją będą odpowiednio rozproszone po klastrze, w dużej ilości instancji, to awaria dowolnego poda nie wpłynie na dostępność naszego serwisu.

A co z samym clusterIP? Zauważ, że to konkretne IP, na które tu patrzyliśmy nie jest nigdzie “fizycznie” widoczne. Każdy host w klastrze K8S posiada swój własny zestaw regułek, zwykle spójny z innymi, przynajmniej pod kątem clusterIP. Próbując dostać się do konkretnego serwisu, właśnie przez clusterIP tak na prawdę iptables losuje nam IP poda, na który będziemy przekierowani i DNAT’owani.

Również dzięki temu można przekierować/przeroutować ruch np. z VPN lub zewnętrznej sieci do dowolnego noda, który stanie się wtedy gateway’em. Taki node po otrzymaniu pakietu do jednego z clusterIP przekieruje takie zapytanie dalej, do odpowiedniego poda.

Troubleshooting

A wszystko to, bo ostatnio pomieszałem labelki w selektorze aplikacji www i mysql’a :) około połowa połączeń była odrzucana, przez co strona częściej nie działała niż działała. Jeśli doświadczasz losowego connection refused, to prawdopodobnie właśnie przy load balancingu/losowaniu poda K8S przekierowuje Twoje zapytanie do innego poda, który w danej chwili ma uruchomioną inną usługę. Po sprawdzeniu, zmianie labelek i przeładowaniu całego serwisu wszystko zaczyna działać.

Kubernetes – co w sieci piszczy

maciej — Sun, 24 Nov 2019 10:44:57 +0000

Zróbmy wycieczkę pakietem od poda, aż po default gateway całego klastra Kubernetesa. Post ma na celu ułatwienie debugowania ewentualych problemów sieciowych Kubernetesa z Flannelem.

Skoro to czytasz, to zakładam, że masz jako takie pojęcie czym się je Kubernetesa, czym są pody i interfejsy sieciowe. Dobrze, gdybyś też wiedział conieco o kontenerach Dockera. Na tapetę weźmiemy (nie)działającą instalację, która składa się z kilku kontenerów i sieci obsługiwanej przez Flannel. Zaczynajmy!

Wejdźmy do poda

A zanim wejdziemy, zobaczmy jakie mamy pody:

master# kubectl get pods -n cloudover
NAME READY STATUS RESTARTS AGE
cloudover-io-8xxxyyy886-6c86k 1/1 Running 2 10d
cloudover-io-8xxxyyy886-jx479 1/1 Running 2 10d
cloudover-org-xxxyyyc48-4j4j4 1/1 Running 2 10d
cloudover-org-xxxyyyc48-jv59p 1/1 Running 2 10d
dinemic-io-599xxxyyy8-86d49 1/1 Running 2 20d
dinemic-io-599xxxyyy8-t4pq6 1/1 Running 2 20d
dinemic-io-backup-15xxxyyy20-4t2xr 0/1 Completed 0 2d17h
dinemic-io-backup-15xxxyyy20-2x7pp 0/1 Completed 0 41h
dinemic-io-backup-15xxxyyy20-7k8zs 0/1 Completed 0 17h
dinemic-io-mysql-79yyyxxx6d-wfdrh 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-p9jp2 1/1 Running 2 20d
mnabozny-pl-56xxxyyy45-plzfq 1/1 Running 2 20d
mnabozny-pl-backup-157xxxyyy0-q76s7 0/1 Completed 0 125m
mnabozny-pl-backup-157xxxyyy0-vrzgt 0/1 Completed 0 65m
mnabozny-pl-backup-157xxxyyy0-nt5mm 0/1 Completed 0 5m20s
mnabozny-pl-mysql-86xxxyyy55-q7nhn 1/1 Running 2 20d
pkg-cloudover-org-84xxxyyy78-dxzxr 1/1 Running 2 10d
pkg-cloudover-org-84xxxyyy78-tqb7w 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-2729k 1/1 Running 2 10d
pkg-dinemic-io-xxxyyyfc77-4vjsq 1/1 Running 2 10d

Mamy więc kilka podów z różnych moich serwisów oraz zakończone cron joby backupu danych (Completed). Weźmy na warsztat poda pkg-dinemic-io-xxxyyyfc77-2729k, który sprawia problemy i zobaczmy jak wygląda jego sieć. Żeby było czym popatrzeć, musimy doinstalować potrzebne narzędzia (polecenie ip). Domyślnie, obraz dockera, z którego odpalony jest ten serwis, jest dość mocno okrojony:

master# kubectl exec -n cloudover -it pkg-dinemic-io-... bash
apt update
apt install -yqq iproute2 traceroute

Kolejną rzeczą jest sprawdzenie na którym nodzie uruchomiony jest pod, który chcemy zbadać i doinstalowanie tcpdumpa.

Mając (prawie) wszystko co potrzeba, możemy zobaczyć jak połączone są interfejsy poda i noda. Linux (docker i cała masa innych narzędzi) wykorzystuje mechanizm veth oraz sieciowe namespace (przestrzenie nazw), netns do oddzielania od siebie ruchu sieciowego kontenerów, wirtualnych maszyn itd. Namespace to grupa procesów (dotyczy to też dowolnego innego zasobu), która współdzieli te same interfejsy, tablice routingu, firewall i trochę innych rzeczy. Działa to prawie tak, jak osobny host w sieci lub wirtualna maszyna, z tą różnicą, że mamy doczynienia z jednym systemem operacyjnym. Jądro Linuksa odseparowuje te zasoby, aby można było używać np. nachodzących na siebie adresacji lub regułek iptables bez żadnych dodatkowych komplikacji.

Druga z przydatnych rzeczy, o której wspomniałem to interfejs typu veth. Najprościej jest porównać je do wirtualnego kabelka ethernetowego, który spina dwa interfejsy. Jeśli pakiet pojawi się na jego jednym końcu, to jest widoczny również na drugim (peer interface). Sparowane interfejsy veth można przekładać pomiędzy różnymi namespaces i przy nieco bardziej zaawansowanej konfiguracji, kształtować ruch sieciowy pomiędzy nimi. Korzysta z tego m.in. openstackowy neuron, flannel, corecluster i prawdopodobnie sporo innych narzędzi.

# dodaj nowa namespace
ip netns add test-ns

# dodaj pare interfejsow veth - veth1 i veth1p, ktore sa wzajemnie sparowane
ip link add veth1 type veth peer name veth1p

# ustaw namespace interfejsu peer na nasza nowa namespace
ip link set veth1p netns test-ns

Powyższy przykład tworzy nazwaną namespace, którą możemy zobaczyć przez ip netns show i usunąć przez ip netns del test-ns.

My za pomocą polecenia ip chcemy zobaczyć jak poukładane są interfejsy sieciowe na nodzie, gdzie jest uruchomiony pod. Sprawdźmy najpierw w samym podzie jakie mamy interfejsy:

pod# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
3: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default 
 link/ether a2:62:74:d8:6e:1c brd ff:ff:ff:ff:ff:ff link-netnsid 0
 inet 10.244.1.80/24 scope global eth0
 valid_lft forever preferred_lft forever

Jak zawsze lo, które jest po prostu lo. Eth0 za to prezentuje się nieco inaczej niż na “zwykłym” systemie. Po nazwie eth0 widzimy @if12. Dwunastka po małpie oznacza id interfejsu peer, który jest sparowany z naszym eth0. Eth0 w tym przypadku veth w przestrzeni namespace, której tutaj nie widzimy, z netnsid 0.

Patrząc po drugiej stronie, czyli na nodzie mamy taką listę interfejsów:

node# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
 link/ether aa:bb:cc:xx:yy:zz brd ff:ff:ff:ff:ff:ff
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Ostatni z nich to dźwięcznie brzmiący veth7b2f355b z dopiskiem @if3 Patrząc na pierwszy listing, który zrobiliśmy w podzie, z eth0@if12 widać, że eth0 poda miało id 3. Wszystko wię zatem zgadza. Ostatnią rzeczą, na którą warto rzucić okiem to parametr link-netnsid oznaczający ID namespace, do którego przypisany jest peerowany interfejs. Tak więc, w ip link show bezpośrednio z noda widzimy, że interfejs veth7b2f355b jest speerowany (sparowany? może pożeniony? :) z interfejsem o id 3 z namespace o id 5. W ip link show uruchomionym na podzie, widzimy, że interfejs eth0 jest speerowany z interfejsem o id 12, z namespace 0.

Wszystko się zgadza. Żeby sprawdzić możemy puścić pinga lub traceroute z poda i nasłuchiwać na odpowiadającym mu interfejsie sieciowym, na nodzie. Pakiety powinny się pojawić.

Dalej, w świat po opuszczeniu poda

Pakiety wychodzące z poda są adresowane przez “system operacyjny” poda z adresu interfejsu eth0 (src):

pod# ip route show
default via 10.244.1.1 dev eth0 
10.244.0.0/16 via 10.244.1.1 dev eth0 
10.244.1.0/24 dev eth0 proto kernel scope link src 10.244.1.80

W tym przypadku będzie to 10.244.x.y/24, który skonfigurował automatycznie Kubernetes. Po stworzeniu takiego pakietu i zaadresowaniu, jego warstwa IP nie powinna się zmieniać (chyba, że przejdzie przez magiczne regułki iptables, o czym będzie później). Zatem sam pod odpowiada za przygotowanie naszego pakietu w warstwie trzeciej.

Po przejściu na drugą stronę, czyli do “systemu” noda, pakiet taki pojawia się na interfejsie speerowanym z podem. Patrząc na adresacje tego interfejsu po stronie noda, nie zobaczymy już na nim adresu IP:

node# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 inet6 ::1/128 scope host 
 valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 link/ether b8:27:eb:46:06:69 brd ff:ff:ff:ff:ff:ff
 inet 10.0.0.103/24 brd 10.0.0.255 scope global eth0
 valid_lft forever preferred_lft forever
 inet6 fe80::ba27:ebff:fe46:669/64 scope link 
 valid_lft forever preferred_lft forever
...
5: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default 
 link/ether 9e:2b:2b:16:e2:73 brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.0/32 scope global flannel.1
 valid_lft forever preferred_lft forever
 inet6 fe80::9c2b:2bff:fe16:e273/64 scope link 
 valid_lft forever preferred_lft forever
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
 inet 10.244.1.1/24 scope global cni0
 valid_lft forever preferred_lft forever
 inet6 fe80::58a8:5dff:fe84:d7ee/64 scope link 
 valid_lft forever preferred_lft forever
...
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5
 inet6 fe80::9004:f7ff:fea2:90f0/64 scope link 
 valid_lft forever preferred_lft forever

W zasadzie żaden z interfejsów speerowanych z podami nie ma przypisanego adresu. Jak jest zatem organizowany routing i przekazywanie pakietów? Tu zaczyna się nieco trudniejsza zabawa.

Każdy z interfejsów przyłączonych do podów jest zmostkowany z cni0 (żeby wyświetlić, doinstaluj pakiet br-utils):

node# brctl show
bridge name	bridge id		STP enabled	interfaces
cni0		8000.5aa85d84d7ee	no		veth67f9f314
							veth7b2f355b
							veth96d5a04b
							vethe25b43a7
							vethed432234
docker0		8000.02421143bd1a	no

Nasz interfejs veth7b2f355b również tam jest. Zatem pakiety, o ile nie zostaną wycięte przez iptables, są przekazywane przez mostek pomiędzy interfejsami z tego samego noda. Jeśli nie możesz sobie tego wyobrazić, to pomyśl, że cni0 jest switchem, a każdy zmostkowany interfejs jest kabelkiem (veth) prowadzącym do innego komputera (tutaj to namespace).

Dokładnie to samo można sprawdzić przez polecenie ip z pakietu iproute:

node# ip link show
...
6: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP mode DEFAULT group default qlen 1000
 link/ether 5a:a8:5d:84:d7:ee brd ff:ff:ff:ff:ff:ff
7: veth67f9f314@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether ce:53:d6:38:84:5c brd ff:ff:ff:ff:ff:ff link-netnsid 0
8: vethe25b43a7@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether a6:16:c1:f9:ae:02 brd ff:ff:ff:ff:ff:ff link-netnsid 1
10: vethed432234@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 82:a5:3c:69:61:39 brd ff:ff:ff:ff:ff:ff link-netnsid 3
11: veth96d5a04b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 7e:af:3a:8a:29:91 brd ff:ff:ff:ff:ff:ff link-netnsid 4
12: veth7b2f355b@if3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master cni0 state UP mode DEFAULT group default 
 link/ether 92:04:f7:a2:90:f0 brd ff:ff:ff:ff:ff:ff link-netnsid 5

Każdy z interfejsów zmostkowanych z cni0 (lub innym mostkiem) ma parametr master cni0, który odpowiada za “bycie w bridgu” z cni0.

Ok, mamy zatem interfejsy, które są ze sobą połączone warstwą drugą, natomiast nie mamy jeszcze interfejsu, który odpowiadałby za wypchnięcie pakietu z noda lub przekazanie do innego poda. O ile w podzie wszystko jest jasne i routing mówi: wszystko co nie do mnie, idzie przez default gw, to na nodzie tak różowo nie jest.

Pakiety w obrębie jednego noda są routowane pomiędzy nimi, przez cni0 – każdy pod na nodzie ma swój IP z sieci przypisanej do noda – w tym przypadku 10.244.1.0/24. Jeśli pakiet ma być dostarczony do innego noda, to zaczynają się schodki.

Tablica rouringu noda wygląda następująco:

node# ip route show
default via 10.0.0.1 dev eth0 onlink 
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.103 
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 
10.244.4.0/24 via 10.244.4.0 dev flannel.1 onlink 
10.244.5.0/24 via 10.244.5.0 dev flannel.1 onlink 
10.244.6.0/24 via 10.244.6.0 dev flannel.1 onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown

Cała sieć 10.244.1.0/24 jest routowana do naszego noda przez cni0. Natomiast sieci z innych nodów (10.244.2-6.0/24) są przesyłane przez interfejs flannel.1. Dopisek onlink mówi kernelowi, aby przesyłał ruch do tych sieci, nawet nie mając na tym interfejsie przypisanego adresu ip (inaczej musiałby mieć trasę przez konkretny host).

Interfejs flannel.1 jest tunelem vxlan (ip -d link show pokaże przy nim ID vlanu 1, mówi o tym też dopisek .1 w nazwie). Zatem adresując pakiet z naszego poda z adresem 10.244.1.68, przechodzi on przez interfejsy veth do domyślnego namespace, i pojawia się jako pakiet przychodzący przez port cni0 (łapie się na regułki z łancucha FORWARD z iptables), ale nie adresowany do naszego noda (zatem nie będzie to iptables INPUT). Ponieważ kernel w domyślnym namespace zna regułki mówiące o tym jak dostać się do innych sieci na innych nodach, przesyła taki pakiet przez interfejs flannel.1. Tam już na podstawie zapytań arp odnajnowany jest host z sieci innego noda, obsługującego danego poda, np. 10.244.6.0/32:

node# arp -an | grep flannel.1
? (10.244.4.0) at 2e:ed:ad:yy:aa:xx [ether] PERM on flannel.1
? (10.244.0.0) at d2:79:b7:yy:aa:xx [ether] PERM on flannel.1
? (10.244.3.0) at 1e:42:c2:yy:aa:xx [ether] PERM on flannel.1
? (10.244.6.0) at 5a:2d:9a:yy:aa:xx [ether] PERM on flannel.1
? (10.244.2.0) at c6:52:d3:yy:aa:xx [ether] PERM on flannel.1
? (10.244.5.0) at ce:ec:b4:yy:aa:xx [ether] PERM on flannel.1

Sieć stworzona z interfejsów flannel.1 różnych nodów można znowu wyobrazić sobie jako switcha spinającego po jednym kabelku z różnych nodów. Jednak zamiast par veth mamy tutaj tunele VXLAN, które tworzą wirtualną warstwę 2, niezależną od fizycznej sieci. W powyższym przypadku vxlan stworzony przez flannel.1 jest wypuszczany do fizycznej sieci przez eth0 noda. W vxlanie node za pomocą pakietów ARP poznaje inne hosty w sieci i na ich podstawie jest w stanie poprawnie zaadresować mac adres karty odpowiadającej docelowej sieci, w której będzie pod. Flaga onlink w tablicy routingu trochę to zadanie ułatwia, gdyż normalnie kernel musiałby mieć podanego hosta we wspólnej sieci, łączącej wszystkie nody. Tutaj ten etap jest pominięty i przeniesiony na vxlan i odkrywanie hostów poniekąd przez arp.

Po osiągnięciu docelowego hosta przez vxlan, pakiet przebywa analogiczną drogę do poda.

iptables

Po wpisaniu iptables-save dostajemy całkiem sporo regułek i łańcuchów, które odpowiadają za filtrowanie ruchu i natowanie go. Z ważniejszych rzeczy, na które warto zwrócić uwagę, to na wszystkich nodach mamy mimo wszystko ustawioną politykę FORWARD na DROP z dopuszczeniem przekazywania pakietów z sieci flanella:

:FORWARD DROP [0:0]
...
-A FORWARD -s 10.244.0.0/16 -j ACCEPT
-A FORWARD -d 10.244.0.0/16 -j ACCEPT

Do debugowania ruchu może też się przydać poniższy zestaw regułek:

-A POSTROUTING -s 10.244.0.0/16 -d 10.244.0.0/16 -j RETURN
-A POSTROUTING -s 10.244.0.0/16 ! -d 224.0.0.0/4 -j MASQUERADE --random-fully
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.1.0/24 -j RETURN
-A POSTROUTING ! -s 10.244.0.0/16 -d 10.244.0.0/16 -j MASQUERADE --random-fully

Określa on skąd i gdzie pakiety mają być natowane oraz jaki ruch powinien zostać zablokowany.

Dodatkowo w dumpie z iptables-save znajdziemy też całą listę (dość długą) reguł, określających dostęp do klastra k8s, jego serwisów i dns’a.

Uff…

Podsumowując, inżynierowie integrujący flanella zrobili kawał dobrej roboty, który niekoniecznie dobrze się debuguje w razie problemów :) Natomiast ostatnie kilka lub kilkanaście lat pracy nad wirtualizacją i kontenerami daje coraz lepsze narzędzia pozwalające coraz lepiej kontrolować ruch sieciowy w tak zagmatwanych środowiskach jakim jest na przykład kubernetes.