Jeśli pracujesz w świecie tworzenia oprogramowania, na pewno słyszałeś o Kubernetes. Ale czym dokładnie jest i dlaczego stał się standardem de facto do zarządzania aplikacjami kontenerowymi? Ten przewodnik poprowadzi cię od podstaw do fundamentalnych koncepcji, z praktycznymi przykładami i diagramami, które pomogą ci zrozumieć.
Przed Kubernetes: trochę historii
Aby zrozumieć, dlaczego Kubernetes jest tak rewolucyjny, cofnijmy się o krok.
- Tradycyjne wdrażanie: Początkowo aplikacje uruchamiano na serwerach fizycznych. To podejście było kosztowne, trudne do skalowania i podatne na konflikty zasobów.
- Wdrażanie zwirtualizowane: Potem pojawiły się maszyny wirtualne (VM). VM pozwalały na uruchamianie wielu izolowanych aplikacji na tym samym sprzęcie, poprawiając wykorzystanie zasobów i bezpieczeństwo. Jednak każda VM uruchamia cały system operacyjny, zużywając dużo zasobów.
- Wdrażanie kontenerowe: Kontenery (jak Docker) to kolejna ewolucja. Dzielą ten sam system operacyjny hosta, ale uruchamiają izolowane procesy. Są lekkie, szybko się uruchamiają i są przenośne.
Kontenery rozwiązały problem przenośności, ale stworzyły inny: jak zarządzać setkami (lub tysiącami) kontenerów w środowisku produkcyjnym? Jak zapewnić, że zawsze działają, mogą się ze sobą komunikować i skalować w zależności od obciążenia?
Tu wkracza Kubernetes.
Czym jest Kubernetes?
Kubernetes (często skracany do K8s) to platforma open-source do orkiestracji kontenerów. W prostych słowach, automatyzuje wdrażanie, skalowanie i zarządzanie aplikacjami kontenerowymi. Stworzony przez Google i obecnie utrzymywany przez Cloud Native Computing Foundation (CNCF), Kubernetes stał się podstawowym narzędziem dla każdego, kto pracuje z mikroserwisami na dużą skalę.
Architektura klastra Kubernetes
Środowisko Kubernetes nazywane jest klastrem. Klaster składa się ze zbioru maszyn, nazywanych węzłami (nodes), które uruchamiają nasze aplikacje. Architektura dzieli się na dwie główne części: Control Plane i Worker Nodes.
Control Plane
Control Plane to „mózg" klastra. Podejmuje globalne decyzje (takie jak planowanie) oraz wykrywa zdarzenia klastra i na nie reaguje. Jego główne komponenty to:
- API Server (
kube-apiserver): Brama do klastra. Udostępnia API Kubernetes, z którego korzystają użytkownicy (przezkubectl), komponenty klastra i zewnętrzne narzędzia do komunikacji. - etcd: Spójna i wysoko dostępna baza danych klucz-wartość. Przechowuje wszystkie dane klastra, reprezentujące pożądany i aktualny stan systemu.
- Scheduler (
kube-scheduler): Przydziela nowo utworzone Pods do dostępnych Worker Nodes, uwzględniając wymagania zasobowe, polityki i inne ograniczenia. - Controller Manager (
kube-controller-manager): Uruchamia kontrolery — pętle sterujące, które obserwują stan klastra i pracują, aby doprowadzić go do pożądanego stanu. Na przykładNode Controllerzarządza węzłami, aReplication Controllerzapewnia, że działa prawidłowa liczba Pods.
Worker Node
Worker Nodes to maszyny (fizyczne lub wirtualne), na których faktycznie uruchamiane są aplikacje. Każdy węzeł jest zarządzany przez Control Plane i zawiera następujące komponenty:
- Kubelet: Agent działający na każdym węźle. Zapewnia, że kontenery opisane w Pods działają i są zdrowe.
- Kube-proxy: Proxy sieciowy zarządzający regułami sieciowymi na węzłach. Umożliwia komunikację sieciową z Pods z sesji sieciowych wewnątrz lub na zewnątrz klastra.
- Container Runtime: Oprogramowanie odpowiedzialne za uruchamianie kontenerów. Docker jest najbardziej znany, ale Kubernetes obsługuje również inne środowiska uruchomieniowe, takie jak
containerdiCRI-O.
Podstawowe obiekty Kubernetes
W Kubernetes wszystko jest reprezentowane przez obiekty. Te obiekty to „zapisy intencji": po utworzeniu obiektu Kubernetes stale pracuje, aby zapewnić, że istnieje i odpowiada pożądanemu stanowi.
Oto najważniejsze z nich:
Pod
Pod to najmniejsza jednostka wykonawcza w Kubernetes. Reprezentuje jeden lub więcej kontenerów uruchamianych razem na tym samym węźle, dzielących zasoby takie jak sieć i pamięć masowa.
Zazwyczaj uruchamiasz tylko jeden kontener na Pod, ale w zaawansowanych scenariuszach (np. „sidecar containers" do logowania lub monitorowania) może być ich więcej.
Prawie nigdy nie tworzysz Pods bezpośrednio. Używasz abstrakcji wyższego poziomu, takich jak Deployments.
Deployment
Deployment to obiekt, którego będziesz używać najczęściej. Opisuje pożądany stan grupy identycznych Pods. Kontroler Deployment jest odpowiedzialny za:
- Tworzenie i zarządzanie ReplicaSet (inny obiekt zapewniający, że określona liczba replik Pod zawsze działa).
- Skalowanie liczby Pods w górę lub w dół.
- Zarządzanie aktualizacjami aplikacji w kontrolowany sposób (np. Rolling Update), bez przestojów.
Przykładowy plik YAML dla Deployment uruchamiającego 3 repliki serwera NGINX:
# nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.14.2 ports: - containerPort: 80
Service
Pods w Kubernetes są efemeryczne: mogą być tworzone i niszczone w dowolnym momencie. Każdy Pod ma własny adres IP, ale ten IP nie jest stabilny. Jak więc niezawodnie udostępnić naszą aplikację?
Za pomocą Service. Service to abstrakcja definiująca logiczny zbiór Pods i politykę dostępu do nich. Zapewnia stabilny punkt dostępu (wirtualny adres IP i nazwę DNS) dla grupy Pods.
Service używa selector opartego na labels, aby znaleźć Pods, do których powinien kierować ruch.
Jak stworzyć Service dla naszego NGINX Deployment:
# nginx-service.yaml apiVersion: v1 kind: Service metadata: name: nginx-service spec: selector: app: nginx ports: - protocol: TCP port: 80 targetPort: 80 type: ClusterIP # Default - exposes the service only within the cluster
Istnieją różne typy Services:
ClusterIP: Udostępnia usługę pod wewnętrznym IP klastra (domyślnie).NodePort: Udostępnia usługę na statycznym porcie na każdym Worker Node.LoadBalancer: Tworzy zewnętrzny load balancer u dostawcy chmury (np. AWS, GCP) i przypisuje publiczny IP do usługi.
Ingress
Service typu LoadBalancer jest świetny, ale tworzenie go dla każdej usługi może być kosztowne. Aby udostępnić wiele usług HTTP/HTTPS na zewnątrz, używasz Ingress.
Ingress działa jako „inteligentny router" dla ruchu zewnętrznego. Pozwala definiować reguły routingu na podstawie hosta (np. api.mysite.com) lub ścieżki (np. mysite.com/api).
Przykład Ingress:
# example-ingress.yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: example-ingress spec: rules: - host: mysite.com http: paths: - path: /api pathType: Prefix backend: service: name: api-service port: number: 8080 - path: /ui pathType: Prefix backend: service: name: ui-service port: number: 3000
Inne przydatne obiekty
- Namespace: Pozwala tworzyć „wirtualne klastry" wewnątrz fizycznego klastra. Przydatny do izolowania środowisk (np.
development,staging,production) lub zespołów. - ConfigMap i Secret: Do zarządzania danymi konfiguracyjnymi i sekretami (jak hasła lub klucze API) oddzielonymi od obrazu kontenera.
- StatefulSet: Podobny do Deployment, ale specyficzny dla aplikacji stanowych (jak bazy danych) wymagających stabilnych tożsamości sieciowych i trwałej pamięci masowej.
- PersistentVolume (PV) i PersistentVolumeClaim (PVC): Do zarządzania trwałą pamięcią masową w klastrze.
Podsumowanie
Kubernetes to niesamowicie potężne narzędzie, ale jego krzywa uczenia się może być stroma. Ten przewodnik tylko zarysował temat, ale mamy nadzieję, że dał ci solidne zrozumienie podstawowych koncepcji.
Co teraz?
- Eksperymentuj lokalnie: Zainstaluj Minikube lub Kind, aby stworzyć klaster Kubernetes na swoim komputerze.
- Używaj
kubectl: Zapoznaj się z poleceniemkubectl, swoim głównym narzędziem do interakcji z klastrem. Spróbuj stworzyć NGINX Deployment i Service z tego artykułu. - Przejrzyj oficjalne tutoriale: Dokumentacja Kubernetes to fantastyczne źródło pełne przykładów.
Orkiestracja kontenerów to fundamentalna umiejętność w świecie cloud-native, a opanowanie Kubernetes otworzy przed tobą świat możliwości. Baw się dobrze!