`Arhitectura unui Cluster Kubernetes în Producție: Control Plane HA, etcd Quorum și Worker Nodes` în Kubernetes (kubectl)

Noduri și Helm Kubernetes 1.25+ Producție

Ghid de arhitectură enterprise pentru Kubernetes în producție: configurarea High Availability (HA) pentru Control Plane, calculul cvorumului etcd (3 sau 5 noduri), topologii etcd stacked vs externe și distribuția nodurilor pe zone de disponibilitate.

Sintaxă comandă

etcdctl endpoint health | etcdctl snapshot save backup.db | kubectl get nodes -o wide

Un cluster Kubernetes de producție nu poate tolera existența niciunui punct unic de eșec (Single Point of Failure – SPOF). Dacă un cluster de dezvoltare poate rula cu un singur nod de master, în mediile enterprise este obligatorie o arhitectură de înaltă disponibilitate (High Availability – HA), compusă din cel puțin 3 noduri de Control Plane distribuite în zone fizice de disponibilitate (Availability Zones – AZ) distincte și zeci de noduri de execuție (Worker Nodes) organizate pe bazine de resurse.

1. Matematica Cvorumului etcd: De ce 3 sau 5 Noduri, Niciodată Număr Par?

Baza de date etcd stochează întreaga stare a clusterului și funcționează pe baza algoritmului distribuit de consens Raft. Pentru a putea accepta orice operațiune de scriere (de exemplu crearea unui Pod nou), majoritatea strictă a nodurilor etcd trebuie să fie online și să cadă de acord. Această majoritate poartă numele de Cvorum (Quorum) și este calculată matematic prin formula:

Cvorum = (N / 2) + 1  (unde N este numărul total de noduri etcd)

Număr Total Noduri (N)	Cvorum Necesar	Căderi Maxime Tolerate	Explicație și Recomandare
1	1	0	Medii de test/dezvoltare. Orice oprire oprește tot clusterul.
3	2	1 nod	Standardul recomandat pentru majoritatea clusterelor de producție.
4	3	1 nod	Nerecomandat: Tolerează exact 1 cădere (la fel ca 3 noduri), dar adaugă complexitate și risc dublu de eșec de rețea.
5	3	2 noduri	Recomandat pentru clustere masive (peste 500 de noduri de calcul).

2. Topologii de Arhitectură: Stacked vs External etcd

Stacked Control Plane (Recomandat în 90% din cazuri): Fiecare nod master găzduiește simultan instanțele de kube-apiserver, kube-scheduler, kube-controller-manager și un membru etcd local. Este topologia implicită creată de kubeadm, ușor de întreținut și optimă ca latență.
External etcd Topology: Membrii etcd rulează pe 3 sau 5 servere dedicate complet separate de nodurile de Control Plane. Oferă izolare maximă de performanță la sarcini extreme I/O pe disc.

Procedura de Backup și Verificare de Sănătate etcd

# 1. Verificarea sănătății clusterului etcd:
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  endpoint health

# 2. Crearea unui snapshot atomic consistent (de rulat automat prin Cron):
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /var/backups/etcd/etcd_snapshot_$(date +%Y%m%d_%H%M%S).db

3. Protecția Resurselor de Sistem pe Worker Nodes

Dacă Pod-urile consumă 100% din memoria RAM sau CPU-ul unui nod, procesele vitale ale sistemului (kubelet, containerd, daemonul sshd) vor fi omorâte de nucleul Linux (OOM Killer), provocând trecerea nodului în starea NotReady. Pentru a împiedica acest colaps, configurați obligatoriu parametrii system-reserved și kube-reserved în fișierul de configurare kubelet:

# În /var/lib/kubelet/config.yaml pe fiecare nod:
systemReserved:
  cpu: "500m"
  memory: "1Gi"
kubeReserved:
  cpu: "500m"
  memory: "1Gi"
evictionHard:
  memory.available: "500Mi"
  nodefs.available: "10%"