Skip to main content

Rolling update

Un Deployment poate actualiza gradual template-ul Pod-urilor. Fișierul k8s/scenarios/deployment-v2.yaml schimbă:

  • imaginea de la 1.0.0 la 1.1.0
  • label-ul version de la v1 la v2
  • variabila APP_VERSION de la v1 la v2.

Strategia folosită este:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

maxUnavailable: 0 cere ca actualizarea să nu reducă numărul de replici disponibile, iar maxSurge: 1 permite temporar un Pod suplimentar. Kubernetes consideră noul Pod disponibil doar după ce readiness probe-ul reușește.

Într-un terminal, urmăriți Pod-urile:

kubectl get pods -n cc-lab2 -w

În alt terminal, examinați și aplicați noua versiune:

kubectl diff -f k8s/scenarios/deployment-v2.yaml
kubectl apply -f k8s/scenarios/deployment-v2.yaml
kubectl rollout status deployment/ticketing-api -n cc-lab2

Inspectați ReplicaSet-urile și istoricul:

kubectl get replicasets -n cc-lab2
kubectl rollout history deployment/ticketing-api -n cc-lab2

Apelați /info după terminarea rollout-ului:

curl http://localhost:8080/info

Răspunsul trebuie să indice "version":"v2".

Despre „zero downtime”

Această configurație urmărește să păstreze replici pregătite pe durata rollout-ului, dar nu reprezintă o garanție universală de zero downtime. Comportamentul corect depinde și de readiness probes, de capacitatea clusterului și de modul în care aplicația gestionează oprirea și cererile în curs.