Când lansezi o versiune nouă a unei aplicații în Kubernetes, este esențial să poți urmări progresul actualizării și să poți interveni rapid dacă noua versiune prezintă erori majore.
Suita de comenzi kubectl rollout oferă control complet asupra ciclului de viață al deployment-urilor: comanda status monitorizează trecerea graduală a pod-urilor pe noua versiune, restart forțează o repornire elegantă (rolling restart) fără a întrerupe traficul utilizatorilor (utilă la actualizarea unui Secret sau ConfigMap), iar undo execută un rollback instantaneu la versiunea stabilă precedentă.
Toate reviziile anterioare sunt păstrate în istoricul etcd conform parametrului `revisionHistoryLimit`, permițând revenirea la orice stare salvată din trecut.
Sintaxă, opțiuni și concepte cheie
| Opțiune / Concept | Descriere practică |
|---|---|
status deployment/ |
Urmărește în timp real încheierea procesului de actualizare a pod-urilor. |
restart deployment/ |
Declanșează o repornire treptată a tuturor pod-urilor fără oprirea serviciului. |
undo deployment/ |
Revenire imediată la ultima revizie funcțională a deployment-ului. |
undo --to-revision= |
Revenire la o revizie specifică din istoricul de versiuni. |
history deployment/ |
Afișează istoricul reviziilor anterioare salvate în cluster. |
Exemple practice și cod
Exemplul 1: Repornirea elegantă a unui serviciu după actualizarea bazei de date și rollback la eroare
Comenzile esențiale de management de producție.
# 1. Repornim graceful toate pod-urile din deployment:
$ kubectl rollout restart deployment/api-gateway
# 2. Urmărim progresul în terminal:
$ kubectl rollout status deployment/api-gateway
Waiting for deployment "api-gateway" rollout to finish: 1 out of 3 new replicas have been updated...
deployment "api-gateway" successfully rolled out
# 3. Dacă noua versiune prezintă probleme critice, facem rollback instant:
$ kubectl rollout undo deployment/api-gateway
deployment.apps/api-gateway rolled backRezultat & Impact
Revenire la starea funcțională anterioară în sub 5 secunde cu zero downtime.Greșeli frecvente și bune practici
- Setarea unui `readinessProbe` configurat greșit, ceea ce face ca `kubectl rollout status` să rămână blocat la infinit deoarece noile pod-uri nu devin niciodată ‘ready’.
- Configurarea `revisionHistoryLimit: 0` în manifest, ceea ce dezactivează complet istoricul și face imposibilă comanda `rollout undo`.