Węzeł (ang. node) to pojedyncza maszyna — fizyczny serwer albo maszyna wirtualna — która należy do większego klastra i na której faktycznie wykonują się obciążenia. Mówiąc prościej: klaster to zespół, a węzeł to jeden zawodnik, który dostaje robotę do zrobienia i ją odwala. W świecie Kubernetes węzeł jest miejscem, gdzie lądują pody, a w nich kontenery z Twoją aplikacją.
Sam węzeł nie podejmuje decyzji, co i gdzie uruchomić — od tego jest control plane (płaszczyzna sterowania) i jego scheduler. Węzeł jedynie melduje: „mam tyle CPU, tyle RAM, jestem zdrowy” i czeka na przydział pracy. Żeby to działało, na każdym węźle siedzi kilka komponentów: kubelet (agent, który pilnuje, żeby kontenery faktycznie działały), container runtime (np. containerd, które te kontenery odpala) oraz kube-proxy obsługujące ruch sieciowy. Węzły dzielą się na sterujące (control plane) i robocze (worker nodes) — to na tych drugich biega Twój kod.
Jak to wygląda w praktyce
Załóżmy, że masz klaster i chcesz zobaczyć, z czego się składa. Odpalasz:
kubectl get nodes -o wide
i dostajesz listę maszyn ze statusem Ready albo NotReady, wersją Kubernetes, adresem IP i systemem. Jak któryś węzeł pokazuje NotReady, to znak, że kubelet przestał odpowiadać albo maszyna padła. Wtedy zaglądasz głębiej przez kubectl describe node nazwa-wezla, gdzie zobaczysz zużycie zasobów, etykiety i taints. W chmurze (EKS, GKE, AKS) węzły często grupuje się w node poole i pozwala im się automatycznie skalować — gdy podów przybywa, autoscaler dorzuca kolejne maszyny.
Częste pułapki
- Mylenie węzła z podem. Węzeł to maszyna, pod to najmniejsza jednostka uruchamiana na tej maszynie. Jeden węzeł hostuje wiele podów.
- Ignorowanie limitów. Pod bez ustawionych
requestsilimitspotrafi zjeść pamięć całego węzła i wywołać eviction innych podów albo OOM kill. - Traktowanie węzłów jak pieszczoszków. W dobrze zaprojektowanym klastrze węzeł jest wymienialny. Padł — scheduler przeniesie pody gdzie indziej. Jeśli aplikacja tego nie przeżywa, to problem architektury, nie węzła.
Pojęcia powiązane: klaster, pod, kontener, kubelet, scheduler, control plane, autoscaling, taint i toleration.