Kubernetes bez paniki: jak nie utopić się w konfiguracji już na starcie

Kontener działa idealnie lokalnie, a po wdrożeniu na produkcję zaczynają się problemy z pamięcią i tajemnicze restarty. Podpowiadamy, jak zrozumieć mechanizmy Kubernetesa, zanim zepsują wam weekend.

17 września 2026, 13:003 min czytania

Jak zacząć z Kubernetesem i nie zepsuć sobie weekendu?

Każdy, kto przechodził z lokalnego dockerowego środowiska na klaster produkcyjny, zna ten moment grozy: aplikacja hulała bez zająknięcia na laptopie, a chwilę po deployu zaczyna brakować pamięci albo kontener znika w środku nocy z powodu OOMKilled. Kubernetes miał to wszystko uprościć, automatyzując skalowanie i utrzymanie usług, jednak brak zrozumienia jego wewnętrznej logiki potrafi zamienić spokojny piątkowy wieczór w gaszenie pożaru.

Zmiana paradygmatu: myśl deklaratywnie

Osoby przesiadające się z Dockera najczęściej próbują sterować klastrem tak, jakby wciąż wydawały pojedyncze polecenia uruchomienia kontenera. Tymczasem Kubernetes działa inaczej: administrator opisuje w manifestach YAML pożądany stan systemu, a kontrolery klastra bez przerwy pilnują, by rzeczywistość mu odpowiadała.

Pod nie jest tożsamy z kontenerem – to najmniejsza jednostka uruchamiana w klastrze, która może grupować kilka kontenerów dzielących wspólną sieć (localhost) oraz wolumeny. Popularnym rozwiązaniem architektonicznym jest tu wzorzec Sidecar, czyli np. dodatkowy kontener zbierający logi obok głównej aplikacji.
Nie zakłada się Podów ręcznie w środowisku produkcyjnym – zamiast tego stosuje się obiekty wyższego rzędu, takie jak Deployment albo StatefulSet. Kiedy Pod ulegnie awarii, Deployment od razu odtworzy go na innym węźle, natomiast Pod utworzony bezpośrednio po prostu zniknie bezpowrotnie.
Adresy IP Podów są nietrwałe i zmieniają się przy każdym restarcie, dlatego rolę stabilnego punktu dostępu przejmuje obiekt Service, który dysponuje własnym, niezmiennym adresem wewnętrznym oraz wbudowanym mechanizmem równoważenia obciążenia na warstwie L4.

Ciekawostki i pułapki, na które trzeba uważać

Codzienna praca z Kubernetesem wiąże się z kilkoma zachowaniami systemu, które warto poznać, zanim zaskoczą nas na produkcji.

Limity pamięci działają inaczej niż limity procesora: przekroczenie ustawionego progu limits.memory kończy się natychmiastowym i bezceremonialnym ubiciem Poda przez jądro systemu (OOMKilled). Przekroczenie limits.cpu nie powoduje zabicia procesu – Kubernetes zaczyna wtedy mocno ograniczać przydział cykli procesora, co objawia się gwałtownym wzrostem opóźnień.
Wewnętrzne mechanizmy DNS potrafią zaskoczyć – za rozwiązywanie nazw w klastrze odpowiada komponent CoreDNS, a każdy Service otrzymuje adres w formacie <nazwa-usługi>.<namespace>.svc.cluster.local. Źle skonstruowane zapytanie DNS w kodzie aplikacji może wygenerować spory narzut sieciowy i przeciążyć CoreDNS.
Trzy rodzaje sond pełnią odmienne funkcje: Liveness Probe weryfikuje, czy aplikacja w ogóle żyje, a jej niepowodzenie kończy się zabiciem i restartem Poda. Readiness Probe sprawdza gotowość do obsługi ruchu – gdy zawiedzie, Pod jest usuwany z listy endpointów Service'u, ale nie jest restartowany.
Warto zapamiętać zasadę bezpieczeństwa: Liveness Probe nigdy nie powinna zależeć od zewnętrznego serwisu, na przykład bazy danych, bo jej awaria wywoła kaskadowy restart wszystkich Podów w klastrze jednocześnie.

Przydatne sztuczki w codziennej pracy z kubectl

Zamiast tworzyć rozbudowane komendy od podstaw, warto wypracować kilka nawyków, które realnie skracają czas spędzony w terminalu.

Manifesty można wygenerować bez tworzenia faktycznych zasobów – wystarczy dodać flagę --dry-run=client -o yaml, aby otrzymać gotowy szkielet pliku, np. kubectl create deployment moj-app --image=nginx --dry-run=client -o yaml > deployment.yaml.
Do szybkiego podglądu usługi ukrytej głęboko w klastrze, bez wystawiania jej publicznie, służy przekierowanie portu: kubectl port-forward svc/moj-service 8080:80 -n production.
Bieżące zużycie zasobów sprawdza się poleceniem kubectl top pods -n production, które od razu wskazuje, który Pod zużywa najwięcej pamięci lub mocy procesora.

Co dalej?

Warto mieć świadomość, że powyższe informacje to zaledwie ułamek całej wiedzy o Kubernetesie – mocno uproszczony zestaw absolutnych podstaw. Lektura kilku akapitów o Podach i sondach nie sprawi, że klaster sam poradzi sobie z awarią w piątek o siedemnastej, a pliki YAML nie zaczną pisać się same.

Osoby, które chcą zdobyć pogłębioną wiedzę techniczną i przećwiczyć pracę na klastrach w warunkach zbliżonych do bojowych, bez ryzyka dla realnej produkcji, mogą zapisać się na dwudniowe szkolenie „Wprowadzenie do Kubernetes” organizowane na sysopspolska.pl.