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 – 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.

Maciej[cc] » sieci