Kubernetes Deployment

A Deployment is a record of intent. You write a YAML file that says "run 4 copies of my-api version 2.3, listening on port 8080," and you hand it to the cluster. From then on, Kubernetes treats that file as the source of truth and keeps the cluster matching it.

You almost never create pods directly in production. A bare pod has no self-healing: if the node it runs on dies, the pod is gone for good. A Deployment fixes that by sitting one level above your pods and owning their lifecycle.

Under the covers, a Deployment does not manage pods directly either. It creates and manages a ReplicaSet, and the ReplicaSet creates the pods. The Deployment's job is to manage ReplicaSets over time, which is exactly what makes versioned rollouts possible.

The Deployment controller runs inside the Kubernetes control plane in a constant reconciliation loop. It compares the desired state (your spec) against the observed state (what is actually running) and takes action to close the gap. If you asked for 4 replicas and only 3 are healthy, it tells the ReplicaSet to start one more.

When you change the pod template, for example by bumping the image tag, the Deployment creates a brand new ReplicaSet for the new version and scales it up while scaling the old one down. With the default RollingUpdate strategy you can tune this with maxSurge (how many extra pods can exist during the rollout) and maxUnavailable (how many can be missing). Typical defaults are 25 percent each, so a 4 replica Deployment will spin up 1 extra pod and take down 1 at a time.

Because the old ReplicaSet is kept around (Kubernetes retains 10 by default via revisionHistoryLimit), a rollback is just pointing back at a previous ReplicaSet. Running kubectl rollout undo reverses a bad release in seconds without rebuilding anything.

Readiness probes are what make the rollout safe. The controller will not route traffic to a new pod, and will not proceed to the next batch, until that pod reports ready. A pod that never passes its readiness check stalls the rollout instead of taking the service down.

Use a Deployment for stateless workloads: web servers, REST and gRPC APIs, background workers, anything where one replica is interchangeable with another. This covers the large majority of services people run on Kubernetes.

Do not use a Deployment when pod identity or stable storage matters. Databases, Kafka brokers, and anything needing stable network names or per-pod persistent volumes belong in a StatefulSet. Node-level agents like log shippers or monitoring sidecars belong in a DaemonSet, and run-to-completion jobs belong in a Job or CronJob.

The main trade-off of the RollingUpdate strategy is that two versions of your code run at the same time during a rollout, so your app and database schema must tolerate that overlap. If you cannot, you can set the strategy to Recreate, which kills all old pods before starting new ones, accepting a short downtime in exchange for never mixing versions.

Deployments also do not give you advanced release patterns out of the box. Canary and blue-green rollouts are possible by juggling multiple Deployments and Services, but most teams reach for tools like Argo Rollouts or Flagger once they need fine-grained traffic shifting.

Say you run an API at version 1.0 with 6 replicas and you want to ship version 1.1. You edit the image tag in the Deployment spec and apply it. Kubernetes creates a new ReplicaSet for 1.1 and, with default settings, starts roughly 1 to 2 new pods while removing the same number of old ones, waiting for each new pod to pass its readiness probe before continuing.

Within a minute or two all 6 pods are running 1.1 and the old ReplicaSet is scaled to 0 but kept on file. If alerts fire because 1.1 is throwing 500s, you run kubectl rollout undo deployment/api and Kubernetes scales the old 1.0 ReplicaSet back up while draining 1.1. Traffic never has to stop, and you never had to manually recreate a single pod.