Co to jest Kubernetes?

Kubernetes to otwartoźródłowa platforma do automatyzacji wdrażania, skalowania i zarządzania kontenerami. Projekt powstał wewnątrz Google, a w 2015 roku trafił pod opiekę Cloud Native Computing Foundation (CNCF). Dziś Kubernetes jest standardem branżowym w środowiskach produkcyjnych, od startupów po globalne korporacje.

Czym są kontenery i dlaczego wymagają orkiestracji?

Kontener działa podobnie do lekkiej maszyny wirtualnej, ale bez narzutu pełnego systemu operacyjnego. Izolacji podlegają tylko system plików, pamięć i procesy, dzięki mechanizmom takim jak namespaces i cgroups, a kontenery współdzielą jedno, natywne jądro systemu hosta. Dzięki temu kontenery startują szybciej, zużywają mniej zasobów i łatwiej przenoszą się między środowiskami.

Wyzwania przy skalowaniu i rola Dockera

Popularnym narzędziem do tworzenia i uruchamiania kontenerów jest Docker. Docker buduje obraz kontenera i uruchamia go na jednej maszynie. Problem pojawia się, gdy aplikacja rośnie i wymaga dziesiątek instancji rozłożonych na wiele serwerów. Kto decyduje, na którym serwerze uruchomić kolejny kontener? Kto restartuje ten, który padł? Kto rozdziela ruch między działające instancje?

Na czym polega orkiestracja kontenerów?

Odpowiedzią na te pytania jest orkiestracja kontenerów. Orkiestrator zarządza całym klastrem maszyn jak jednym zasobem obliczeniowym. Przydziela kontenery do węzłów, monitoruje ich stan, skaluje liczbę instancji i obsługuje awarie bez interwencji człowieka. Kubernetes jest dziś dominującym orkiestratorem kontenerów na rynku.

Bez orkiestracji zespół DevOps musiałby ręcznie śledzić, które kontenery działają, które padły i gdzie brakuje zasobów. Przy kilku kontenerach to wykonalne. Przy kilkuset staje się pełnoetatową pracą bez gwarancji sukcesu. Kubernetes przejmuje tę odpowiedzialność i wykonuje ją automatycznie, zgodnie z regułami zdefiniowanymi przez operatora.

Pochodzenie nazwy i skrót K8s

Sama nazwa pochodzi z języka greckiego i oznacza sternika lub pilota statku. Skrót K8s zastępuje osiem liter między “K” a “s” cyfrą 8. Oba zapisy funkcjonują równolegle w dokumentacji i społeczności.

Jak działa Kubernetes od środka?

Podział klastra: Control plane i Worker nodes

Kubernetes zarządza klastrem złożonym z węzłów. Węzeł to fizyczna lub wirtualna maszyna, na której działają kontenery. Klaster składa się z dwóch typów węzłów: węzłów sterujących (ang. control plane) i węzłów roboczych (ang. worker nodes).

Control plane podejmuje decyzje o stanie klastra. Przechowuje konfigurację, planuje rozmieszczenie kontenerów i reaguje na zmiany. Worker nodes wykonują faktyczną pracę, czyli uruchamiają kontenery z aplikacjami.

Pod jako podstawowa jednostka w Kubernetes

Podstawową jednostką w Kubernetes nie jest pojedynczy kontener, lecz Pod. Pod to jeden lub kilka kontenerów, które zawsze działają razem na tym samym węźle i dzielą sieć oraz przestrzeń dyskową. Kontenery w jednym Podzie komunikują się przez localhost i mają dostęp do tych samych wolumenów. Pod jest tworzony, uruchamiany i usuwany jako całość.

Zarządzanie stanem aplikacji i pętla uzgadniania

Kubernetes nie zarządza Podami bezpośrednio w większości przypadków. Zamiast tego używa wyższych abstrakcji, takich jak Deployment, StatefulSet czy DaemonSet, które definiują pożądany stan aplikacji. Operator mówi Kubernetesowi: “chcę mieć trzy działające repliki tej aplikacji”. Kubernetes dba o to, żeby ten stan był zawsze utrzymany, niezależnie od awarii węzłów czy przeciążenia klastra.

