W poprzednim module uruchomiliśmy nasz pierwszy klaster. Mamy więc działającą “fabrykę”, ale na razie niczego ona nie produkuje. Czas to zmienić!

W Kubernetesie nie uruchamiamy kontenerów bezpośrednio, tak jak robiliśmy to za pomocą docker run. Zamiast tego, “opakowujemy” je w bardziej abstrakcyjne obiekty, które pozwalają Kubernetesowi inteligentnie nimi zarządzać. W tej lekcji poznamy trzy najważniejsze, fundamentalne obiekty: Pod, Deployment i Service.

1. Pod: Atomowa jednostka wdrożenia

Pod to najmniejsza i najbardziej podstawowa jednostka, jaką można stworzyć i zarządzać w Kubernetesie.

Wyobraź sobie Poda jako “otoczkę” dla jednego lub kilku ściśle powiązanych ze sobą kontenerów.

Kluczowe cechy Poda:

  • Jest to najmniejszy “atom” w świecie K8s. Wszystko, co uruchamiasz, działa wewnątrz Poda.
  • Kontenery w jednym Podzie dzielą te same zasoby sieciowe (mogą komunikować się ze sobą przez localhost) oraz te same woluminy (przestrzeň dyskową).
  • Dobra praktyka: W 99% przypadków w jednym Podzie umieszcza się jeden kontener. Model “wiele kontenerów w jednym Podzie” jest zarezerwowany dla zaawansowanych scenariuszy, gdzie kontenery muszą działać w nierozerwalny sposób (tzw. sidecar pattern).

Ważne: Rzadko kiedy tworzymy Pody ręcznie. Traktujemy je jako efemeryczne (ulotne) byty, które mogą być w każdej chwili zniszczone i odtworzone. Do zarządzania ich cyklem życia używamy obiektów wyższego poziomu, takich jak Deployment.

2. Deployment: Twój menedżer aplikacji

Skoro Pody są ulotne, potrzebujemy czegoś, co będzie pilnować, aby nasza aplikacja zawsze działała w pożądanej przez nas liczbie kopii. I tym właśnie jest Deployment.

Deployment to obiekt, który zarządza zestawem identycznych Podów. Jego główne zadania to:

  • Utrzymywanie pożądanego stanu: Mówisz mu: “Chcę, aby zawsze działały 3 repliki (kopie) Poda z moją aplikacją”. Deployment będzie stale pilnował, aby tak właśnie było. Jeśli jeden z Podów ulegnie awarii, Deployment automatycznie stworzy nowy na jego miejsce.
  • Zarządzanie aktualizacjami (Rollouts): Kiedy chcesz wdrożyć nową wersję aplikacji, Deployment robi to w inteligentny, kontrolowany sposób. Domyślnie stosuje strategię Rolling Update, czyli stopniowo zastępuje stare Pody nowymi, jeden po drugim. Dzięki temu Twoja aplikacja jest dostępna bez żadnych przerw w działaniu.
  • Zarządzanie powrotami do poprzedniej wersji (Rollbacks): Jeśli po aktualizacji okaże się, że nowa wersja ma błąd, jedno polecenie wystarczy, aby Deployment przywrócił poprzednią, stabilną wersję aplikacji.

Deployment to nasz główny koń roboczy do wdrażania aplikacji bezstanowych (takich jak serwery WWW, API itp.).

3. Service: Stabilny adres dla Twojej aplikacji

Mamy już Deployment, który dba o to, by nasze Pody działały. Ale pojawia się problem: Pody, jak już wiemy, są ulotne. Mogą być niszczone, tworzone na nowo, a każdy nowy Pod dostaje nowy, wewnętrzny adres IP.

Jak więc inne części naszej aplikacji (lub użytkownicy z zewnątrz) mogą się z nimi niezawodnie połączyć?

Rozwiązaniem jest Service.

Service to obiekt, który tworzy stabilny, wirtualny punkt dostępowy dla grupy Podów. Można go postrzegać jako wewnętrzny load balancer (system równoważenia obciążenia) i serwer DNS w jednym.

Jak to działa?

  1. Definiujesz Service, który wyszukuje Pody na podstawie ich etykiet (np. wszystkie Pody z etykietą app: moj-serwer-www).
  2. Service otrzymuje własny, stabilny adres IP wewnątrz klastra i stałą nazwę DNS.
  3. Kiedy jakikolwiek ruch sieciowy trafia na adres Service’u, ten automatycznie przekierowuje go do jednego ze zdrowych Podów, które pasują do selektora etykiet.

Dzięki temu inne aplikacje nie muszą znać adresów IP poszczególnych Podów. Komunikują się tylko ze stałym adresem Service’u, a Kubernetes martwi się resztą.

Jak to wszystko działa razem?

Podsumujmy przepływ pracy dla typowej aplikacji:

  1. Tworzysz Deployment, w którym opisujesz, jaki obraz kontenera ma być użyty i ile replik (Podów) chcesz uruchomić.
  2. Deployment tworzy i nadzoruje Pody, zapewniając, że ich liczba zawsze zgadza się z pożądanym stanem.
  3. Tworzysz Service, aby “wystawić” te Pody pod jednym, stałym adresem sieciowym, umożliwiając komunikację z nimi.

Wskazówka: Warto zwizualizować tę relację. Deployment zarządza Podami, a Service kieruje do nich ruch.

Podsumowanie

Zapamiętaj role tej “świętej trójcy” Kubernetesa:

  • Pod: Uruchamia Twój kontener (lub kontenery).
  • Deployment: Dba o to, by Pody działały i zarządza ich aktualizacjami.
  • Service: Zapewnia stabilny sposób komunikacji z Twoimi Podami.

Zrozumienie relacji między tymi trzema obiektami to 80% sukcesu w pracy z Kubernetesem. W następnej lekcji w końcu napiszemy nasz pierwszy plik YAML, aby stworzyć te obiekty i wdrożyć naszą pierwszą aplikację w Minikube!