kubectl rollout resume

When to Use kubectl rollout resume

kubectl rollout resume completes the pause-resume workflow by triggering the rollout of changes accumulated while the deployment was paused. It is always used in conjunction with kubectl rollout pause and should be followed by kubectl rollout status to verify the rollout succeeds.

Basic Resume Workflow

Resume is always the second step after pause:

# Step 1: Pause
kubectl rollout pause deployment/my-app

# Step 2: Make changes
kubectl set image deployment/my-app app=myapp:v2
kubectl set env deployment/my-app FEATURE_FLAG=true

# Step 3: Resume
kubectl rollout resume deployment/my-app

# Step 4: Monitor
kubectl rollout status deployment/my-app

What Happens on Resume

When you resume a paused deployment:

1. Kubernetes evaluates all pod template changes made during the pause.
2. A new ReplicaSet is created with the combined changes.
3. The rolling update begins according to the deployment's strategy.
4. The progress deadline timer starts.

# Resume the deployment
kubectl rollout resume deployment/my-app
# deployment.apps/my-app resumed

# Watch the new ReplicaSet being created
kubectl get rs -l app=my-app --sort-by=.metadata.creationTimestamp

# Monitor pod replacement
kubectl get pods -l app=my-app -w

Resume with Verification

Always verify the rollout after resuming:

# Resume and immediately monitor
kubectl rollout resume deployment/my-app
kubectl rollout status deployment/my-app --timeout=300s

# If the rollout fails, investigate
if [ $? -ne 0 ]; then
  echo "Rollout failed after resume"
  kubectl describe deployment my-app
  kubectl get pods -l app=my-app
  kubectl logs -l app=my-app --tail=50
fi

Resuming When No Changes Were Made

If you pause and resume without making any changes, nothing happens. Kubernetes detects that the pod template has not changed and does not create a new ReplicaSet:

# Pause and immediately resume — no effect
kubectl rollout pause deployment/my-app
kubectl rollout resume deployment/my-app
# No rollout is triggered because the pod template did not change

Finding and Resuming Paused Deployments

In large clusters, you may need to find deployments that were accidentally left paused:

# Find all paused deployments across the cluster
kubectl get deployments -A -o json | \
  jq -r '.items[] | select(.spec.paused == true) | "\(.metadata.namespace)/\(.metadata.name)"'

# Resume all paused deployments in a namespace
for deploy in $(kubectl get deployments -n staging -o json | \
  jq -r '.items[] | select(.spec.paused == true) | .metadata.name'); do
  echo "Resuming $deploy"
  kubectl rollout resume deployment/$deploy -n staging
done

Scripted Pause-Resume Pattern

A complete script for batching changes safely:

#!/bin/bash
set -e

DEPLOYMENT="my-app"
NAMESPACE="production"

# Pause
kubectl rollout pause deployment/${DEPLOYMENT} -n ${NAMESPACE}
echo "Deployment paused"

# Trap to ensure resume happens even if script fails
trap "kubectl rollout resume deployment/${DEPLOYMENT} -n ${NAMESPACE}" EXIT

# Make all changes
kubectl set image deployment/${DEPLOYMENT} app=myapp:v2.0 -n ${NAMESPACE}
kubectl set resources deployment/${DEPLOYMENT} -c app \
  --limits=cpu=1,memory=512Mi \
  --requests=cpu=250m,memory=256Mi -n ${NAMESPACE}

echo "Changes applied, resuming..."

# Resume (also triggered by trap on exit)
kubectl rollout resume deployment/${DEPLOYMENT} -n ${NAMESPACE}

# Remove the trap since we already resumed
trap - EXIT

# Monitor
kubectl rollout status deployment/${DEPLOYMENT} -n ${NAMESPACE} --timeout=300s
echo "Rollout complete"

The trap ensures the deployment is resumed even if the script encounters an error, preventing accidentally paused deployments.

Resume and Rollback

After resuming, if the rollout reveals issues, you can roll back:

# Resume
kubectl rollout resume deployment/my-app

# Wait for rollout
kubectl rollout status deployment/my-app --timeout=120s

# If failed, roll back
kubectl rollout undo deployment/my-app
kubectl rollout status deployment/my-app --timeout=120s

You cannot roll back a paused deployment. You must resume first, let the rollout proceed (or fail), and then roll back if needed.

Best Practices

Always pair resume with status monitoring. Use shell traps in scripts to ensure deployments are never left paused. Verify all intended changes were applied before resuming. Include resume in runbooks and CI/CD scripts alongside the corresponding pause command. Monitor your cluster for accidentally paused deployments as part of regular health checks.