Arhitectura: control plane și noduri

Înțelegerea arhitecturii Kubernetes este fundamentală pentru orice inginer DevOps sau SRE, deoarece clusterul nu este o entitate monolitică, ci un sistem distribuit complex. Control Plane acționează ca „creierul” clusterului, gestionând starea globală și luând decizii, în timp ce Nodurile sunt „mușchii” care execută efectiv sarcinile de calcul. Fără o clarificare a acestei separări, depanarea problemelor de scalabilitate sau disponibilitate devine aproape imposibilă în medii de producție reale.

Concepte cheie

• API Server: Este front-end-ul unic al control plane-ului, expunând API-ul REST prin care toate comunicările (de la kubectl la componente interne) au loc; este punctul central de validare și configurare.
• etcd: Un depozit de cheie-valoare distribuit, coerent și sigur, care stochează toată starea clusterului; dacă etcd este pierdut, clusterul este irecuperabil fără backup-uri recente.
• Scheduler: Componenta care decide pe ce nod va fi plasată o pod nou creat, analizând resursele disponibile, constrângerile de hardware și politicile de anti-affinity.
• Controller Manager: Rulază controalele de buclă închisă care monitorizează starea clusterului și încearcă să aducă starea curentă în conformitate cu starea dorită definită de utilizator.
• Kubelet: Agentul care rulează pe fiecare nod și se asigură că containerele descrise în manifestele Pod sunt rulate și sănătoase, comunicând constant cu API Server.
• Kube-proxy: Menține regulile de rețea pe fiecare nod, permițând comunicarea de rețea între poduri și servicii externe prin intermediul regulilor iptables sau IPVS.
• Container Runtime: Software-ul care runde efectiv containerele (ex: containerd, CRI-O); Kubernetes nu le gestionează direct, ci folosește standardul CRI (Container Runtime Interface).

Exemplu practic

Imagină-ți că aplici un manifest YAML pentru un Deployment. Fluxul este următorul:

1. Trimite comanda kubectl apply -f app.yaml.
2. API Server validează cererea și salvează configurația în etcd.
3. Scheduler detectează podul nesolicitat, calculează cel mai bun nod (bazat pe CPU/RAM liber) și atașează eticheta nodeName la pod.
4. Kubelet de pe acel nod detectează schimbarea în etcd, apelează Container Runtime pentru a descărca imaginea și a porni containerul.
5. Kube-proxy actualizează regulile de rețea pentru a direcționa traficul către noul pod.

# Exemplu simplificat de Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3 # Scheduler va crea 3 instanțe
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

Greșeli frecvente

• Ignorarea resurselor (Requests/Limits): Dacă nu setezi cerințe minime de CPU/Memory, Scheduler-ul poate plasa poduri pe noduri supraîncărcate, ducând la OOM Kill sau throttling sever.
• Confundarea Nodului cu Podul: Nodul este mașina virtuală/fizică; Podul este unitatea atomică de execuție care poate conține unul sau mai multe containere partajând rețeaua și stocarea.
• Neglijarea securității etcd-ului: etcd stochează date sensibile (parole, token-uri). Fără criptare în repaus și acces controlat strict, un atacator poate prelua controlul întregului cluster.

Întrebări de interviu

1. Ce se întâmplă când un nod devine unreachable? Răspuns: Kubelet se oprește din a trimite heartbeat-uri. După un timeout (default 40s), Node Controller marchează nodul ca NotReady. Scheduler-ul nu mai plasează poduri noi acolo, iar podurile existente sunt șterse și recreate pe alte noduri disponibile.

2. De ce este important ca etcd să fie replicat? Răspuns: etcd este sursa adevărului. Dacă un singur nod etcd cade, clusterul poate continua să funcționeze dacă majoritatea nodurilor etcd sunt active (quorum). Dacă pierzi majoritatea, clusterul devine read-only sau inaccesibil.

3. Diferența dintre Kubelet și Container Runtime? Răspuns: Kubelet este agentul Kubernetes care orchestrează; el spune ce trebuie rulat și când. Container Runtime (ex: containerd) este motorul care execută efectiv comenzile OCI pentru a crea și runde procesele în containere.

Exercițiu

Construiește un cluster local folosind minikube sau kind (durata: 30 min).

1. Creează un Deployment cu 2 replicași pentru o imagine simplă (ex: nginx).
2. Execută kubectl get nodes și identifică pe ce nod rulează fiecare pod (kubectl get pods -o wide).
3. Simulează o defecțiune: oprește serviciul kubelet pe un nod (sau șterge nodul în mediul local).
4. Observă cum Scheduler-ul redistribuie podurile pe nodul rămas și notează timpii de reconectare.