Jak diagnozować i badać sieć w Kubernetes

Kubernetes to narzędzie open-source, które jest kluczowe w orkiestracji kontenerów. Kubernetes pomaga w orkiestracji i zarządzaniu klastrami na dużą skalę w różnych środowiskach chmurowych, a nawet na serwerach lokalnych (on-premise). Klaster to zestaw hostów przeznaczonych do uruchamiania skonteneryzowanych aplikacji i usług. Klaster wymaga do działania minimum dwóch węzłów – jednego węzła nadrzędnego (master) i jednego węzła roboczego (worker). Możesz skalować swoją infrastrukturę Kubernetes, dodając więcej węzłów roboczych. Węzeł nadrzędny i jego węzły robocze muszą mieć możliwość komunikacji sieciowej, aby infrastruktura mogła działać. Aby zapoznać się z przeglądem najważniejszych funkcji Kubernetes, zapraszamy do naszego samouczka Poznajemy Kubernetes.

W tym samouczku pokażemy Ci kilka narzędzi i technik pomagających w inspekcji i rozwiązywaniu problemów z siecią w Kubernetes.

Wymagania wstępne

• Aby móc śledzić ten samouczek, powinieneś posiadać klaster Kubernetes. Mamy samouczek wyjaśniający Jak zainstalować i używać Kubernetes na Ubuntu 20.04 , który może przeprowadzić Cię przez konfigurację podstawowego klastra na potrzeby demonstracji.

• Powinieneś również mieć kubectl zainstalowane lokalnie. W zależności od lokalnego środowiska, postępuj zgodnie z oficjalną dokumentacją dotyczącą instalacji narzędzi Kubernetes. Narzędzie kubectl powinno być skonfigurowane do połączenia z Twoim klastrem. Wyjaśnimy to szczegółowo w sekcji poniżej.

Uruchomimy kilka poleceń zarówno lokalnie, jak i na węźle Kubernetes. Zaczynajmy!

Konfiguracja lokalnego kubectl do połączenia ze zdalnym klastrem Kubernetes

Zacznijmy od zainstalowania kubectl. Nasze lokalne środowisko działa na systemie Ubuntu, przejdź pod ten link, jeśli korzystasz z innego środowiska lokalnego. Aby zainstalować narzędzia kubectl w lokalnym środowisku Ubuntu/Debian za pomocą menedżera pakietów apt, uruchom następujące polecenia, aby zaktualizować repozytorium apt i zainstalować niezbędne pakiety:

Następnie uruchom następujące polecenie, aby pobrać publiczny klucz podpisywania Google Cloud:

Następnie dodaj repozytorium apt Kubernetes:

Następnie zaktualizuj indeks apt i zainstaluj kubectl za pomocą następującego polecenia:

Następnie zweryfikuj, czy kubectl jest zainstalowany, sprawdzając wersję za pomocą następującego polecenia:

Oto dane wyjściowe, jeśli właśnie zainstalowałeś kubectl lokalnie:

Na powyższym zrzucie ekranu kubectl próbuje połączyć się z lokalnym klastrem Kubernetes. Jednak to się nie udaje, ponieważ nie mamy jeszcze uruchomionego klastra Kubernetes na naszej lokalnej maszynie.

Aby połączyć się ze zdalnym klastrem Kubernetes, najpierw pobierzesz dane uwierzytelniające Kubernetes ze zdalnego klastra. Oto polecenie do skopiowania danych uwierzytelniających z węzła nadrzędnego (master):

Zastąp wyróżnione części swoją ssh nazwą użytkownika i publicznym adresem IP węzła nadrzędnego. Po zakończeniu pobierania danych uwierzytelniających skopiuj je do swojego katalogu domowego:

To wszystko. Twój lokalny kubectl powinien być w stanie połączyć się i wydawać polecenia w Twoim zdalnym klastrze Kubernetes. Aby potwierdzić, że Twój lokalny kubectl jest połączony ze zdalnym klastrem, sprawdź ponownie za pomocą polecenia version:

Oto dane wyjściowe pokazujące pomyślne połączenie:

Opcjonalnie możesz wykonać polecenie get nodes w następujący sposób:

Pobieranie adresu Cluster IP poda

Możesz pobrać adres Cluster IP poda, uruchamiając polecenie kubectl get pod na swoim lokalnym komputerze. Aby wyświetlić więcej informacji, takich jak węzeł hostujący pod oraz adres IP klastra poda, dodaj flagę -o wide do polecenia:

Oto dane wyjściowe z naszego klastra Kubernetes. W samouczku wstępnym utworzyliśmy wdrożenie serwera WWW Nginx, jak widać:

Kolumna IP pokazuje wewnętrzny adres IP poszczególnych podów. Jeśli pod, którego szukasz, nie pojawia się na liście, możesz znajdować się w innej przestrzeni nazw. Możesz wydać następujące polecenie, aby wyświetlić pody we wszystkich przestrzeniach nazw:

