Skip to content
Latchkey

kubectl rollout restart: Usage, Options & Common CI Errors

Restart every pod in a workload without editing its spec.

kubectl rollout restart performs a rolling restart of a Deployment, StatefulSet, or DaemonSet, cycling its pods while keeping the spec unchanged. It is the standard way to make pods re-read a rotated Secret or ConfigMap in CI.

What it does

kubectl rollout restart deploy/NAME stamps a restartedAt annotation into the pod template, which Kubernetes treats as a change and rolls out gradually - honouring maxSurge/maxUnavailable so there is no downtime. Nothing about the desired image or env changes; only the pods are replaced.

Common usage

Terminal
kubectl rollout restart deploy/web
kubectl rollout restart statefulset/db
kubectl rollout restart deploy/web && kubectl rollout status deploy/web --timeout=120s

Common errors in CI

A restart can stall exactly like a deploy: if the new pods fail readiness, the rolling restart wedges at maxUnavailable and never completes, so always follow it with kubectl rollout status --timeout so the step fails fast. A common misconception is that restart reloads a mounted ConfigMap automatically - it does, because the new pods re-mount it, but env vars sourced from a ConfigMap at start time only update on restart, which is exactly why this command exists. Restarting a single-replica Deployment briefly drops the service unless you have a surge configured.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →