kubectl rollout

Zarządza wdrożeniem: status, restart, cofnięcie (rollback).

kubectl rollout to zestaw poleceń do zarządzania cyklem życia wdrożeń w Kubernetes — głównie obiektów deployment, ale też daemonset i statefulset. Dzięki niemu sprawdzisz, czy nowa wersja aplikacji w ogóle się wstała, wymusisz restart wszystkich podów, podejrzysz historię zmian albo cofniesz się do poprzedniej wersji, gdy świeży deploy okazał się katastrofą. To Twój panel sterowania, kiedy chcesz wiedzieć, co się dzieje z aplikacją w klastrze i jak to odkręcić.

Składnia i najważniejsze opcje

Podstawowa konstrukcja wygląda tak: kubectl rollout PODKOMENDA TYP/NAZWA [flagi]. Dostępne podkomendy:

  • status — pokazuje, czy wdrożenie się zakończyło; domyślnie blokuje terminal i czeka aż wszystkie pody będą gotowe.
  • history — lista rewizji (wersji) danego zasobu wraz z numerami i opisem zmian.
  • undo — cofnięcie do poprzedniej rewizji (rollback).
  • restart — wymusza stopniowy restart podów bez zmiany obrazu, dodając adnotację do szablonu poda.
  • pause / resume — wstrzymuje i wznawia wdrożenie, np. by wprowadzić kilka zmian naraz i puścić je jednym ruchem.
  • --to-revision=N — przy undo wskazuje konkretną rewizję do przywrócenia (domyślnie poprzednia, czyli 0).
  • --revision=N — przy history pokazuje szczegóły jednej konkretnej rewizji.
  • --timeout=300s — przy status ustawia, jak długo czekać zanim polecenie się podda i zwróci błąd.

Przykłady użycia

  • kubectl rollout status deployment/web — czeka i raportuje, aż nowa wersja deploymentu web w pełni się wdroży.
  • kubectl rollout restart deployment/web — restartuje wszystkie pody po kolei, np. żeby załapały świeży sekret albo ConfigMap.
  • kubectl rollout history deployment/web — wyświetla listę rewizji, żebyś wiedział, do której chcesz wrócić.
  • kubectl rollout undo deployment/web --to-revision=3 — cofa web do konkretnej, sprawdzonej rewizji numer 3.
  • kubectl rollout status deployment/web --timeout=120s — to samo co status, ale poddaje się po 2 minutach zamiast wisieć w nieskończoność.

Częste błędy i pułapki

Restart to nie redeploy. rollout restart nie pobiera nowego obrazu z tagiem :latest — on tylko odtwarza pody na tej samej specyfikacji. Jeśli liczysz na świeży build, zmień tag obrazu albo użyj kubectl set image.

Historia bywa pusta. Sensowne opisy w history zobaczysz tylko, gdy wcześniej zapisywałeś zmiany z adnotacją kubernetes.io/change-cause lub stosujesz --record (przestarzałe). Bez tego dostaniesz gołe numery rewizji.

Limit rewizji. Kubernetes trzyma ograniczoną liczbę starych ReplicaSetów (revisionHistoryLimit, domyślnie 10). Stare rewizje znikają, więc undo --to-revision do bardzo starej wersji może po prostu nie zadziałać.

Pause blokuje rollout. Gdy wstrzymasz wdrożenie przez pause, kolejne zmiany się kumulują i nic się nie dzieje, dopóki nie zrobisz resume. Łatwo o tym zapomnieć i zastanawiać się, czemu deploy stoi.

Powiązane komendy: kubectl apply, kubectl set image, kubectl get deployment, kubectl describe, kubectl scale.