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

Zmiana paradygmatu: Myśl deklaratywnie

Najczęstszy błąd przy przejściu z Dockera do Kubernetesa to próba mikromanagementu. W Dockerze wydajesz polecenie “uruchom ten kontener”. W Kubernetesie definiujesz stan docelowy w manifestach YAML, a kontrolery klastra bezustannie dążą do jego utrzymania.

• Pod to nie sam kontener – pod jest najmniejszą jednostką wykonawczą. Może mieścić kilka kontenerów współdzielących przestrzeń sieciową (localhost) i wolumeny danych. Wzorzec Sidecar (np. kontener wysyłający logi obok kontenera aplikacji) to standard architektoniczny.
• Nie twórz Podów “z palca” –  produkcyjnie zawsze używaj obiektów wyższego poziomu, takich jak Deployment czy StatefulSet. Gdy Pod padnie, Deployment natychmiast powoła nowy na innym węźle. Zwykły Pod stworzony ręcznie po prostu zniknie.
• Ulotność i obiekty Service – IP Poda zmienia się przy każdym restarcie. Obiekt Service pełni rolę stabilnego punktu wejścia z własnym, stałym IP wewnętrznym oraz wbudowanym load balancingiem L4.

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

Praca z K8s w praktyce wiąże się z kilkoma nietrywialnymi zachowaniami, o których warto wiedzieć od pierwszego dnia:

• Pamięć RAM vs CPU (Limity i Żądania) – jeśli Twój Pod przekroczy zdefiniowany limit pamięci (limits.memory), kernel systemu ubije go bez ostrzeżenia (OOMKilled). Jeśli jednak przekroczy limit procesora (limits.cpu), Pod nie zostanie zabity – Kubernetes zacznie drastycznie przycinać mu cykle CPU (CPU throttling), co objawi się nagłym skokiem opóźnień (latency).
• Problemy z DNS wewnętrznym – kubernetes używa komponentu CoreDNS do rozwiązywania nazw wewnątrz klastra. Każdy Service otrzymuje adres typu <nazwa-usługi>.<namespace>.svc.cluster.local. Złe zapytanie DNS w kodzie aplikacji może wygenerować ogromny narzut sieciowy i zapychać CoreDNS.
• Kluczowe sondy (Liveness vs Readiness vs Startup):
• Liveness Probe: sprawdza, czy aplikacja żyje. Jeśli zawiedzie, K8s zabije i zrestartuje Pod.
• Readiness Probe: sprawdza, czy aplikacja jest gotowa przyjmować ruch. Jeśli zawiedzie, K8s usuwa Pod z endpoints Service’u, ale go nie restartuje.
• Dobra praktyka: nigdy nie ustawiaj Liveness Probe na zewnętrzny serwis (np. bazę danych), bo awaria bazy spowoduje masowy restart wszystkich Podów w klastrze jednocześnie (cascading failure)!

Przydatne sztuczki w daily work (kubectl)

Zamiast pisać długaśne komendy, warto wyrobić sobie nawyki, które oszczędzają mnóstwo czasu w terminalu:

• Generowanie manifestów bez tworzenia zasobów – nie pisz YAML-a od zera. Użyj flagi –dry-run=client -o yaml, by wygenerować szkielet: kubectl create deployment moj-app –image=nginx –dry-run=client -o yaml > deployment.yaml
• Szybki port-forward do debugowania – chcesz podglądnąć usługę działającą głęboko w klastrze bez wystawiania jej na świat? kubectl port-forward svc/moj-service 8080:80 -n production
• Podgląd zasobów w czasie rzeczywistym – kubectl top pods -n production – szybko wskaże, który Pod pożera najwięcej pamięci lub CPU.

Co dalej?

Powiedzmy sobie wprost: ten artykuł to tylko wierzchołek góry lodowej, mocne uproszczenie i zbiór najbardziej absolutnych basiców. Przeczytanie paru akapitów o Podach i sondażach nie sprawi magicznie, że Twój klaster sam ogarnie awarię w piątek o 17:00, a YAML-e zaczną pisać się same.

Jeśli chcesz dostać prawdziwe, nieokrojone mięso techniczne, dotknąć żywego organizmu i poćwiczyć na klastrach w warunkach bojowych bez ryzyka zaorania produkcji – zapisz się na pełne, dwudniowe szkolenie Wprowadzenie do Kubernetes na sysopspolska.pl. Gwarantujemy 100% praktyki, zerwanie z nudną teorią i dawkę wiedzy, po której Twoje weekendy w końcu będą naprawdę wolne – najbliższe szkolenie już 24-25 września!