Czym jest Kubernetes i jak działa orkiestracja kontenerów?

Czym jest Kubernetes?

Kubernetes to otwartoźródłowa platforma do zarządzania skonteneryzowanymi aplikacjami i usługami. Oficjalna dokumentacja definiuje go jako „przenośną, rozszerzalną, otwartoźródłową platformę do zarządzania skonteneryzowanymi obciążeniami i usługami, która ułatwia zarówno deklaratywną konfigurację, jak i automatyzację".

Kluczowe jest zrozumienie, czym Kubernetes nie jest. To nie model AI ani narzędzie do budowania obrazów kontenerów. To nie jest też klasyczna platforma PaaS (Platform as a Service) — dokumentacja wprost zaznacza, że „Kubernetes nie jest tradycyjnym, wszechstronnym systemem PaaS". Najprościej opisać go jako warstwę orkiestracji kontenerów^?orkiestracji kontenerów: automatyczne rozmieszczanie, skalowanie i utrzymywanie wielu kontenerów na wielu maszynach: system, który koordynuje pracę wielu kontenerów rozłożonych na wielu maszynach, tak by aplikacja działała stabilnie, skalowała się i sama naprawiała po awariach. Sam Kubernetes nie uruchamia kontenerów bezpośrednio — do tego potrzebuje osobnego środowiska uruchomieniowego (container runtime^?container runtime: oprogramowanie, które faktycznie uruchamia kontenery na maszynie, np. containerd lub CRI-O).

Nazwa pochodzi z greki i oznacza „sternika" lub „pilota". Popularny skrót „K8s" bierze się z ośmiu liter między „K" a „s".

Kto za tym stoi?

Kubernetes wywodzi się z Google. Firma udostępniła projekt jako otwartoźródłowy w 2014 roku, a według dokumentacji łączy on „ponad 15 lat doświadczeń Google w uruchamianiu obciążeń produkcyjnych na dużą skalę". Bezpośrednim przodkiem Kubernetesa był wewnętrzny system Google o nazwie Borg, który zarządzał uruchamianiem usług firmy na masową skalę.

Dziś projekt nie należy już do Google. W marcu 2016 roku Kubernetes został przekazany do Cloud Native Computing Foundation (CNCF) — fundacji działającej pod skrzydłami Linux Foundation, która pełni rolę neutralnego opiekuna kluczowych projektów ekosystemu „cloud native". 6 marca 2018 roku Kubernetes stał się, jak podaje CNCF, „pierwszym projektem CNCF, który osiągnął status Graduated" — czyli najwyższy poziom dojrzałości. Oznacza to, że rozwój Kubernetesa jest dziś prowadzony przez rozproszoną, wielofirmową społeczność, a nie pojedynczą korporację.

Jak to działa?

Fundamentem działania Kubernetesa jest model stanu pożądanego (desired state) i pętli uzgadniania (reconciliation).

Użytkownik nie wydaje systemowi poleceń typu „uruchom teraz ten kontener na tej maszynie". Zamiast tego deklaruje pożądany stan: na przykład „chcę, żeby zawsze działały trzy kopie tej aplikacji". Kubernetes przyjmuje tę deklarację i sam dba o to, by rzeczywistość jej odpowiadała.

Stan pożądany najczęściej opisuje się w plikach YAML zawierających deklarację zasobów klastra. Prosty manifest Deploymentu może wyglądać tak:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sklep
spec:
  replicas: 3

Pole replicas: 3 deklaruje, że kontroler Deploymentu powinien utrzymywać trzy repliki aplikacji — to jeden z elementów stanu pożądanego opisanego w manifeście. Desired state obejmuje jednak nie tylko liczbę replik, lecz także obraz kontenera, porty, zasoby, zmienne środowiskowe i inne elementy specyfikacji.

Odpowiadają za to kontrolery (controllers) — procesy działające w nieskończonej pętli. Każdy kontroler nieustannie obserwuje aktualny stan klastra przez centralne API, porównuje go z zadeklarowanym stanem pożądanym i podejmuje działania, które zbliżają jedno do drugiego. Jeśli zadeklarowano trzy kopie aplikacji, a jedna z nich ulegnie awarii, kontroler wykryje różnicę i utworzy nową kopię. Dokumentacja opisuje to jako „zestaw niezależnych, komponowalnych procesów sterujących, które nieustannie prowadzą stan bieżący w kierunku stanu pożądanego".

Ten mechanizm jest źródłem najważniejszych cech Kubernetesa — samonaprawy i automatyzacji. System nie czeka na interwencję administratora — sam reaguje na awarie węzłów, padające kontenery czy zmiany obciążenia.

Z jakich elementów się składa?

Klaster Kubernetes dzieli się na dwie warstwy: płaszczyznę sterowania (control plane), która podejmuje globalne decyzje, oraz węzły robocze (nodes), które uruchamiają właściwe aplikacje.