Pobieranie adresu IP usługi (Service)

Możesz również pobrać adres IP usługi (Service) w swoim klastrze. Dodając flagę --all-namespaces , otrzymasz wszystkie usługi uruchomione w klastrze:

Wynik powyższego polecenia jest następujący. Adres IP usługi znajduje się w kolumnie cluster-ip :

Pobieranie i uzyskiwanie dostępu do sieciowych przestrzeni nazw podów

Każdy pod Kubernetes ma przypisaną sieciową przestrzeń nazw. Sieciowe przestrzenie nazw, zwane również netns, to natywne biblioteki sieciowe w systemie Linux, które zapewniają izolację między urządzeniami sieciowymi.

Aby sprawdzić rozdzielczość DNS lub ogólną łączność sieciową, możesz uruchamiać polecenia w sieciowej przestrzeni nazw poda. Aby to osiągnąć, zacznij od wyszukania identyfikatora procesu (PID) jednego z kontenerów w podzie. Możesz to łatwo zrobić w Docker przy użyciu poleceń specyficznych dla platformy Docker. Pierwsze polecenie wyświetla listę kontenerów uruchomionych na węźle. Zaloguj się na jeden ze swoich węzłów roboczych i uruchom następujące polecenie:

W danych wyjściowych interesuje nas kolumna z identyfikatorem kontenera (container ID) lub nazwami (Names). Zwróć uwagę na kontener Nginx, który wdrożyliśmy w samouczku wstępnym Jak zainstalować i używać Kubernetes na Ubuntu 20.04.

Następnie skopiuj identyfikator (ID) lub nazwę (Name) kontenera, ponieważ użyjemy ich w następnym poleceniu, aby znaleźć identyfikator procesu:

Zastąp wyróżnioną część wartością skopiowaną z poprzedniego polecenia. Poniżej znajduje się wynik, który otrzymaliśmy, czyli identyfikator procesu:

Teraz, gdy mamy identyfikator procesu, możemy go użyć do uruchomienia polecenia nsenter wewnątrz sieciowej przestrzeni nazw procesu:

Zastąp wyróżnioną część identyfikatorem procesu otrzymanym w poprzednim poleceniu. Następnie w miejsce ip addr, możesz wstawić dowolne polecenie, które chcesz uruchomić w sieciowej przestrzeni nazw poda. Możesz je również uruchomić z sudo, jeśli otrzymasz błąd braku uprawnień (permission denied).

Polecenie nsenter pozwala na uruchomienie szerszego zakresu poleceń dostępnych na węźle, w przeciwieństwie do użycia docker exec które ogranicza Cię tylko do poleceń zainstalowanych wewnątrz kontenera.

Pobieranie wirtualnego interfejsu ethernetowego poda

Sieciowa przestrzeń nazw w podzie komunikuje się z głównym netns węzła za pomocą wirtualnego tunelu ethernetowego (pipe). Po stronie węzła ten tunel pojawia się jako urządzenie, którego nazwa zaczyna się od veth i kończy się unikalnym identyfikatorem, takim jak veth742f721 lub veth90. Podczas gdy wewnątrz poda tunel ten identyfikuje się jako eth0.

Możesz chcieć dowiedzieć się, które urządzenie veth jest sparowane z konkretnym podem. Możesz zacząć od wyświetlenia listy wszystkich urządzeń sieciowych na węźle, a następnie wyświetlić listę wszystkich urządzeń w sieci poda. Aby zidentyfikować, które urządzenie veth jest sparowane z konkretnym podem, możesz skorelować numery urządzeń między tymi dwiema listami.

Użyj polecenia nsenter do uruchomienia polecenia ip addr w sieciowej przestrzeni nazw poda. Będziesz musiał znać identyfikator procesu (PID) jednego z kontenerów. W tym celu zapoznaj się z poprzednią sekcją dotyczącą Pobierania i uzyskiwania dostępu do sieciowych przestrzeni nazw podów.

Następnie wykonaj następujące polecenie w terminalu węzła roboczego (worker node), odpowiednio zastępując wyróżnioną część:

Polecenie wyświetli listę interfejsów poda:

Zwróć uwagę na if7 znaki po eth0@ w powyższym wyjściu. Oznacza to, że eth0 poda jest sparowany z 7. interfejsem węzła. Następnie wyświetl listę interfejsów w domyślnej przestrzeni nazw węzła, uruchamiając polecenie ip addr :

Polecenie wyświetla listę interfejsów w sposób pokazany poniżej:

W wyjściu siódmym interfejsem jest veth254b50e6@if3  – wirtualny tunel ethernetowy sparowany z podem, który testujemy.

Przeglądanie reguł Iptables

