Pody i Węzły

Naucz się rozwiązywać problemy z aplikacjami działającymi w Kubernetesie, korzystając z kubectl get, kubectl describe, kubectl logs i kubectl exec.

Cele

  • Poznać Pody Kubernetes.
  • Poznać węzły Kubernetes.
  • Nauczyć się rozwiązywać problemy z aplikacjami.

Pody Kubernetes

Po stworzeniu Deploymentu w Module 2, Kubernetes stworzył Pod, który "przechowuje" instancję Twojej aplikacji. Pod jest obiektem abstrakcyjnym Kubernetes, 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 Kubernetes, 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.

Podsumowanie:

  • Pody
  • Węzły
  • Główne polecenia Kubectl

Pod to grupa jednego lub wielu kontenerów aplikacji (jak np. Docker) zawierających współdzieloną przestrzeń dyskową (volumes), adres IP i informacje, jak mają być uruchamiane.


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

Kontenery powinny być uruchamiane razem w jednym podzie, jeśli są ściśle ze sobą związane i muszą współdzielić zasoby, np. dysk.


Schemat węzła


Rozwiązywanie problemów przy pomocy kubectl

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

Węzeł jest maszyną roboczą Kubernetes - fizyczną lub wirtualną, zależnie od klastra. Wiele podów może być uruchomionych na tym samym węźle.

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.

Uwaga: komenda describe może być używana do uzyskania szczegółowych informacji o większości obiektów Kubernetesa, w tym o Węzłach, Podach i Deploymentach. Wyjście komendy describe jest zaprojektowane tak, aby było czytelne dla ludzi, a nie do wykorzystania w skryptach.

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.

Przeglądanie dzienników kontenera

Wszystko, co aplikacja normalnie wysyłałaby do standardowego wyjścia, staje się logami dla kontenera wewnątrz Poda. Możemy pobrać te logi za pomocą polecenia kubectl logs:

kubectl logs "$POD_NAME"

Uwaga: Nie musimy określać nazwy kontenera, ponieważ wewnątrz poda mamy tylko jeden kontener.

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, uruchamiając polecenie curl:

curl http://localhost:8080

Uwaga: użyliśmy tutaj localhost, ponieważ wykonaliśmy polecenie wewnątrz Podu NodeJS. Jeśli nie możesz połączyć się z localhost:8080, upewnij się, że uruchomiłeś polecenie kubectl exec i wykonujesz polecenie z wnętrza Podu

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

Gdy będziesz gotowy, przejdź do rozdziału Jak używać Service do udostępniania aplikacji.

Ostatnia modyfikacja April 18, 2025 at 9:11 AM PST: [pl] sync explore-intro.html with the latest EN version (6cd17b56e4)