Prześledźmy, co dzieje się po drodze. Gdy użytkownik wysyła manifest YAML, trafia on najpierw do kube-apiserver. Informacja zostaje zapisana w etcd, następnie scheduler wybiera odpowiedni węzeł, a kubelet uruchamia na nim kontenery. Nad całością czuwają kontrolery, które stale pilnują zgodności rzeczywistego stanu z zadeklarowanym. Poniższa lista pokazuje, kto jest kim w tym łańcuchu.

Płaszczyzna sterowania

• kube-apiserver — front-end całej płaszczyzny sterowania. Udostępnia API Kubernetesa, przez które przechodzą wszystkie operacje.
• etcd — spójna, wysokodostępna baza klucz-wartość, w której przechowywany jest cały stan klastra. Dokumentacja podkreśla, że w środowiskach produkcyjnych wymaga ona planu tworzenia kopii zapasowych.
• kube-scheduler — obserwuje nowo utworzone pody, którym nie przypisano jeszcze węzła, i dobiera dla nich odpowiedni węzeł, uwzględniając m.in. wymagania zasobowe i ograniczenia sprzętowe.
• kube-controller-manager — uruchamia wspomniane kontrolery (m.in. kontroler węzłów, zadań i kont usługowych), skompilowane dla uproszczenia w jeden proces.
• cloud-controller-manager — opcjonalny komponent osadzający logikę specyficzną dla danego dostawcy chmury.

Węzły robocze

• kubelet — agent pilnujący, by kontenery opisane w specyfikacji podów faktycznie działały i były zdrowe.
• kube-proxy — proxy sieciowe utrzymujące reguły sieciowe umożliwiające komunikację z podami (opcjonalne, jeśli wtyczka sieciowa realizuje tę funkcję samodzielnie).
• container runtime — właściwe środowisko uruchomieniowe kontenerów, np. containerd lub CRI-O.

Podstawowe obiekty

Podstawowe obiekty, którymi operuje użytkownik, to przede wszystkim Pod — „zbiór jednego lub więcej działających kontenerów", i zarazem najmniejsza jednostka, którą można wdrożyć. Zamiast zarządzać podami ręcznie, korzysta się z zasobów wyższego poziomu: Deployment (dla bezstanowych aplikacji, gdzie pody są wymienne), StatefulSet (dla aplikacji zachowujących stan, np. baz danych), DaemonSet (uruchamia poda na każdym węźle) oraz Job i CronJob (zadania jednorazowe i cykliczne).

Równie ważna jest grupa obiektów sieciowych i organizacyjnych. Service zapewnia podom stały adres i równoważy ruch między nimi wewnątrz klastra, natomiast Ingress (lub nowsze Gateway API) umożliwia publikację usług na zewnątrz. Z kolei Namespace pozwala logicznie podzielić jeden klaster na odseparowane obszary — na przykład dla różnych zespołów lub środowisk.

Do czego może być używane?

Kubernetes automatyzuje zadania, które przy ręcznym zarządzaniu setkami kontenerów byłyby nie do udźwignięcia. Dokumentacja wymienia wprost jego kluczowe zastosowania:

• Odkrywanie usług i równoważenie obciążenia — Kubernetes może udostępnić kontener pod nazwą DNS lub własnym adresem IP i rozłożyć ruch sieciowy tak, by wdrożenie pozostało stabilne.
• Automatyczne wdrożenia i wycofywanie zmian — system stopniowo doprowadza stan aplikacji do zadeklarowanego, a w razie problemu potrafi wycofać zmianę.
• Samonaprawa — restartuje kontenery, które uległy awarii, wymienia je i zabija te, które nie przechodzą zdefiniowanych testów kondycji.
• Skalowanie poziome — liczbę kopii aplikacji można zwiększać i zmniejszać komendą, przez interfejs lub automatycznie na podstawie zużycia CPU (mechanizm Horizontal Pod Autoscaler, HPA).
• Automatyczne upakowanie zasobów (bin packing), orkiestracja pamięci masowej oraz zarządzanie sekretami i konfiguracją (hasła, tokeny, klucze SSH).

Najlepiej widać to na prostym przykładzie. Wyobraźmy sobie sklep internetowy działający na pięciu serwerach. W normalnym ruchu wystarczają trzy kopie aplikacji, ale w czasie Black Friday zapotrzebowanie rośnie dziesięciokrotnie. Kubernetes może wtedy automatycznie zwiększyć liczbę kopii do trzydziestu, rozłożyć je na dostępnych węzłach, a po zakończeniu promocji ponownie zmniejszyć ich liczbę — bez ręcznej interwencji.

W praktyce Kubernetes jest fundamentem architektury mikroserwisowej^?architektury mikroserwisowej: styl budowy aplikacji z wielu małych, niezależnie wdrażanych usług, platform CI/CD, systemów przetwarzania danych, a coraz częściej także treningu i serwowania modeli AI — z pomocą platform takich jak Kubeflow^?Kubeflow: otwartoźródłowa platforma do uruchamiania procesów uczenia maszynowego (ML) na Kubernetes — od przygotowania danych, przez trening, po wdrożenie modeli czy KServe^?KServe: otwartoźródłowy komponent do serwowania modeli ML na Kubernetes jako skalowalne usługi inferencyjne, z autoskalowaniem (także do zera) — gdzie zapewnia orkiestrację zasobów obliczeniowych.

