kubectl rollout resume: Usage, Options & Common CI Errors
Release a paused Deployment and roll out the batched changes.
kubectl rollout resume clears the paused flag on a Deployment, so the changes accumulated since the pause roll out together. It is always the second half of a pause/resume pair in a CI deploy.
What it does
kubectl rollout resume deploy/NAME sets spec.paused=false. The Deployment controller immediately reconciles the recorded template changes into a single new ReplicaSet and rolls forward, respecting maxSurge/maxUnavailable.
Common usage
kubectl rollout resume deploy/web
kubectl rollout status deploy/web --timeout=180s
kubectl get deploy/web -o jsonpath='{.spec.paused}' # should print nothing/falseCommon errors in CI
"error: deployment \"web\" is not paused" on resume just means there was nothing to un-pause - usually a re-run after the first run already resumed; treat it as a soft success in idempotent scripts. The real bug is the opposite: never reaching resume (a step failed between pause and resume) leaves the Deployment frozen, so every later deploy silently no-ops. Guard with kubectl get deploy/web -o jsonpath='{.spec.paused}' at the start of a deploy and resume if it reads true. After resume, gate on rollout status so a bad batched change fails the pipeline.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes