Understand application deployments and how to perform rolling update and rollbacks
5 minutes
5 Questions
In the context of the CKA exam, a Deployment is the standard resource for managing stateless applications. It acts as a wrapper around ReplicaSets, ensuring the desired number of Pods are running and managing their lifecycle. The two critical lifecycle operations are Rolling Updates and Rollbacks.
âŚIn the context of the CKA exam, a Deployment is the standard resource for managing stateless applications. It acts as a wrapper around ReplicaSets, ensuring the desired number of Pods are running and managing their lifecycle. The two critical lifecycle operations are Rolling Updates and Rollbacks.
**Rolling Updates** are the default deployment strategy. When you update the Pod template (for example, changing the container image from v1 to v2), Kubernetes does not terminate all existing Pods simultaneously. Instead, it spins up a new ReplicaSet and incrementally scales it up while scaling down the old ReplicaSet. This ensures zero downtime. The speed and safety of this transition are controlled by the `maxSurge` (how many extra pods can exist) and `maxUnavailable` (how many pods can be down) parameters in the YAML manifest.
To perform a rolling update imperatively, execute:
`kubectl set image deployment/myapp container-name=image:v2`
Monitor the progress with:
`kubectl rollout status deployment/myapp`
**Rollbacks** allow you to revert changes if an update fails or introduces bugs. Kubernetes maintains a history of Deployment revisions.
To view the revision history:
`kubectl rollout history deployment/myapp`
To undo the deployment and revert to the previous revision:
`kubectl rollout undo deployment/myapp`
To revert to a specific revision number:
`kubectl rollout undo deployment/myapp --to-revision=2`
For the exam, you must be proficient with the `kubectl rollout` command suite, including how to pause and resume rollouts (`kubectl rollout pause/resume`) to stack multiple changes before triggering the update.
Understanding Application Deployments, Rolling Updates, and Rollbacks
Why is this important? In a production Kubernetes environment, applications need to be updated (changing container images, configurations, or labels) without causing downtime. The Deployment controller is crucial because it manages the state of Pods and ReplicaSets, allowing for seamless updates and, if necessary, the ability to revert changes quickly if an update breaks the application. This is a core competency for the CKA exam.
What is it? A Deployment is a higher-level Kubernetes object that wraps around a ReplicaSet to manage Pods. A Rolling Update is the default deployment strategy where Pods are updated incrementally (replacing old versions with new ones) rather than all at once. A Rollback is the process of reverting a Deployment to a previous revision in its history (a specific ReplicaSet configuration).
How it works: When you modify the PodTemplateSpec of a Deployment (e.g., changing the image version), Kubernetes creates a new ReplicaSet. It slowly scales up the new ReplicaSet and scales down the old ReplicaSet. The speed of this process is controlled by the maxSurge (how many extra pods can be created) and maxUnavailable (how many pods can be down) parameters. Kubernetes keeps a history of these ReplicaSets, allowing you to run a command to switch the Deployment pointer back to an older ReplicaSet (Rollback).
How to answer questions on this topic: 1. Creating Deployments: Use the imperative command to save time. kubectl create deployment my-dep --image=nginx:1.14.2 --replicas=3. 2. Updating Images: Do not write YAML from scratch. Use kubectl set image deployment/my-dep nginx=nginx:1.16.1 or kubectl edit deployment my-dep. 3. Verifying Updates: Always check if the update is successful. Use kubectl rollout status deployment/my-dep. If the status hangs, check kubectl get pods to see if there is an ErrImagePull or ImagePullBackOff error. 4. Rolling Back: If asked to undo a change, first view the history with kubectl rollout history deployment/my-dep, then perform the rollback using kubectl rollout undo deployment/my-dep. You can also rollback to a specific revision using --to-revision=X.
Exam Tips: Answering Questions on Understand application deployments and how to perform rolling update and rollbacks Tip 1: Memorize the imperative commands. Using kubectl set image is significantly faster than editing a YAML file. Tip 2: If a question asks you to update an image and 'record' the change, be aware that the --record flag is deprecated but may still appear in older context. However, usually, the exam just wants you to perform the update. You can verify the history exists via kubectl rollout history. Tip 3: Watch out for typos in image names. A common trap is asking you to update to an image that does not exist. The Pods will enter a crash loop. You will then likely be asked to fix it by rolling back. Always verify the Pod status after an update command.