Możesz wykonać polecenie iptables-save , aby wyświetlić listę wszystkich reguł iptables na węźle:

Wynik polecenia może być długi, więc możesz zapisać go do pliku w celu późniejszej analizy:

Możesz również użyć less do stronicowania wyniku:

Ponieważ interesują nas tylko reguły NAT Kubernetes, dodaj flagę -L , aby określić właściwy cel:

Oto wynik:

Sprawdzanie szczegółów IPVS

Kube-proxy to sieciowy serwer proxy działający na każdym węźle w klastrze Kubernetes. Może być używany do konfiguracji IPVS w celu obsługi translacji wirtualnych adresów IP usług (Service IPs) na adresy IP podów. Aby wyświetlić tabelę translacji adresów IP, możesz użyć polecenia ipvsadm . Najpierw musisz zainstalować je na swoim węźle:

Teraz możesz wykonać następujące polecenie:

Aby wyświetlić pojedynczy adres IP usługi, dodaj flagę -t , określając żądany adres IP:

Odpytywanie DNS klastra

Istnieje kilka sposobów na debugowanie rozwiązywania nazw DNS w klastrze. Oficjalna dokumentacja opisuje jeden ze sposobów polegający na wdrożeniu kontenera debugującego ze wszystkimi niezbędnymi narzędziami, a następnie użyciu kubectl do wykonania nslookup.

Opcjonalnie możesz odpytać DNS za pomocą poleceń dig oraz nsenter bezpośrednio z samego węzła. Najpierw musisz zainstalować dig na swoim węźle nadrzędnym (master node). W przypadku systemu Ubuntu zainstaluj je za pomocą polecenia apt :

Wróć do terminala na lokalnym komputerze i uruchom poniższe polecenie, aby znaleźć adres IP klastra dla usługi kube-dns :

Polecenie wyświetla:

Kolumna cluster-ip zawiera potrzebną nam wartość. Teraz możemy użyć nsenter do uruchomienia dig w przestrzeni nazw kontenera. Będziesz jednak potrzebować identyfikatora procesu kontenera (PID), aby uzyskać dostęp do jego przestrzeni nazw. Zapoznaj się z sekcją Pobieranie i uzyskiwanie dostępu do sieciowych przestrzeni nazw podów powyżej, aby uzyskać wskazówki.

Gdy masz już container-id, wykonaj następujące polecenie na swoim węźle nadrzędnym (master node):

Polecenie dig przyjmuje adres IP usługi DNS klastra ( @10.96.0.10) i wyszukuje pełną nazwę domenową usługi service-name.namespace.svc.cluster.local:

Aby uzyskać informacje na temat znajdowania nazw usług i przestrzeni nazw, zapoznaj się z sekcją Pobieranie adresu IP usługi.

Przeglądanie śledzenia połączeń Conntrack

Możesz użyć polecenia conntrack , aby wyświetlić wszystkie aktualnie śledzone połączenia:

Wyświetla wynik podobny do zrzutu ekranu:

Dodaj flagę -E , aby stale monitorować przychodzące połączenia:

Aby wyświetlić połączenia śledzone do określonego adresu docelowego, dodaj flagę -d i określ adres docelowy:

Czasami tabela śledzenia połączeń ulega przepełnieniu, co skutkuje odrzucaniem nowych połączeń. Powoduje to problemy uniemożliwiające węzłom nawiązywanie niezawodnych połączeń. Jeśli tak się stanie, w logach systemowych, w lokalizacji , zobaczysz komunikaty takie jak poniższy:/var/log/syslog:

Istnieje ustawienie systemowe określające maksymalną liczbę śledzonych połączeń. Użyj następującego polecenia, aby wyświetlić bieżącą wartość:

Wynik:

Możesz zmodyfikować tę wartość za pomocą -w flagi:

Możesz chcieć zmodyfikować swój plik /etc/sysctl.conf , aby uczynić tę wartość trwałą i zapewnić jej zachowanie po ponownym uruchomieniu. Otwórz plik za pomocą nano:

Następnie zmodyfikuj wartość, jeśli ta linia istnieje, lub dodaj linię na końcu pliku, określając nową wartość:

Podsumowanie

Podczas wdrażania wielu skonteneryzowanych usług odniesiesz ogromne korzyści z Kubernetes, ponieważ zapewnia on centralny punkt zarządzania. Aby zapewnić łączność między różnymi podami Kubernetes, przedstawiliśmy kilka poleceń inspekcji sieci, których można użyć do rozwiązywania problemów związanych z infrastrukturą Kubernetes.

Aby dowiedzieć się więcej o Kubernetes, jego zaletach, konfiguracji i wdrażaniu aplikacji na Kubernetes, zapoznaj się z naszymi różnymi samouczkami dotyczącymi Kubernetes.

Miłej pracy!