În scripturile de CI/CD (GitHub Actions, GitLab CI, Jenkins), o eroare frecventă este rularea comenzii kubectl apply urmată imediat de teste automate sau pași de migrare. Deoarece aplicarea este asincronă, Pod-urile noi nu sunt încă gata în acel moment, ceea ce duce la eșecuri false în testele automate. Comanda kubectl wait blochează scriptul și așteaptă până când o anumită condiție este îndeplinită, eșuând curat dacă se depășește timpul limită (timeout).
Scenarii comune de utilizare pentru kubectl wait în CI/CD
# 1. Așteptarea ca toate replicile unui Deployment să fie inițializate și sănătoase:
kubectl wait --for=condition=Available deployment/api-server -n prod --timeout=180s
# 2. Așteptarea finalizării cu succes a unui Job de migrare a bazei de date:
kubectl wait --for=condition=Complete job/db-migration --timeout=300s
# 3. Așteptarea ca un Pod vechi să fie complet șters înainte de a continua:
kubectl wait --for=delete pod/old-worker-instance --timeout=60s
# 4. Așteptarea ca un nod să devină 'Ready' după un reboot de mentenanță:
kubectl wait --for=condition=Ready node/worker-node-3 --timeout=120s
Cod de ieșire în scripturi: Dacă starea cerută este atinsă în intervalul de timeout,
kubectl wait returnează codul de ieșire 0. Dacă timpul expiră fără ca resursa să fie gata, comanda returnează 1, oprind imediat pipeline-ul de CI/CD și prevenind lansarea unei versiuni defecte în producție.