Cały model działania Kubernetes opiera się na pętli uzgadniania stanu. Komponenty platformy nieustannie porównują stan rzeczywisty klastra ze stanem pożądanym zapisanym w konfiguracji. Gdy wykryją różnicę, podejmują działania korygujące. To podejście sprawia, że Kubernetes jest odporny na awarie i nie wymaga ciągłego nadzoru operatora.

Zdj. 1. Oficjalna strona internetowa Kubernetes

Źródło: https://kubernetes.io/

Główne składniki control plane

Control plane składa się z kilku komponentów, z których każdy odgrywa określoną rolę.

API Server – centralny punkt wejścia

API Server to centralny punkt wejścia do klastra. Wszystkie polecenia, zarówno od operatora, jak i od wewnętrznych komponentów, przechodzą przez API Server. Przyjmuje żądania w formacie REST i zapisuje stan w bazie danych etcd.

Etcd to rozproszony magazyn klucz-wartość, który przechowuje cały stan klastra. Zawiera informacje o węzłach, Podach, konfiguracjach i sekretach. Jest jedynym źródłem prawdy dla całego klastra. Utrata etcd bez kopii zapasowej oznacza utratę stanu klastra, dlatego regularne tworzenie kopii zapasowych etcd należy do podstawowych obowiązków administratora.

Scheduler decyduje, na którym węźle uruchomić nowy Pod. Bierze pod uwagę dostępne zasoby, wymagania Poda, reguły rozmieszczenia i ograniczenia zdefiniowane przez operatora. Scheduler nie uruchamia Podów samodzielnie, tylko przypisuje je do węzłów.

Controller Manager uruchamia kontrolery, które monitorują stan klastra i reagują na odchylenia od stanu pożądanego. Jeśli Deployment wymaga trzech replik, a jedna padnie, kontroler Deploymentu natychmiast zleca utworzenie nowej. Każdy typ obiektu Kubernetes ma swój kontroler odpowiedzialny za utrzymanie jego stanu.

Główne składniki węzłów roboczych

Na każdym węźle roboczym działają trzy kluczowe komponenty.

Kubelet – agent zarządzający Podami

Kubelet to agent, który komunikuje się z control plane i zarządza Podami na danym węźle. Odbiera instrukcje od API Servera, uruchamia kontenery przez środowisko uruchomieniowe i raportuje stan z powrotem do control plane. Kubelet regularnie sprawdza też, czy kontenery przechodzą zdefiniowane health checki.

Kube-proxy i Container Runtime

Kube-proxy zarządza regułami sieciowymi na węźle. Odpowiada za przekierowanie ruchu do właściwych Podów i implementuje abstrakcję Service, która pozwala komunikować się z grupą Podów przez jeden stabilny adres.

Container Runtime to silnik uruchamiający kontenery. Kubernetes obsługuje kilka środowisk uruchomieniowych, w tym containerd i CRI-O. Docker był pierwotnie domyślnym środowiskiem, ale nigdy natywnie nie wspierał protokołu CRI – Kubernetes komunikował się z nim za pomocą wbudowanego w kubelet adaptera „dockershim”. W wersji 1.24 dockershim został usunięty, więc dalsze korzystanie z Dockera wymaga instalacji zewnętrznego komponentu cri-dockerd, utrzymywanego przez firmę Mirantis. Zalecaną ścieżką jest jednak migracja na środowiska natywnie wspierające CRI, takie jak containerd lub CRI-O.

Kluczowe pojęcia i obiekty Kubernetes

Kubernetes operuje na zestawie obiektów, które razem opisują pożądany stan aplikacji i infrastruktury. Znajomość tych obiektów jest podstawą pracy z klastrem.

Podstawowe obiekty: Pod, Deployment i StatefulSet

Pod to najmniejsza jednostka wdrożeniowa w Kubernetes. Zawiera jeden lub więcej kontenerów, które dzielą adres IP, przestrzeń nazw i wolumeny. Pody są efemeryczne. To oznacza, że Kubernetes może je usuwać i tworzyć w dowolnym momencie. Nie należy przywiązywać się do konkretnej instancji Poda ani zakładać, że będzie działać w nieskończoność. Każdy nowy Pod otrzymuje nowy adres IP, dlatego do komunikacji z grupą Podów używa się obiektów Service.

Deployment

