Kubernetes Basics
Deployments — Rolling Updates and Rollbacks
Deployments manage the lifecycle of application replicas by automating the transition between different versions of container images. This mechanism ensures zero-downtime updates by incrementally replacing old pods with new ones based on configured strategies. You reach for Deployments when you need to provide continuous service availability while maintaining the ability to revert to a stable state during deployment failures.
Understanding the Deployment Controller
The Deployment controller acts as a declarative manager for your application's state. When you submit a Deployment manifest, you define the desired number of replicas and the specific container image to run. Unlike manually managing individual pods, the Deployment constantly observes the cluster state against your desired configuration. If a node fails or a pod crashes, the controller intervenes by recreating the necessary containers to meet the target count. This abstraction is fundamental because it decouples your intent from the underlying orchestration mechanics. By utilizing a ReplicaSet under the hood, the Deployment ensures that the desired number of pods are consistently available. When you modify the image version, the Deployment doesn't simply destroy all existing pods; it initiates a coordinated update sequence. This architectural choice is why Kubernetes is capable of maintaining service uptime even while your backend logic is being upgraded across a distributed set of nodes.
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.25 # The target container image version
ports:
- containerPort: 80The Mechanics of Rolling Updates
Rolling updates are the default strategy for ensuring your services remain reachable while moving from version A to version B. When you update the image tag in your Deployment manifest, the system orchestrates a phased transition. It starts by creating a new pod with the updated image and waiting for it to report as 'Ready' through health checks. Only after the new pod is confirmed to be healthy does it terminate one of the old pods. This incremental process continues until the entire replica set has been replaced. The 'why' behind this is critical: by overlapping the lifecycle of old and new pods, you maintain a continuous pool of capacity to handle incoming requests. If you were to shut down all old pods simultaneously, your service would experience a period of total downtime. This strategy effectively guarantees that the traffic load is always distributed across functional pods throughout the entire release cycle.
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0 # Ensures no pods are lost during update
maxSurge: 1 # Allows creating one extra pod during the transitionManaging Update Speed and Availability
Controlling the pace of a rolling update is achieved through the 'maxSurge' and 'maxUnavailable' parameters. 'maxSurge' defines how many pods can be created above the desired replica count during the update process, while 'maxUnavailable' defines how many pods can be taken offline simultaneously. These knobs are vital because they allow you to trade off update speed against resource utilization. For instance, if you have a cluster with limited compute resources, you might set these values to ensure that you do not exceed your total memory capacity during the update window. Understanding these parameters is essential for large-scale production environments where sudden spikes in resource demand could lead to node pressure or eviction events. By tuning these settings, you effectively balance the speed at which new features reach your users against the risk of temporary resource exhaustion during the rollout phase of the deployment.
spec:
strategy:
rollingUpdate:
maxSurge: 25% # Can temporarily boost capacity by 25%
maxUnavailable: 0 # Guarantees full capacity throughout updateImplementing Rollbacks on Failure
A rollback is the process of reversing a deployment to a previously known stable state, typically executed when a new version introduces unexpected issues. Kubernetes maintains a history of your Deployment revisions, allowing you to return to any prior configuration instantly. When you identify that an update is failing, the rollback command instructs the Deployment controller to reverse the rolling update process, effectively replacing the problematic pods with those from the identified revision. This is inherently safe because the system treats the previous state as a valid target. The logic relies on the fact that Kubernetes tracks every change in a revision history; by selecting a previous revision, you are essentially telling the controller to treat that old configuration as the new 'desired' state. This is a primary safeguard in modern cloud-native architecture, ensuring that human error or faulty code deployment does not result in prolonged service degradation for your end users.
# Roll back to the previous stable revision
kubectl rollout undo deployment/web-app
# Check revision history to see what was changed
kubectl rollout history deployment/web-appPausing and Resuming Deployments
Sometimes you may need to perform multiple configuration changes in a single update sequence, such as updating an image tag alongside a configuration map or a secret reference. In these cases, it is advantageous to pause the deployment rollout to prevent the system from triggering an immediate update for each individual change. By pausing the rollout, you hold the controller in a waiting state where it will not start new pod replacements until you explicitly resume. This mechanism is crucial for avoiding unnecessary churn in your cluster and ensures that your application transitions to the final desired state only after all interdependent configurations have been applied. Once the changes are complete, resuming the rollout allows the Deployment to proceed with the update strategy as defined. This workflow is a best practice for complex deployments where atomicity of changes is required for the application to function correctly and remain in a stable, consistent state.
# Pause deployment to apply multiple changes safely
kubectl rollout pause deployment/web-app
# Resume the update once configuration is complete
kubectl rollout resume deployment/web-appKey points
- Deployments use a declarative approach to maintain the desired number of application replicas.
- Rolling updates ensure zero downtime by replacing pods one by one in a controlled sequence.
- The maxSurge and maxUnavailable settings allow for precise control over resource consumption during updates.
- Kubernetes tracks the history of deployment revisions to facilitate quick recovery from bad releases.
- A rollback can be triggered via command-line tools to revert to any previous stable configuration.
- Pausing a rollout prevents premature pod restarts while multiple configuration changes are being applied.
- Readiness probes are essential for rolling updates to ensure only healthy pods receive traffic.
- The Deployment controller automatically reconciles the current state with the desired state defined in the manifest.
Common mistakes
- Mistake: Manually deleting pods to trigger an update. Why it's wrong: Pods are ephemeral and managed by the Deployment; deleting them triggers a replacement, not a controlled rollout. Fix: Update the Deployment image or configuration.
- Mistake: Setting 'maxUnavailable' to 0 while having a single replica. Why it's wrong: Kubernetes cannot bring down the old pod before the new one is ready, causing a deadlock. Fix: Ensure 'maxUnavailable' allows for at least one pod down or increase replica count.
- Mistake: Assuming a 'kubectl apply' with a typo in the image tag triggers a rollback. Why it's wrong: Kubernetes treats an invalid image as a deployment configuration change. Fix: Use 'kubectl rollout undo' to revert to the last known stable Revision.
- Mistake: Ignoring readiness probes during a Rolling Update. Why it's wrong: K8s considers a pod ready as soon as the container starts, even if the app isn't ready, leading to traffic hitting broken pods. Fix: Always define a correct readiness probe.
- Mistake: Setting 'maxSurge' and 'maxUnavailable' to 0 simultaneously. Why it's wrong: This results in a zero-change scenario where the deployment cannot scale or swap pods. Fix: Set at least one value to a positive integer or percentage.
Interview questions
What is a rolling update in Kubernetes, and why do we use it?
A rolling update in Kubernetes is the default strategy for updating the version of an application deployed in a cluster. Instead of taking the entire application offline, it incrementally replaces old pods with new ones. We use this because it ensures zero downtime for the end-user. As the deployment controller creates new pods with the updated container image, it simultaneously terminates old pods, maintaining availability while transitioning to the desired state. This is critical for high-availability environments where service continuity is non-negotiable.
How do you trigger a rollback in Kubernetes if a deployment fails?
If a deployment results in errors or unexpected behavior, you can trigger a rollback using the 'kubectl rollout undo' command. For example, typing 'kubectl rollout undo deployment/my-app' will revert the deployment to its previous revision. Kubernetes maintains a history of 'ReplicaSets' specifically to facilitate this. It works by shifting the traffic back to the prior stable state defined in the previous revision. This allows for an instantaneous recovery from bad code, preventing prolonged outages when a deployment goes wrong.
What is the role of the 'maxSurge' and 'maxUnavailable' parameters in a rolling update?
These parameters control the pace of a rolling update and define resource constraints. 'maxSurge' specifies the maximum number of pods that can be created above the desired replica count during the update process—for instance, if set to 25%, it creates extra pods immediately. 'maxUnavailable' defines how many pods can be taken down simultaneously during the update. By tuning these, you balance the trade-off between deployment speed and cluster resource consumption, ensuring you have enough capacity to handle requests while the cluster migrates to the new version.
Compare the Rolling Update strategy with the Recreate strategy in Kubernetes.
The Recreate strategy shuts down all existing pods of the old version before creating any pods of the new version. This results in a temporary outage, which is why it is rarely used in production, though it is useful if your application cannot handle having two versions running simultaneously. Conversely, the Rolling Update strategy replaces pods incrementally, ensuring continuous availability. While Rolling Update is safer for users, Recreate is easier to implement for simple, stateful applications that cannot tolerate concurrent dual-version states.
How does Kubernetes use ReplicaSets to manage rolling updates and rollbacks?
Kubernetes deployments manage the lifecycle of pods through ReplicaSets. During a rolling update, the deployment controller creates a new ReplicaSet for the new image version and scales it up while scaling the old ReplicaSet down. This decoupling is essential; the old ReplicaSet is not deleted immediately but kept at zero or a partial scale. This architecture is exactly why rollbacks are possible: because the previous ReplicaSet definition still exists, Kubernetes can simply re-scale that old ReplicaSet and terminate the new ones to revert the cluster to the last known good state.
How would you pause and resume a rolling update, and why would you want to do this?
You can pause an update using 'kubectl rollout pause deployment/my-app'. This is highly valuable during a 'canary deployment' scenario, where you want to observe the new version's performance on a small subset of traffic before completing the full rollout. While paused, you can inspect logs or metrics. Once you are confident the update is stable, you use 'kubectl rollout resume' to allow Kubernetes to continue replacing the remaining pods. This manual intervention provides a layer of safety, acting as a gatekeeper against faulty code reaching your entire production fleet.
Check yourself
1. If you have 10 replicas and set 'maxSurge' to 2 and 'maxUnavailable' to 0, what is the behavior during a rolling update?
- A.It will scale down to 8 and then up to 10
- B.It will create 2 new pods before terminating any old pods
- C.It will terminate 2 pods and then create 2 new pods
- D.It will update all 10 pods simultaneously
Show answer
B. It will create 2 new pods before terminating any old pods
With maxSurge=2 and maxUnavailable=0, K8s creates new pods first, ensuring capacity never drops below 10. The other options describe scenarios where capacity drops (violating maxUnavailable=0) or where no surge occurs.
2. What is the primary purpose of a Deployment Revision in Kubernetes?
- A.To record the history of changes for rollback purposes
- B.To enable high availability across multiple clusters
- C.To store the secrets used by the container images
- D.To define the network policies for the pods
Show answer
A. To record the history of changes for rollback purposes
Revisions allow users to track changes and perform rollbacks to a specific previous configuration. The other options refer to networking, security, or multi-cluster architecture, not the rollout mechanism.
3. Why would a rolling update stop and stay in a 'progressing' state indefinitely?
- A.The Deployment reached the maxSurge limit
- B.The new pods are failing their readiness probes
- C.The cluster has reached its maximum pod count
- D.The old pods are still processing incoming traffic
Show answer
B. The new pods are failing their readiness probes
If readiness probes fail, the Deployment controller will not consider the new pods 'Ready' and will not proceed with terminating old pods. The other options do not prevent a deployment from progressing toward its target state.
4. What happens when you run 'kubectl rollout undo' on a deployment that is currently updating?
- A.It stops the deployment and leaves it in an inconsistent state
- B.It pauses the update and waits for manual intervention
- C.It reverts the deployment to the previous revision
- D.It immediately deletes all existing pods
Show answer
C. It reverts the deployment to the previous revision
Rolling undo reverts the deployment configuration to the state recorded in the previous revision. The other options suggest either errors or destructive actions that don't align with K8s' declarative nature.
5. When performing a rolling update, how does the Service object know which pods to send traffic to?
- A.By identifying the specific Pod IDs in the Deployment
- B.By tracking the Pod creation timestamps
- C.By matching the Pod labels to the Service selector
- D.By communicating directly with the Container Runtime
Show answer
C. By matching the Pod labels to the Service selector
Services use label selectors to dynamically discover pods. As old pods are terminated and new ones created, they all share the same labels, allowing for seamless traffic shifting. The other methods are not how Services discover pods.