kubectl rolloutWatch, undo and restart Deployment rollouts
kubectl rollout manages the rolling updates of Deployments, StatefulSets and DaemonSets: wait for one to finish (status), list revisions (history), roll back (undo), replace every pod gracefully (restart), and pause or resume changes.
kubectl rollout (status | history | undo | restart | pause | resume) TYPE/NAME [--to-revision=N] [--timeout=5m] [-n NS]CI built api:2.5.0. Update the Deployment and block until the rollout succeeds or fails, as a pipeline would.
kubectlThe Kubernetes CLI.
A Deployment never updates pods in place. Each distinct pod template gets its own ReplicaSet, named with a hash of the template and annotated with a revision number. When the template changes (new image, env, resources or a restartedAt annotation), the Deployment controller scales the new ReplicaSet up and the old one down in steps bounded by maxSurge (extra pods allowed, default 25%) and maxUnavailable (pods allowed missing, default 25%), and only counts a new pod once it's Ready for minReadySeconds. rollout status watches the Deployment's status fields (updatedReplicas, availableReplicas, conditions) and exits 0 when done or non-zero when the Progressing condition reports ProgressDeadlineExceeded (default 600s). undo copies an old ReplicaSet's template back into the Deployment, which triggers a normal rolling update. restart just sets a kubectl.kubernetes.io/restartedAt annotation on the template. Old ReplicaSets, kept at 0 replicas up to revisionHistoryLimit (default 10), are what make undo possible.
The Deployment shifts pods from the old ReplicaSet to a new one, one at a time, and only counts pods that pass readiness.
The Deployment owns one active ReplicaSet with 3 pods running api:2.4.1. The Service sends traffic to all three because they are Ready.
statusWait for the rollout to finish; non-zero exit if it failsstatus --timeout=5mGive up waiting after a durationhistory [--revision=N]List revisions, or show one revision's pod templateundo [--to-revision=N]Roll back to the previous or a specific revisionrestartReplace all pods with a rolling update (same spec)pause / resumeBatch several changes into one rollout-w=falsestatus: print the current state once, don't waitRunning kubectl apply in CI and calling it a successful deployapply returns before any pod starts; a broken image or failing probe is never noticed by the pipeline.
kubectl rollout status deploy/api --timeout=5m (non-zero exit fails the job)kubectl rollout undo and moving onGit still has the bad version; the next apply or GitOps sync redeploys it.
Undo to stop the bleeding, then revert the change in GitExpecting rollout restart to pick up a new ConfigMap value automatically everywherePods only see env from ConfigMaps at start; mounted files update eventually but the app may cache them. restart helps only for Deployments, STS and DS.
kubectl rollout restart deploy/api, or put a checksum of the config in a template annotation (Helm pattern)Leaving CHANGE-CAUSE as <none>History then can't tell you which revision held which release.
kubectl annotate deploy/api kubernetes.io/change-cause='release 2.5.0' after each deployTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the commands to roll back the Deployment web in namespace shop to revision 7, after first checking which image revision 7 used.
Write a CI step that fails the job if the Deployment api in prod hasn't finished rolling out within 3 minutes.
Read this: 'Waiting for deployment "api" rollout to finish: 1 old replicas are pending termination...' repeated for 10 minutes. What do you check?
kubectl rolloutWatch, undo and restart Deployment rollouts
kubectl rollout manages the rolling updates of Deployments, StatefulSets and DaemonSets: wait for one to finish (status), list revisions (history), roll back (undo), replace every pod gracefully (restart), and pause or resume changes.
kubectl rollout (status | history | undo | restart | pause | resume) TYPE/NAME [--to-revision=N] [--timeout=5m] [-n NS]CI built api:2.5.0. Update the Deployment and block until the rollout succeeds or fails, as a pipeline would.
kubectlThe Kubernetes CLI.
A Deployment never updates pods in place. Each distinct pod template gets its own ReplicaSet, named with a hash of the template and annotated with a revision number. When the template changes (new image, env, resources or a restartedAt annotation), the Deployment controller scales the new ReplicaSet up and the old one down in steps bounded by maxSurge (extra pods allowed, default 25%) and maxUnavailable (pods allowed missing, default 25%), and only counts a new pod once it's Ready for minReadySeconds. rollout status watches the Deployment's status fields (updatedReplicas, availableReplicas, conditions) and exits 0 when done or non-zero when the Progressing condition reports ProgressDeadlineExceeded (default 600s). undo copies an old ReplicaSet's template back into the Deployment, which triggers a normal rolling update. restart just sets a kubectl.kubernetes.io/restartedAt annotation on the template. Old ReplicaSets, kept at 0 replicas up to revisionHistoryLimit (default 10), are what make undo possible.
The Deployment shifts pods from the old ReplicaSet to a new one, one at a time, and only counts pods that pass readiness.
The Deployment owns one active ReplicaSet with 3 pods running api:2.4.1. The Service sends traffic to all three because they are Ready.
statusWait for the rollout to finish; non-zero exit if it failsstatus --timeout=5mGive up waiting after a durationhistory [--revision=N]List revisions, or show one revision's pod templateundo [--to-revision=N]Roll back to the previous or a specific revisionrestartReplace all pods with a rolling update (same spec)pause / resumeBatch several changes into one rollout-w=falsestatus: print the current state once, don't waitRunning kubectl apply in CI and calling it a successful deployapply returns before any pod starts; a broken image or failing probe is never noticed by the pipeline.
kubectl rollout status deploy/api --timeout=5m (non-zero exit fails the job)kubectl rollout undo and moving onGit still has the bad version; the next apply or GitOps sync redeploys it.
Undo to stop the bleeding, then revert the change in GitExpecting rollout restart to pick up a new ConfigMap value automatically everywherePods only see env from ConfigMaps at start; mounted files update eventually but the app may cache them. restart helps only for Deployments, STS and DS.
kubectl rollout restart deploy/api, or put a checksum of the config in a template annotation (Helm pattern)Leaving CHANGE-CAUSE as <none>History then can't tell you which revision held which release.
kubectl annotate deploy/api kubernetes.io/change-cause='release 2.5.0' after each deployTry these on a Linux machine of your own. Each task has a hint and a solution.
Write the commands to roll back the Deployment web in namespace shop to revision 7, after first checking which image revision 7 used.
Write a CI step that fails the job if the Deployment api in prod hasn't finished rolling out within 3 minutes.
Read this: 'Waiting for deployment "api" rollout to finish: 1 old replicas are pending termination...' repeated for 10 minutes. What do you check?