Architektura klastra Kubernetes – jak działa platforma orkiestracji kontenerów od środka?
Architektura klastra Kubernetes – jak działa platforma orkiestracji kontenerów od środka?
Docker rozwiązał problem uruchamiania aplikacji w kontenerach. Gdy jednak liczba kontenerów rośnie z kilku do kilkuset lub kilku tysięcy, pojawiają się nowe wyzwania:
- gdzie uruchomić kontener,
- jak zapewnić wysoką dostępność,
- co zrobić, gdy serwer ulegnie awarii,
- jak automatycznie skalować aplikacje,
- jak wdrażać nowe wersje bez przestojów.
Właśnie dlatego powstał Kubernetes (K8s) – platforma do orkiestracji kontenerów, która automatyzuje zarządzanie aplikacjami działającymi w rozproszonym środowisku.
Nie jest to jednak „magiczny system”. Kubernetes składa się z wielu współpracujących komponentów, z których każdy odpowiada za określone zadania.
Czym jest klaster Kubernetes?
Klaster Kubernetes to grupa serwerów współpracujących jako jeden logiczny system.
Schemat wygląda następująco:
Kubernetes Cluster
+-----------------------------+
| Control Plane |
+-----------------------------+
/ | \
/ | \
+---------+ +---------+ +---------+
| Worker | | Worker | | Worker |
| Node 1 | | Node 2 | | Node 3 |
+---------+ +---------+ +---------+
Każdy serwer może uruchamiać wiele kontenerów, ale decyzję o ich rozmieszczeniu podejmuje Control Plane.
Control Plane – mózg klastra
Control Plane zarządza całym środowiskiem.
To tutaj podejmowane są decyzje dotyczące:
- planowania nowych kontenerów,
- monitorowania stanu klastra,
- wykrywania awarii,
- skalowania aplikacji,
- komunikacji pomiędzy komponentami.
Najważniejsze elementy Control Plane to:
- kube-apiserver,
- etcd,
- kube-scheduler,
- kube-controller-manager,
- cloud-controller-manager (w chmurze).
kube-apiserver – centrum komunikacji
Każda operacja wykonywana w Kubernetes przechodzi przez API Server.
Przykład:
Administrator wykonuje:
kubectl apply -f deployment.yaml
Przebieg operacji:
kubectl
↓
kube-apiserver
↓
etcd
↓
Scheduler
↓
Worker Nodes
API Server jest jedynym oficjalnym interfejsem komunikacji z klastrem.
Tip eksperta
Nigdy nie komunikuj się bezpośrednio z bazą etcd. Wszystkie operacje administracyjne powinny odbywać się przez API Server, ponieważ zapewnia on autoryzację, uwierzytelnianie oraz walidację danych.
etcd – baza danych klastra
etcd jest rozproszoną bazą typu Key-Value.
Przechowuje praktycznie cały stan klastra:
- Deploymenty,
- Pod’y,
- ConfigMap,
- Secrets,
- informacje o Node,
- polityki sieciowe.
Schemat:
etcd
├── Nodes
├── Pods
├── Deployments
├── Services
├── Secrets
└── ConfigMaps
Jeżeli utracimy dane z etcd, utracimy również konfigurację klastra.
Tip eksperta
Regularny backup etcd jest jednym z najważniejszych elementów strategii Disaster Recovery. W wielu organizacjach wykonuje się automatyczne kopie zapasowe co kilka godzin.
kube-scheduler – planista
Scheduler odpowiada za wybór najlepszego serwera dla nowego Poda.
Nie robi tego losowo.
Analizuje między innymi:
- ilość wolnej pamięci,
- dostępne CPU,
- tainty i tolerations,
- affinity i anti-affinity,
- lokalizację danych,
- wymagania aplikacji.
Proces:
Nowy Pod
↓
Scheduler
↓
Analiza zasobów
↓
Najlepszy Worker Node
Tip eksperta
W środowiskach produkcyjnych warto stosować Node Affinity, aby aplikacje były uruchamiane na odpowiednich typach serwerów, np. bazy danych na szybkich dyskach NVMe, a aplikacje AI na węzłach z GPU.
kube-controller-manager
Controller Manager nieustannie porównuje:
stan oczekiwany
ze
stanem rzeczywistym.
Przykład:
Administrator definiuje:
ReplicaSet = 3
Aktualny stan:
2 Pody
Controller wykrywa różnicę:
Desired: 3
Current: 2
↓
Tworzy nowy Pod
To właśnie dlatego Kubernetes potrafi automatycznie odtwarzać uszkodzone aplikacje.
Worker Node
Worker Node wykonuje właściwą pracę.
Znajdują się tutaj:
- kubelet,
- runtime kontenerów,
- kube-proxy,
- uruchomione Pody.
Schemat:
Worker Node
├── kubelet
├── kube-proxy
├── containerd
└── Pods
kubelet
Kubelet jest agentem działającym na każdym Worker Node.
Jego zadania:
- odbieranie poleceń z API Server,
- uruchamianie Podów,
- monitorowanie ich stanu,
- raportowanie błędów.
Jeżeli Pod przestanie odpowiadać, kubelet zgłasza problem do Control Plane.
Runtime kontenerów
Kubernetes nie uruchamia kontenerów samodzielnie.
Korzysta z runtime zgodnego z CRI (Container Runtime Interface).
Najczęściej spotykane:
- containerd,
- CRI-O.
Starsze klastry często wykorzystywały Docker, jednak obecnie standardem jest containerd.
kube-proxy
Każdy Worker Node posiada kube-proxy.
Odpowiada za:
- routing ruchu,
- load balancing,
- obsługę Services,
- reguły iptables lub nftables.
Przykład:
Client
↓
Service
↓
kube-proxy
↓
Pod A
lub
Pod B
lub
Pod C
Pod – najmniejsza jednostka Kubernetes
Pod to najmniejszy element uruchamiany w klastrze.
Może zawierać:
- jeden kontener,
- kilka współpracujących kontenerów.
Przykład:
Pod
├── nginx
└── log collector
Kontenery współdzielą:
- adres IP,
- przestrzeń sieciową,
- wolumeny.
Tip eksperta
W większości przypadków jeden Pod powinien zawierać jedną główną aplikację. Dodatkowe kontenery warto stosować tylko jako sidecary, np. do logowania, monitoringu lub proxy.
Deployment
Deployment odpowiada za zarządzanie Podami.
Przykład:
replicas: 3
Kubernetes automatycznie utrzyma trzy działające instancje aplikacji.
Jeżeli jedna z nich ulegnie awarii:
Pod Crash
↓
Controller
↓
Nowy Pod
Service
Pody są tymczasowe.
Ich adresy IP mogą się zmieniać.
Dlatego Kubernetes wykorzystuje Service.
Schemat:
Internet
↓
Service
↓
Pod 1
Pod 2
Pod 3
Aplikacje komunikują się z nazwą Service, a nie z konkretnym Podem.
Ingress
Ingress umożliwia publikowanie usług HTTP i HTTPS.
Przykład:
Internet
↓
Ingress
↓
Frontend
↓
Backend
↓
Database
Najczęściej wykorzystywane kontrolery:
- NGINX Ingress,
- Traefik,
- HAProxy.
Network Policy
Domyślnie większość klastrów pozwala na komunikację pomiędzy wszystkimi Podami.
Nie jest to dobre rozwiązanie.
Network Policy pozwala określić:
Frontend
↓
Backend
↓
Database
ale jednocześnie zablokować:
Frontend
↓
Database
Tip eksperta
W środowiskach produkcyjnych warto przyjąć zasadę Default Deny – domyślnie blokować cały ruch między Podami i zezwalać tylko na niezbędną komunikację.
High Availability
Profesjonalny klaster posiada więcej niż jeden Control Plane.
Przykład:
Load Balancer
|
----------------------------
API1 API2 API3
----------------------------
Shared etcd Cluster
Awaria jednego serwera nie powoduje zatrzymania klastra.
Skalowanie
Kubernetes obsługuje kilka rodzajów skalowania.
Poziome:
3 Pods
↓
6 Pods
Pionowe:
2 GB RAM
↓
4 GB RAM
Możliwe jest także automatyczne dodawanie nowych Worker Node za pomocą Cluster Autoscalera.
Bezpieczeństwo klastra
Dobrze zabezpieczony Kubernetes wykorzystuje:
- RBAC,
- Pod Security Standards,
- Network Policies,
- Secrets,
- TLS,
- Admission Controllers,
- skanowanie obrazów,
- podpisywanie obrazów,
- audyt API.
Tip eksperta
Jednym z najczęściej spotykanych błędów jest przyznawanie kontu serwisowemu uprawnień cluster-admin. W praktyce większość aplikacji potrzebuje znacznie mniejszych uprawnień zgodnie z zasadą Least Privilege.
Architektura produkcyjnego klastra
Internet
│
Load Balancer
│
Ingress Controller
│
Kubernetes Service
│
+----------------------------+
| Worker Nodes |
| |
| Pod A Pod B Pod C |
| |
+----------------------------+
│
Persistent Storage
│
Monitoring + Logging
│
Control Plane
│
etcd
Najlepsze praktyki
✅ stosuj co najmniej trzy węzły Control Plane w środowisku produkcyjnym
✅ regularnie wykonuj backup bazy etcd
✅ używaj Network Policies i zasady Default Deny
✅ ogranicz uprawnienia za pomocą RBAC
✅ uruchamiaj kontenery jako użytkownik non-root
✅ skanuj obrazy przed wdrożeniem
✅ monitoruj klaster za pomocą Prometheus i Grafana
✅ centralizuj logi (np. Loki lub Elasticsearch)
✅ aktualizuj Kubernetes oraz komponenty klastra zgodnie z harmonogramem
Podsumowanie
Kubernetes nie jest jedynie narzędziem do uruchamiania kontenerów. To rozbudowany system zarządzania infrastrukturą, który automatyzuje planowanie, skalowanie, odtwarzanie i monitorowanie aplikacji.
Zrozumienie architektury klastra jest kluczowe nie tylko dla administratorów, ale również dla specjalistów DevOps i DevSecOps. Dopiero znajomość zależności pomiędzy komponentami, takimi jak Control Plane, kubelet, scheduler, etcd czy kube-proxy, pozwala skutecznie diagnozować problemy, projektować wysokodostępne środowiska i budować bezpieczne platformy kontenerowe gotowe do pracy w produkcji.
Resort obrony narodowej z roku na rok coraz poważniej traktuje zagadnienia cyberbezpieczeństwa RP, co dobrze wróży na przyszłość. Łatwo dają Czytaj dalej
Manipulowanie i eksperymentowanie z routerami Cisco może prowadzić do potencjalnych problemów i nieprawidłowego działania sieci. Dlatego zawsze ważne jest przestrzeganie Czytaj dalej