Czym różni się od innych rozwiązań?

Najczęstsze nieporozumienie dotyczy relacji Kubernetes–Docker. To nie są konkurenci działający na tym samym poziomie. Docker jest przede wszystkim narzędziem do budowania, pakowania i lokalnego uruchamiania kontenerów. Kubernetes działa piętro wyżej — zarządza wieloma kontenerami rozproszonymi po wielu maszynach, a do samego ich uruchamiania potrzebuje środowiska uruchomieniowego. W klastrach Kubernetes rolę tę pełnią dziś najczęściej containerd lub CRI-O, z którymi Kubernetes komunikuje się przez Container Runtime Interface (CRI). Wsparcie dla Dockera poprzez warstwę pośrednią (dockershim) zostało usunięte w Kubernetes 1.24. To relacja komplementarna, nie konkurencyjna.

Na tle pokrewnych podejść różnice widać najlepiej w zestawieniu:

Istotna jest też filozofia projektu. Dokumentacja podkreśla, że „Kubernetes nie jest monolityczny", a domyślne rozwiązania są „opcjonalne i wymienne". Kubernetes dostarcza „klocki do budowy platform deweloperskich, ale zachowuje wybór i elastyczność tam, gdzie to istotne". Nie narzuca więc konkretnego rozwiązania do logowania, monitoringu czy CI/CD — te dobiera się samodzielnie.

Najważniejsze ograniczenia i wyzwania

Największym wyzwaniem Kubernetesa jest jego złożoność. Elastyczność, która jest jego siłą, ma cenę: liczba pojęć, komponentów i opcji konfiguracyjnych sprawia, że wdrożenie i utrzymanie klastra produkcyjnego wymaga specjalistycznej wiedzy. To realny koszt operacyjny — zarówno w postaci czasu zespołu, jak i ryzyka błędnej konfiguracji.

Kubernetes świadomie nie dostarcza wielu rzeczy w komplecie. Nie ma wbudowanego CI/CD, nie narzuca rozwiązania do logowania, monitoringu ani alertowania, nie dostarcza baz danych czy cache'y jako usług. Wszystko to trzeba dobrać i zintegrować samodzielnie, co dodatkowo podnosi próg wejścia.

Wrażliwym punktem jest etcd — baza przechowująca cały stan klastra. Jej utrata bez kopii zapasowej oznacza utratę stanu całego klastra, dlatego dokumentacja wprost wskazuje na konieczność planu backupu. Warto też pamiętać o modelu awarii podów: krytyczna awaria węzła oznacza, że wszystkie działające na nim pody przepadają — Kubernetes traktuje to jako stan ostateczny i tworzy nowe pody zamiast wskrzeszać stare.

Dlaczego to jest istotne?

Kubernetes przestał być „jedną z opcji" i stał się faktycznym standardem branżowym dla orkiestracji kontenerów. Jego status pierwszego projektu, który ukończył ścieżkę dojrzałości w CNCF, nie jest tylko formalnością — to sygnał, że cały ekosystem cloud native zaczął organizować się wokół niego. Dla osoby wchodzącej w świat nowoczesnej infrastruktury oznacza to, że Kubernetes jest dziś umiejętnością bazową, podobnie jak kiedyś znajomość systemu Linux.

Jego znaczenie wykracza poza samo uruchamianie aplikacji webowych. Deklaratywny model „stanu pożądanego" okazał się na tyle uniwersalny, że stał się wzorcem projektowym dla zarządzania niemal dowolnymi zasobami — od sieci po infrastrukturę AI. To właśnie na Kubernetesie coraz częściej opiera się trening i serwowanie modeli uczenia maszynowego, gdzie orkiestracja tysięcy zadań obliczeniowych jest kluczowa.

Kubernetes najlepiej rozumieć nie jako narzędzie, lecz jako fundament — warstwę, która ukrywa złożoność zarządzania rozproszonymi kontenerami i pozwala opisywać infrastrukturę deklaratywnie. To właśnie ta zmiana sposobu myślenia — od „jak to uruchomić" do „jaki stan chcę osiągnąć" — jest jego najtrwalszym wkładem w branżę.

Źródła

• Kubernetes — Overview / Definicja i przeznaczenie — link
• Kubernetes — Cluster Architecture (komponenty i kontrolery) — link
• Kubernetes — Workloads (Pody, Deployment, StatefulSet, Job) — link
• Kubernetes — What is Kubernetes (filozofia, granice) — link
• Kubernetes Blog — Dockershim removal FAQ (CRI, usunięcie w 1.24) — link
• CNCF — Kubernetes project (daty przyjęcia i graduacji) — link
• CNCF — Kubernetes: CNCF's first graduated project — link