Pody i Węzły

Cele

• Zrozumieć, jak działają Pody Kubernetesa.
• Zrozumieć, jak działają węzły Kubernetesa.
• Nauczyć się rozwiązywać problemy z aplikacjami.

Pody Kubernetesa

Po stworzeniu Deploymentu w Module 2, Kubernetes stworzył Pod, który "przechowuje" instancję Twojej aplikacji. Pod jest obiektem abstrakcyjnym Kubernetesa, który reprezentuje grupę jednego bądź wielu kontenerów (jak np. Docker) wraz ze wspólnymi zasobami dla tych kontenerów. Zasobami mogą być:

• Współdzielona przestrzeń dyskowa, np. Volumes
• Zasoby sieciowe, takie jak unikatowy adres IP klastra
• Informacje służące do uruchamiania każdego z kontenerów ⏤ wersja obrazu dla kontenera lub numery portów, które mają być użyte

Pod tworzy model specyficznego dla aplikacji "wirtualnego serwera" i może zawierać różne kontenery aplikacji, które są relatywnie blisko powiązane. Przykładowo, pod może zawierać zarówno kontener z Twoją aplikacją w Node.js, jak i inny kontener dostarczający dane, które mają być opublikowane przez serwer Node.js. Kontenery wewnątrz poda współdzielą adres IP i przestrzeń portów, zawsze są uruchamiane wspólnie w tej samej lokalizacji i współdzielą kontekst wykonawczy na tym samym węźle.

Pody są niepodzielnymi jednostkami na platformie Kubernetes. W trakcie tworzenia Deploymentu na Kubernetesa, Deployment tworzy Pody zawierające kontenery (w odróżnieniu od tworzenia kontenerów bezpośrednio). Każdy Pod związany jest z węzłem, na którym zostało zlecone jego uruchomienie i pozostaje tam aż do jego wyłączenia (zgodnie z polityką restartowania) lub skasowania. W przypadku awarii węzła, identyczny pod jest skierowany do uruchomienia na innym węźle klastra.

Schemat ogólny podów

Węzły

Pod jest uruchamiany na węźle (Node). Węzeł jest maszyną roboczą, fizyczną lub wirtualną, w zależności od klastra. Każdy z węzłów jest zarządzany przez warstwę sterowania (Control Plane). Węzeł może zawierać wiele podów. Warstwa sterowania Kubernetesa automatycznie zleca uruchomienie podów na różnych węzłach w ramach klastra. Automatyczne zlecanie uruchomienia bierze pod uwagę zasoby dostępne na każdym z węzłów.

Na każdym węźle Kubernetesa działają co najmniej:

• Kubelet, proces odpowiedzialny za komunikację pomiędzy warstwą sterowania Kubernetesa i węzłami; zarządza podami i kontenerami działającymi na maszynie.

• Proces wykonawczy kontenera (np. Docker), który zajmuje się pobraniem obrazu dla kontenera z repozytorium, rozpakowaniem kontenera i uruchomieniem aplikacji.

Schemat węzła

Rozwiązywanie problemów przy pomocy kubectl

W module Module 2 używałeś narzędzia Kubectl. W module 3 będziemy go nadal używać, aby wydobyć informacje na temat zainstalowanych aplikacji i środowiska, w jakim działają. Najczęstsze operacje przeprowadzane są przy pomocy następujących poleceń kubectl:

• kubectl get - wyświetl informacje o zasobach
• kubectl describe - pokaż szczegółowe informacje na temat konkretnego zasobu
• kubectl logs - wyświetl logi z kontenera w danym podzie
• kubectl exec - wykonaj komendę wewnątrz kontenera w danym podzie

Korzystaj z tych poleceń, aby sprawdzić, kiedy aplikacja została zainstalowana, jaki jest jej aktualny status, gdzie jest uruchomiona i w jakiej konfiguracji.

Kiedy już wiemy więcej na temat części składowych klastra i podstawowych poleceń, przyjrzyjmy się naszej aplikacji.

Sprawdzanie konfiguracji aplikacji

Sprawdźmy, czy aplikacja, którą wdrożyliśmy w poprzednim scenariuszu, działa. Użyjemy polecenia kubectl get i poszukamy istniejących Podów:

kubectl get pods

Jeśli żadne pody nie działają, poczekaj kilka sekund i ponownie wylistuj pody. Możesz kontynuować, gdy zobaczysz działający jeden pod.

Następnie, aby zobaczyć, jakie kontenery znajdują się w tym Podzie i jakie obrazy są używane do budowy tych kontenerów, uruchamiamy polecenie kubectl describe pods:

kubectl describe pods

Widzimy tutaj szczegóły dotyczące kontenera Pod: adres IP, używane porty oraz listę zdarzeń związanych z cyklem życia Poda.

Wyjście komendy describe jest obszerne i obejmuje niektóre pojęcia, których jeszcze nie omawialiśmy, ale nie martw się tym, bo staną się one zrozumiałe przed końcem tego bootcampu.

Pokazywanie aplikacji w terminalu

Pamiętaj, że Pody działają w izolowanej, prywatnej sieci - więc musimy przepuścić do nich dostęp, aby móc je debugować i wchodzić z nimi w interakcję. Aby to zrobić, użyjemy polecenia kubectl proxy, aby uruchomić proxy w drugim terminalu. Otwórz nowe okno terminala, a w tym nowym terminalu uruchom:

kubectl proxy

Teraz ponownie uzyskamy nazwę Poda i zapytamy ten pod bezpośrednio przez proxy. Aby uzyskać nazwę Poda i zapisać ją w zmiennej środowiskowej POD_NAME:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

Aby zobaczyć wyniki działania naszej aplikacji, wykonaj polecenie curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

URL jest ścieżką do API Poda.

Wykonywanie polecenia w kontenerze

Możemy wykonywać polecenia bezpośrednio na kontenerze po uruchomieniu i działaniu Poda. Do tego celu używamy podpolecenia exec i używamy nazwy Poda jako parametru. Wymieńmy zmienne środowiskowe:

kubectl exec "$POD_NAME" -- env

Warto ponownie wspomnieć, że nazwa samego kontenera może zostać pominięta, ponieważ w Podzie mamy tylko jeden kontener.

Następnie rozpocznijmy sesję bash w kontenerze Pod:

kubectl exec -ti $POD_NAME -- bash

Mamy teraz otwartą konsolę na kontenerze, w którym uruchamiamy naszą aplikację NodeJS. Kod źródłowy aplikacji znajduje się w pliku server.js:

cat server.js

Możesz sprawdzić, czy aplikacja działa, wykonując polecenie curl:

curl http://localhost:8080

Aby zamknąć połączenie z kontenerem, wpisz exit.

Co dalej?

• Samouczek Jak używać Service do udostępniania aplikacji.

• Dowiedz się więcej o Podach.

• Dowiedz się więcej o węzłach.