Deployment to obiekt opisujący pożądany stan zestawu Podów. Operator definiuje obraz kontenera, liczbę replik i strategię aktualizacji. Kubernetes utrzymuje ten stan automatycznie. Deployment obsługuje też aktualizacje rolling update, czyli stopniowe zastępowanie starych Podów nowymi bez przestoju aplikacji. Jeśli nowa wersja okaże się wadliwa, Deployment pozwala szybko cofnąć się do poprzedniej wersji przez polecenie rollback.

StatefulSet

StatefulSet to obiekt podobny do Deploymentu, ale przeznaczony dla aplikacji stanowych, takich jak bazy danych. W przeciwieństwie do Deploymentu, StatefulSet nadaje każdemu Podowi stałą, przewidywalną nazwę i gwarantuje kolejność tworzenia oraz usuwania Podów. Każdy Pod w StatefulSet może mieć własny PersistentVolume, który pozostaje przypisany do tego konkretnego Poda nawet po jego restarcie.

DaemonSet

DaemonSet zapewnia, że na każdym węźle klastra działa dokładnie jedna kopia danego Poda. Używa się go do uruchamiania agentów systemowych, takich jak narzędzia do zbierania logów, monitorowania czy zarządzania siecią. Gdy do klastra dołącza nowy węzeł, DaemonSet automatycznie uruchamia na nim odpowiedni Pod.

Service

Service to abstrakcja sieciowa, która udostępnia grupę Podów pod stałym adresem IP i nazwą DNS. Pody mogą się pojawiać i znikać, ale Service pozostaje stabilny. Klienci łączą się z Service, a Kubernetes przekierowuje ruch do aktualnie działających Podów. Service obsługuje też load balancing między replikami.

Kubernetes oferuje kilka typów Service:

• clusterIP – komunikacja wewnątrz klastra,
• nodePort – dostęp przez port węzła,
• loadBalancer – integracja z zewnętrznym load balancerem dostawcy chmury.

Namespace

Namespace to mechanizm podziału klastra na logiczne przestrzenie. Pozwala izolować zasoby różnych zespołów, środowisk lub aplikacji w obrębie jednego klastra. Zasoby w różnych Namespace’ach mogą mieć te same nazwy bez konfliktów. Kubernetes tworzy domyślnie kilka Namespace’ów, w tym default, kube-system i kube-public. W praktyce organizacje tworzą własne Namespace’y dla każdego środowiska lub zespołu i przypisują im limity zasobów przez obiekty ResourceQuota.

ConfigMap i Secret

ConfigMap przechowuje dane konfiguracyjne w postaci par klucz-wartość. Pozwala oddzielić konfigurację od obrazu kontenera. To ułatwia wdrażanie tej samej aplikacji w różnych środowiskach bez przebudowywania obrazu. Secret działa podobnie, ale przechowuje dane wrażliwe, takie jak hasła, tokeny i certyfikaty, z dodatkową warstwą kontroli dostępu. Warto pamiętać, że base64 to jedynie kodowanie, a nie szyfrowanie, więc samo w sobie nie chroni danych. 

Szyfrowanie w spoczynku włącza się po stronie serwera API (kube-apiserver) za pomocą flagi –encryption-provider-config i wskazanego pliku konfiguracyjnego. Do wyboru są różni dostawcy szyfrowania, jak kms, zalecany w środowiskach produkcyjnych, a także aescbc, aesgcm czy secretbox.

Ingress

Ingress zarządza zewnętrznym dostępem do usług w klastrze, zazwyczaj przez HTTP i HTTPS. Pozwala definiować reguły routingu, obsługiwać wiele domen i terminować TLS. Ingress wymaga kontrolera Ingress, który implementuje faktyczną logikę routingu. Popularne kontrolery to NGINX Ingress Controller i Traefik. Jeden kontroler Ingress może obsługiwać ruch dla wielu aplikacji w klastrze. To upraszcza zarządzanie certyfikatami i regułami dostępu.

PersistentVolume i PersistentVolumeClaim

Pody są efemeryczne, ale dane często muszą przeżyć restart Poda. PersistentVolume to zasób klastra reprezentujący fizyczny nośnik danych, na przykład dysk w chmurze lub zasób NFS. PersistentVolumeClaim to żądanie Poda o przydzielenie określonej ilości przestrzeni dyskowej o określonych właściwościach. Kubernetes łączy PVC z odpowiednim PV i montuje go w Podzie. StorageClass pozwala dynamicznie tworzyć PersistentVolume na żądanie, bez ręcznego przygotowywania dysków przez administratora.

