Kubernetes w mojej pracy: kiedy ma sens i jak go używam

2026-09-10

Kubernetes ma problem z reputacją: połowa branży traktuje go jak odznakę, druga połowa jak podatek. Dla mnie to narzędzie z jasnym momentem zastosowania. Strona marketingowa lub MVP świetnie działa na jednym serwerze z menedżerem procesów i zadaniem CI — tak wdrażana jest właśnie ta strona. Kubernetes zaczyna mieć sens, gdy usług jest kilka, obciążenie się waha, a na tę samą infrastrukturę wdraża więcej niż jeden zespół.

Wszystko zaczyna się od kontenera. Wieloetapowe Dockerfile, mały obraz runtime bez zależności deweloperskich, użytkownik inny niż root, jeden proces w kontenerze. Aplikacja Next.js jest budowana w trybie standalone; API NestJS zawiera tylko dist i produkcyjne node_modules. Ten sam obraz trafia z CI na staging, a potem na produkcję. Zmienia się wyłącznie konfiguracja — przez zmienne środowiskowe, ConfigMapy i Secrety — nigdy nie budujemy osobnego obrazu dla każdego środowiska.

Na co dzień używam niewielu obiektów: Deploymentu dla każdej usługi, stojącego przed nią Service, Ingressu z TLS dla ruchu publicznego oraz HorizontalPodAutoscalera dla elementów, których obciążenie naprawdę skacze. Każdy kontener ma requests i limits zasobów — bez nich scheduler zgaduje. Sondy readiness i liveness są celowo osobne: readiness mówi „jeszcze nie kieruj do mnie ruchu”, liveness — „uruchom mnie ponownie”. Pomylenie ich zmienia wolną bazę danych w burzę restartów. Każda usługa Node.js obsługuje też SIGTERM i kończy rozpoczęte żądania, żeby rolling update nie przerwał płatności w połowie.

Nie wszystko jest serwerem WWW. Workery kolejek działają we własnych Deploymentach i skalują się według zaległości w kolejce, nie użycia CPU. Zadania cykliczne — raporty, czyszczenie, uzgadnianie danych z operatorem płatności — działają jako CronJoby z concurrencyPolicy: Forbid, by wolne uruchomienie nie nakładało się na kolejne. Migracje bazy są osobnym Jobem przed wdrożeniem, a nie częścią startu aplikacji: pięć replik uruchomionych jednocześnie nie powinno równolegle migrować schematu. PostgreSQL wolę mieć jako usługę zarządzaną, np. RDS, zamiast StatefulSetu — klaster jest dla usług bezstanowych.

Manifesty są w Git i podlegają przeglądowi jak kod. Wdrażamy je przez pipeline CI z Helm lub Kustomize albo przez GitOps z Argo CD, więc rollback to revert, a nie nocna sesja z kubectl. kubectl apply z laptopa służy do nauki, nie do produkcji. Logi trafiają na stdout, a potem do centralnego magazynu; metryki — do Prometheus i Grafany. Przebieg wdrożenia śledzę przez kubectl rollout status, zamiast liczyć na szczęście. Na AWS oznacza to zwykle EKS z zarządzanymi grupami węzłów, by zespół zajmował się produktem, a nie control plane.

Nie używam Kubernetes do dwustronicowej witryny, service mesha zanim pojawią się usługi, sekretów jako jawnego YAML-a w repozytorium ani podów bez limitów tylko dlatego, że „działało na stagingu”. Jeśli nie wiesz, czy potrzebujesz klastra, wyślij mi listę usług, ruch i wielkość zespołu. Szczerze powiem, czy wybrać Kubernetes, kilka kontenerów na jednym hoście, czy platformę w rodzaju Vercel — i ile mniej więcej miesięcznie kosztuje każda opcja.

Daj kolejnemu produktowi kogoś, kto zostanie.

Chcesz zacząć? Napisz do mnie — mogę rozpocząć od razu i zostać na dłużej. Długoterminowa współpraca, nie przekazanie projektu po dwóch tygodniach. Omówmy projekt, wymagania i najlepszy sposób realizacji.

Zapytaj o doświadczenie lub usługi