Un cluster Kubernetes este format din două categorii de mașini, control plane și noduri worker, care comunică prin rețea și țin starea aplicațiilor sincronizată în permanență. Control plane-ul ia deciziile: unde rulează fiecare container, ce se întâmplă când un nod cade, cum se distribuie traficul. Nodurile worker execută efectiv containerele, prin intermediul unui runtime precum containerd, care a devenit implicit în Kubernetes de la versiunea 1.24 încoace, după eliminarea suportului direct pentru Docker Engine (dockershim).
Componentele control plane-ului
Control plane-ul rulează patru componente principale. kube-apiserver este singurul punct de intrare în cluster, prin care trec toate comenzile «kubectl» și toate cererile programatice, validate și autentificate înainte de a ajunge mai departe. etcd este o bază de date de tip cheie valoare, distribuită și consistentă, care stochează întreaga stare a clusterului, de la lista de pod-uri până la Secrets; pierderea etcd fără backup înseamnă pierderea completă a configurației clusterului, motiv pentru care majoritatea instalărilor de producție rulează etcd pe cel puțin trei noduri, pentru toleranță la defecte prin algoritmul Raft. kube-scheduler decide pe ce nod worker pornește fiecare pod nou, în funcție de resursele disponibile și de regulile de afinitate. kube-controller-manager rulează bucle de control care aduc starea reală a clusterului la starea dorită, descrisă în manifestele YAML.
Nodurile worker
Fiecare nod worker rulează kubelet, agentul care comunică cu kube-apiserver și pornește containerele cerute prin runtime-ul local, și kube-proxy, care menține regulile de rețea pentru rutarea traficului către pod-urile corecte, de obicei prin iptables sau IPVS. Un cluster minim funcțional are nevoie de cel puțin un nod control plane și un nod worker, dar în capitolul următor veți instala un cluster cu trei mașini, un control plane și două noduri worker, folosind kubeadm, unealta oficială de instalare menținută de proiectul Kubernetes.
De ce etcd este componenta critică
În practică, cea mai frecventă greșeală la instalările pe servere proprii este subestimarea importanței etcd. Un etcd fără backup periodic, de exemplu printr-un job «etcdctl snapshot save» programat zilnic, transformă o defecțiune de disc dintr-un incident de câteva ore într-o pierdere totală a clusterului. Pe un VPS cu resurse limitate, etcd are nevoie de disc SSD rapid, latența de scriere pe disc influențează direct stabilitatea întregului cluster, iar documentația oficială recomandă o latență sub 10 milisecunde pentru operațiile fsync.
Diferența dintre un cluster Kubernetes și o instalare simplă cu Docker Compose pe un singur server este exact acest control plane distribuit: Kubernetes reface automat un pod care a căzut, redistribuie sarcina când un nod worker devine indisponibil și menține starea dorită fără intervenție manuală, lucru pe care Docker Compose, gândit pentru o singură mașină, nu îl oferă. Capitolul următor din curs arată cum se instalează acest control plane, pas cu pas, cu kubeadm, pe servere Ubuntu 24.04 sau AlmaLinux 9.