Jak Kubernetes skaluje aplikacje?

Skalowanie to jedna z głównych zalet Kubernetes. Platforma obsługuje dwa typy skalowania: horyzontalne i wertykalne.

Skalowanie Podów: HPA oraz VPA

Horizontal Pod Autoscaler (HPA) automatycznie zwiększa lub zmniejsza liczbę replik Poda na podstawie metryk, takich jak użycie CPU lub pamięci. Gdy ruch wzrasta, HPA dodaje repliki. Gdy spada, usuwa je, żeby nie marnować zasobów. Operator definiuje progi i limity, a Kubernetes reaguje automatycznie. HPA można też skonfigurować do skalowania na podstawie metryk niestandardowych, na przykład liczby wiadomości w kolejce.

Vertical Pod Autoscaler (VPA) dostosowuje zasoby przydzielone do pojedynczego Poda. Zamiast dodawać repliki, analizuje historyczne zużycie CPU i pamięci i rekomenduje nowe wartości limitów. W domyślnym trybie automatycznym VPA ewikuuje stary Pod, a kontroler nadrzędny tworzy nowy, do którego mutujący webhook VPA wstrzykuje powiększone wartości requests i limits, co wiąże się z krótkim, kontrolowanym restartem. VPA przydaje się dla aplikacji, które nie skalują się horyzontalnie, na przykład baz danych z jedną instancją. Trwają prace nad funkcją in-place pod resource updates, dostępną na razie w wersji alfa lub beta, która w przyszłości ma pozwolić zmieniać zasoby bez restartu.

Skalowanie infrastruktury: Cluster Autoscaler

Cluster Autoscaler działa na poziomie węzłów. Gdy Scheduler nie może umieścić Poda z powodu braku zasobów, Cluster Autoscaler dodaje nowy węzeł do klastra. Gdy węzły są niedostatecznie wykorzystane, usuwa je, żeby obniżyć koszty. Cluster Autoscaler integruje się z dostawcami chmury, takimi jak AWS, GCP i Azure, i komunikuje się bezpośrednio z ich API do zarządzania maszynami wirtualnymi.

Skalowanie w Kubernetes jest deklaratywne. Operator nie wydaje polecenia “dodaj trzy serwery”. Zamiast tego definiuje reguły, a Kubernetes sam decyduje, kiedy i jak skalować. To podejście eliminuje ręczne interwencje i pozwala reagować na zmiany obciążenia w czasie rzeczywistym.

Zalety Kubernetes w środowiskach produkcyjnych

Kubernetes wnosi konkretne korzyści operacyjne, które przekładają się na stabilność i efektywność środowisk produkcyjnych.

Samonaprawianie i deklaratywna konfiguracja

Samonaprawianie to jedna z najważniejszych cech platformy. Gdy Pod padnie, Kubernetes automatycznie uruchamia nowy. Gdy węzeł staje się niedostępny, Kubernetes wykreśla znajdujące się na nim Pody, a kontroler nadrzędny, na przykład ReplicaSet lub Deployment, tworzy w ich miejsce nowe repliki na innych, sprawnych węzłach. Gdy kontener nie przechodzi health checku, Kubernetes restartuje go lub zastępuje nową instancją. Wszystko to dzieje się bez interwencji operatora.

Deklaratywna konfiguracja pozwala opisać pożądany stan infrastruktury w plikach YAML i przechowywać je w repozytorium kodu. Zmiana konfiguracji to zmiana pliku i zastosowanie jej przez kubectl apply. Historia zmian jest widoczna w Git. Powrót do poprzedniej wersji to git revert i ponowne zastosowanie konfiguracji. Takie podejście, nazywane Infrastructure as Code, ułatwia audyt zmian i współpracę między zespołami.

Izolacja zasobów i przenośność

Izolacja zasobów przez Namespace i mechanizmy RBAC pozwala wielu zespołom pracować na tym samym klastrze bez wzajemnego zakłócania. Każdy zespół ma własną przestrzeń z przydzielonymi limitami zasobów i uprawnieniami. RBAC (ang. Role-Based Access Control) pozwala precyzyjnie określić, kto może wykonywać jakie operacje na jakich obiektach klastra.

