Reconciliere, self-healing și scalare

ReplicaSet-ul creat de Deployment menține numărul declarat de Pod-uri. Nu îl vom modifica direct, ci vom modifica Deployment-ul.

Self-healing

Deschideți un terminal și urmăriți Pod-urile:

kubectl get pods -n cc-lab2 -w

Într-un alt terminal, identificați și ștergeți unul dintre Pod-uri:

kubectl get pods -n cc-lab2
kubectl delete pod <nume-pod> -n cc-lab2

În terminalul cu -w veți observa că apare un Pod nou. Deployment-ul declară două replici, iar controllerul remediază automat diferența dintre starea dorită și cea observată.

Comparați identificatorii înainte și după ștergere. Numele Pod-ului s-a schimbat, dar Service-ul continuă să folosească label-ul app=ticketing-api.

Scalare

Scalați Deployment-ul la trei replici:

kubectl scale deployment ticketing-api -n cc-lab2 --replicas=3
kubectl get deployment,replicaset,pods -n cc-lab2

Dacă port-forward este încă activ, apelați de mai multe ori endpoint-ul /info:

for i in {1..10}; do
  curl -s http://localhost:8080/info
  echo
done

Puteți primi răspunsuri de la instanțe diferite. Fiecare apel curl deschide o conexiune nouă, iar Service-ul poate selecta un alt Pod.

Reveniți la două replici înainte de exercițiul de rollout:

kubectl scale deployment ticketing-api -n cc-lab2 --replicas=2
kubectl rollout status deployment/ticketing-api -n cc-lab2

notă

Scalarea actuală este manuală. Autoscaling-ul bazat pe metrici necesită componente și politici suplimentare și nu face parte din acest laborator.