15 Automating Application Updates with Deployments
This chapter introduces Deployments as the primary, declarative way to run and evolve stateless applications on Kubernetes. A Deployment manages Pods indirectly through ReplicaSets, enabling automated rollouts and rollbacks while preserving availability. You learn how to create Deployments (from scratch or by converting existing manifests), how label selectors and the controller-owned pod-template-hash isolate the correct Pods, how to inspect rollout status, and how scaling works through the Deployment’s ownership of the underlying ReplicaSet. The text also highlights ownership rules (manual changes to a controlled ReplicaSet are reverted), adoption/orphaning behavior when deleting or recreating Deployments, and a common pitfall: unintentionally changing replica counts when reapplying manifests that include the replicas field.
The core of the chapter focuses on application updates. Two strategies are covered: Recreate (all old Pods stop, then all new Pods start, causing downtime) and RollingUpdate (old and new Pods are swapped gradually to keep the service available). Rolling updates are driven by two parameters—maxSurge and maxUnavailable—which control how many extra or unavailable Pods are allowed per step, and by minReadySeconds, which delays rollout progress until Pods have remained ready for a specified time. You learn to monitor and steer the process with rollout status, pause and resume, and progress deadlines, and to make updates safer by combining readiness probes with minReadySeconds to catch faulty versions early. When needed, you can undo or roll back to specific revisions, inspect revision history (stored in the preserved ReplicaSets), and even trigger controlled restarts using the same strategy as updates.
Beyond standard rolling updates, the chapter outlines how to implement common release patterns with native building blocks. Canary can be approximated by pausing after the first new Pod(s), by using a high minReadySeconds, or by running a small parallel canary Deployment behind the same Service to send only a small fraction of traffic to the new version. A/B testing is achieved by routing subsets of users to separate Services (and Deployments) via Ingress rules. Blue/Green keeps two parallel Deployments and switches traffic by changing the Service’s selector, while traffic shadowing mirrors requests to a non-serving Deployment for realistic validation without user impact. Combined with careful manifest management, troubleshooting of ReplicaSet/ServiceAccount issues, and disciplined use of kubectl commands, these patterns provide safe, automated, and observable application evolution on Kubernetes.
The relationship between Deployments, ReplicaSets and Pods.
Label selectors in the Deployment and ReplicaSet, and the labels in the Pods.
Scaling a Deployment
The difference between the Recreate and the RollingUpdate strategies
Updating a Deployment
What happens with the ReplicaSets, Pods, and the Service during a rolling update.
How Pods are replaced when maxSurge is 0 and maxUnavailable is 1
How Pods are replaced when maxSurge is 1 and maxUnavailable is 0
How Pods are replaced when both maxSurge and maxUnavailable are 1
A Deployment’s revision history
Implementing the Canary deployment strategy using two Deployments
Implementing the A/B strategy using two Deployments, Services, and an Ingress
Implementing a Blue/Green deployment with labels and selectors
Implementing Traffic shadowing
Summary
- Deployment is an abstraction over ReplicaSets. In addition to all the functionality that a ReplicaSet provides, Deployments also allow you to update Pods declaratively. When you modify the Pod template, the old Pods are replaced with new Pods created using the updated template.
- During an update, the Deployment controller replaces Pods based on the strategy configured in the Deployment. In the Recreate strategy, all Pods are replaced at once, while in the RollingUpdate strategy, they’re replaced gradually.
- Pods created by a ReplicaSet are owned by that ReplicaSet. The ReplicaSet is usually owned by a Deployment. If you delete the owner, the dependents are deleted by the garbage collector, but you can tell kubectl to orphan them instead.
- Other deployment strategies aren’t directly supported by Kubernetes, but can be implemented by appropriately configuring Deployments, Services, and the Ingress.
FAQ
What is a Kubernetes Deployment and how does it relate to ReplicaSets and Pods?
- A Deployment is a higher-level controller that manages Pods indirectly through ReplicaSets.
- You declare the desired state (Pod template, selector, replicas, strategy); the Deployment creates/updates a ReplicaSet, which creates the Pods.
- Updating a Deployment’s Pod template triggers Kubernetes to replace Pods automatically according to the configured update strategy.
Why didn’t my existing Pods get adopted by a new Deployment?
- Deployments add a computed
pod-template-hashlabel to their ReplicaSet and Pods. - Your old Pods likely lack that label, so they won’t match the new ReplicaSet’s selector and won’t be adopted.
- Result: you may see both the old Pods and the new Deployment’s Pods running concurrently until you delete the old ones or align labels.
How can I troubleshoot a Deployment that shows no Pods?
- Describe the Deployment and check Conditions (e.g.,
ReplicaFailure) for messages. - Describe the underlying ReplicaSet and its Events; common causes include forbidden Pod creation due to RBAC/service account issues.
- General flow:
kubectl describe deploy→ inspect Conditions →kubectl describe rs <name>→ inspect Events.
What are the key spec fields in a Deployment?
replicas: desired Pod count.selector: labels that define the Deployment’s membership.template: the Pod template used for new Pods.strategy: how updates roll out (RecreateorRollingUpdatewith options).
How do I scale a Deployment, and what if I scale its ReplicaSet directly?
- Scale the Deployment via manifest apply,
kubectl edit, orkubectl scale deploy <name> --replicas N. - If you scale the owned ReplicaSet directly, the Deployment controller will revert it to match the Deployment’s desired replica count.
- Rule of thumb: change the owner (Deployment), not its managed objects.
How can I avoid accidentally changing replica counts when reapplying manifests?
- Omit
spec.replicasin the original manifest and manage scale separately (e.g., viakubectl scaleor an HPA). - If
replicasis present, reapplying can overwrite your live scale; omitting it later defaults to 1. - Fix last-applied config with
kubectl apply edit-last-applied deploy/<name>and removereplicas.
What’s the difference between Recreate and RollingUpdate strategies?
- Recreate: delete all old Pods first, then create all new ones; service is briefly unavailable.
- RollingUpdate (default): gradually replace Pods; the Service remains available throughout.
- Use Recreate when old and new versions can’t coexist; otherwise prefer RollingUpdate for zero(ish)-downtime.
How do maxSurge and maxUnavailable control a rolling update?
maxSurge: how many extra Pods above desired replicas are allowed during rollout (number or percent; rounded up).maxUnavailable: how many Pods can be unavailable relative to desired replicas (number or percent; rounded down).- Examples (desired=3):
maxSurge=0,maxUnavailable=1: replace Pods one-by-one, never exceed 3 total.maxSurge=1,maxUnavailable=0: temporarily run up to 4 Pods, always keep 3 available.
- Both cannot be 0 at the same time.
What is minReadySeconds and how does it help prevent faulty rollouts?
- Pods become “available” only after being Ready for at least
minReadySeconds. - The Deployment waits for availability before progressing; if a new Pod crashes or fails readiness during that window, progress pauses.
- Setting a higher value creates a built-in canary-like guard that can stop spreading a bad version.
How do I pause/resume a rollout and roll back to previous versions?
- Pause/resume:
kubectl rollout pause|resume deploy/<name>to inspect behavior mid-rollout or stage multiple spec changes. - Status/progress:
kubectl rollout status; tune progress deadline viaspec.progressDeadlineSeconds. - Rollback:
kubectl rollout undo deploy/<name>(or--to-revision=N) rolls back the Pod template using the same update strategy. - History:
kubectl rollout history deploy/<name> [--revision N]; revisions map to preserved ReplicaSets (revisionHistoryLimitcontrols how many). - Note:
undochanges only the Pod template; applying an older manifest may also overwrite strategy and replica settings.
How can I implement canary, blue/green, A/B, or traffic shadowing strategies with Kubernetes?
- Canary: use a small separate Deployment plus the existing Service (small fraction of traffic), or pause the main rollout, or use large
minReadySeconds. - Blue/Green: run two Deployments (Blue and Green) and switch the Service’s selector from Blue to Green when ready.
- A/B: two Deployments and Services; route users via Ingress rules based on headers/cookies/paths; depends on Ingress capabilities.
- Shadowing: mirror traffic to a non-Service-targeted Deployment via an Ingress/proxy that supports traffic mirroring; discard shadow responses.
- For advanced automation and weighted traffic, consider tools like Flagger or Argo Rollouts.
Kubernetes in Action, Second Edition ebook for free