Przenośność między środowiskami to kolejna zaleta. Aplikacja skonteneryzowana i opisana w manifestach Kubernetes działa tak samo na lokalnym klastrze Minikube, w chmurze AWS, GCP czy Azure i w prywatnym centrum danych. Różnice między środowiskami sprowadzają się do konfiguracji, a nie do kodu aplikacji. To eliminuje klasyczny problem „u mnie działa”, który pojawia się przy różnicach między środowiskiem deweloperskim a produkcyjnym.

Kontrola kosztów przez automatyczne skalowanie i efektywne pakowanie Podów na węzłach pozwala lepiej wykorzystać dostępne zasoby. Kubernetes stara się rozmieszczać Pody tak, żeby węzły były możliwie dobrze obciążone. To zmniejsza liczbę potrzebnych maszyn i obniża rachunki za infrastrukturę chmurową.

Jak zacząć pracę z Kubernetes?

Środowisko lokalne i narzędzie kubectl

Nauka Kubernetes zaczyna się od lokalnego klastra. Minikube uruchamia jednowęzłowy klaster Kubernetes na lokalnej maszynie i obsługuje systemy Windows, macOS i Linux. Kind (Kubernetes in Docker) to alternatywa, która uruchamia węzły klastra jako kontenery Docker. Oba narzędzia pozwalają eksperymentować z Kubernetes bez dostępu do infrastruktury chmurowej.

Podstawowym narzędziem do interakcji z klastrem jest kubectl. To interfejs wiersza poleceń, który komunikuje się z API Serverem i pozwala tworzyć, modyfikować i usuwać obiekty klastra. Znajomość podstawowych poleceń kubectl, takich jak apply, get, describe, logs i exec, jest niezbędna do codziennej pracy z Kubernetes.

Pierwsze wdrożenie i zasoby edukacyjne

Pierwsze kroki warto zacząć od wdrożenia prostej aplikacji webowej. Typowy przepływ obejmuje napisanie pliku Dockerfile, zbudowanie obrazu, opublikowanie go w rejestrze kontenerów, napisanie manifestu Deployment i Service, a następnie zastosowanie go przez kubectl apply. Taki projekt pozwala zrozumieć, jak poszczególne obiekty Kubernetes współpracują ze sobą.

Oficjalna dokumentacja Kubernetes na kubernetes.io zawiera interaktywne tutoriale, które prowadzą przez podstawowe scenariusze bez konieczności instalowania czegokolwiek lokalnie. Środowisko Play with Kubernetes pozwala ćwiczyć w przeglądarce na prawdziwym klastrze.

Klastry chmurowe i certyfikacja

Dla osób, które chcą przejść do środowisk chmurowych, każdy z głównych dostawców oferuje zarządzaną usługę Kubernetes: Google Kubernetes Engine (GKE), Amazon Elastic Kubernetes Service (EKS) i Azure Kubernetes Service (AKS). Zarządzane klastry zdejmują z operatora odpowiedzialność za utrzymanie control plane i aktualizacje platformy, pozwalając skupić się na wdrażaniu aplikacji.

Certyfikacja Certified Kubernetes Administrator (CKA) i Certified Kubernetes Application Developer (CKAD) to uznane w branży potwierdzenia kompetencji. Egzaminy mają formę praktyczną. To oznacza rozwiązywanie zadań na prawdziwym klastrze w ograniczonym czasie. Przygotowanie do tych certyfikatów to jednocześnie dobra ścieżka nauki dla osób, które chcą usystematyzować wiedzę o Kubernetes.

Projekt powstał w Google i od 2015 roku jest rozwijany przez Cloud Native Computing Foundation. Kubernetes zarządza klastrem maszyn jak jednym zasobem obliczeniowym, przydziela kontenery do węzłów, monitoruje ich stan i obsługuje awarie bez interwencji człowieka.

Genialne firmy mnożą
swój potencjał z

Sprawdź nasze Case Studies

Ocena Clutch

5.0

Ocena Google

4.8

Bądź widoczny w Google i wyszukiwarkach przyszłości (ChatGPT, Gemini, Perplexity i inne)

Zostaw adres e-mail — porozmawiamy o widoczności Twojej strony w AI.

Dane przetwarzamy w celu kontaktu, zgodnie z naszą
polityką prywatności