15 Automating application updates with Deployments

Deployments are the primary Kubernetes abstraction for running and updating stateless applications declaratively. A Deployment manages Pods indirectly through an automatically created ReplicaSet, letting you define a Pod template, label selector, desired replicas, and an update strategy. Because Deployments compute and add a pod-template-hash label, they adopt and manage only Pods created from their own template. You create and inspect Deployments with kubectl, scale them directly (the controller adjusts the underlying ReplicaSet), and can delete them while orphaning resources if needed. A common pitfall is unintentionally changing replica counts when reapplying manifests; omitting replicas in the original manifest or fixing the last-applied annotation prevents accidental rescaling.

Updating is where Deployments shine. Two strategies are supported: Recreate (delete all old Pods, then create new ones) and RollingUpdate (gradually replace old Pods while keeping the service available). Rolling behavior is governed by maxSurge and maxUnavailable, which control how many extra Pods can be added and how many can be unavailable at each step, and minReadySeconds, which delays rollout progress until new Pods have been stably ready for a period. You can change images via kubectl set image or patch multiple fields at once, pause/resume rollouts, watch progress, and roll back either to the previous or a specific recorded revision (history is retained via old ReplicaSets, bounded by revisionHistoryLimit). Readiness and availability differ: a Pod becomes “available” only after remaining ready for minReadySeconds, which, combined with probes and a progress deadline, helps prevent faulty versions from fully rolling out.

Beyond Recreate and RollingUpdate, several strategies can be composed with Kubernetes primitives. Canary can be approximated by pausing early in a rollout or by running a small canary Deployment alongside the stable one so only a fraction of traffic reaches the new version. A/B testing uses two Deployments and Services with Ingress routing based on attributes (for sticky, targeted experiments). Blue/Green runs two parallel Deployments and switches traffic by changing the Service’s selector, enabling instant cutover and easy rollback. Traffic shadowing mirrors production requests to a separate Deployment, discarding its responses to validate behavior under real load. While these patterns can be implemented manually with Deployments, Services, and Ingress, higher-level controllers can automate them in production environments.

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

Replacing pods when maxSurge is 0 and maxUnavailable is 1

Replacing pods 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

• 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 the owner is deleted, 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