Kubernetes od środka: podstawy architektury klastra
- data
- kategoria
- Containers
- także w
- Cloud · Networking
- czytanie
- 1 min / 197 słów
Kubernetes często poznaje się od strony aplikacji: Deploymentów, Service'ów, ConfigMap, Helm chartów czy manifestów YAML. To naturalne, bo właśnie z tym najczęściej pracuje developer.
Ta seria idzie jednak w inną stronę.
Zamiast pytać:
Jak wdrożyć aplikację do Kubernetes?
pytamy:
Co właściwie sprawia, że klaster Kubernetes działa?
Skupiamy się więc na elementach, których zwykle nie tworzymy sami, ale które cały czas pracują w tle:
kube-apiserver,etcd,kube-scheduler,kube-controller-manager,kubelet,- container runtime,
- CNI,
kube-proxy,- CoreDNS.
Do tego dochodzą dwa bardzo ważne podziały:
- control plane vs data plane,
- managed vs self-managed Kubernetes.
Na końcu zobaczymy też, gdzie taki klaster może działać: w public cloud, on-premises, na maszynach wirtualnych albo bezpośrednio na bare metal.
Celem tej serii nie jest opisanie całego ekosystemu Kubernetes. Nie będziemy wchodzić głęboko w workloady aplikacyjne, operatory, observability czy zaawansowane mechanizmy storage.
Chodzi o zbudowanie solidnego modelu mentalnego: co jest częścią klastra, za co odpowiada każdy główny komponent i jak te elementy współpracują ze sobą.
Jeżeli korzystasz z Kubernetes na co dzień, ale takie nazwy jak etcd, kubelet czy kube-proxy są dla Ciebie raczej czymś, co "po prostu tam jest", ta seria powinna uporządkować ten obraz.