Kubernetes Deployment: Declarative App Updates

Why it exists

Manually managing application lifecycles across many servers is complex and error-prone. You need a reliable, automated way to roll out updates, scale up or down, and recover from failures without downtime. Deployments solve this by abstracting away the low-level details of managing individual application instances (Pods).

The mental model

Think of a Deployment as the manager of a team of identical workers (Pods). You give the manager a goal: 'I need 5 workers running version 1.2 of our software.' The manager ensures that's always the case. If a worker gets sick and crashes, the manager replaces them automatically. If you change the goal to 'I need 10 workers running version 1.3,' the manager handles hiring the new workers and retiring the old ones gracefully, ensuring the work continues uninterrupted.

How it works

A Deployment is a Kubernetes object that declaratively defines a desired state for your application. This includes the container image, the number of replicas, and the update strategy. When you create a Deployment, it creates a child object called a ReplicaSet. The ReplicaSet's job is to ensure the specified number of Pods are always running. When you update the Deployment (e.g., by changing the container image tag), it creates a new ReplicaSet and performs a rolling update. It gradually terminates Pods from the old ReplicaSet while creating Pods in the new one, allowing for zero-downtime rollouts.

When to use it

Use Deployments for stateless applications where any Pod is interchangeable and can handle any request. This is the most common workload type in Kubernetes. Good examples include REST APIs, web frontends, and background processing workers that pull from a queue.

When not to use it

Do not use Deployments for stateful applications that require stable, unique network identifiers and persistent storage tied to each instance. For those, use a StatefulSet (e.g., for databases like Zookeeper or etcd). For tasks that run to completion, use a Job or CronJob. To run a Pod on every node in the cluster, use a DaemonSet.

One canonical example

A team wants to run their stateless web application with three instances for high availability. They create a Deployment manifest specifying replicas: 3 and the container image webapp:v1. Kubernetes ensures three Pods are running. To release a new version, they update the Deployment's image to webapp:v2. The Deployment controller then, one by one, terminates an old Pod and creates a new one until all three are running v2, with no service interruption.