What is a Deployment in Kubernetes and how does it handle updates?

Think of a Deployment like a restaurant manager responsible for keeping the right number of cooks on shift. If the manager needs 5 cooks and one calls in sick, they immediately hire a replacement. If the restaurant gets busier, the manager adds more cooks. And when the kitchen switches to a new menu (application update), the manager doesn't fire everyone and start fresh — they gradually train new cooks on the new menu while the experienced ones keep serving customers, so there's never a gap in service.

A Deployment is a declarative way to tell Kubernetes: 'I want 3 copies of my application running at all times, using this container image, with these resource limits.' The Deployment controller, running inside the kube-controller-manager, continuously watches the actual state and adjusts it to match your desired state. Under the hood, a Deployment doesn't manage Pods directly — it creates a ReplicaSet, which is the controller that actually creates and monitors the Pods. The Deployment manages the ReplicaSet.

The real power of Deployments is their update strategy. When you change the container image (say from v1.2 to v1.3), the Deployment creates a NEW ReplicaSet for v1.3 and gradually scales it up while scaling the OLD ReplicaSet down. With the default RollingUpdate strategy and settings of maxUnavailable=25% and maxSurge=25%, if you have 4 replicas, Kubernetes will first create 1 new Pod (surge), then kill 1 old Pod (unavailable), and continue this dance until all Pods are running v1.3. At every step, at least 3 Pods are serving traffic. The old ReplicaSet is kept around (scaled to 0 replicas) so you can instantly roll back.

Kubernetes records the history of these rollouts. Each change creates a new revision, and by default Kubernetes keeps the last 10. If v1.3 has a bug, you can run kubectl rollout undo and the Deployment immediately scales the old ReplicaSet back up — much faster than deploying a new version because the old ReplicaSet and its Pod template already exist.

A critical gotcha: Deployments rely on readiness probes to decide when a new Pod is 'ready' to receive traffic. If you don't configure a readiness probe, Kubernetes considers a Pod ready the moment its container starts — even if your application needs 30 seconds to load configuration, warm caches, or connect to a database. This means during a rolling update, traffic gets sent to Pods that aren't actually ready, causing errors. Always configure readiness probes in production Deployments.