In the previous lesson, you learned how to organize Pods using labels and query them with selectors. But there's a problem we haven't addressed yet: what happens when you need to run multiple identical Pods, or when one of your Pods crashes? Right now, you'd have to manually create each Pod, monitor them constantly, and recreate any that fail. If you need to update your application to a new version, you'd have to delete and recreate every Pod by hand. This manual approach doesn't scale beyond a handful of Pods.

Deployments solve this problem by automating Pod management. A Deployment uses the label selectors you learned in Lesson 1 to find and control its Pods, automatically creating, monitoring, and replacing them as needed. In this lesson, you'll create your first Deployment and see how it takes over the tedious work of managing Pods on your behalf.

A Deployment is a Kubernetes controller that manages a group of identical Pods for you. Think of it as an automated manager that watches over your Pods, making sure the right number are always running and healthy. If a Pod crashes, the Deployment immediately creates a replacement. If you need more Pods to handle increased traffic, the Deployment creates them. If you need to update your application, the Deployment orchestrates a smooth rollout to the new version. All of this happens automatically once you define what you want.

The key to how Deployments work is the label selector system you learned in Lesson 1. When you create a Deployment, you specify a selector that defines which Pods belong to this Deployment. The Deployment continuously queries Kubernetes using that selector, asking, "Which Pods match my criteria?" Any Pods that match the selector are considered part of this Deployment and will be managed by it. This is the same selector mechanism you used with kubectl get pods -l in the previous lesson, but now Kubernetes itself is using it to automate Pod management.

Here's the important connection: remember how you manually created Pods with labels like app=demo and tier=backend? A Deployment does the same thing, but automatically. You tell the Deployment what labels to put on its Pods, and you tell it which labels to look for with its selector. The Deployment then creates Pods with those labels and uses the selector to find and manage them. This is why understanding labels and selectors was so important — they're the foundation that makes Deployments possible.

A Deployment manifest has three critical parts that work together: the selector, the replicas count, and the Pod template. Let's look at each part individually to understand how they fit together. We'll build up a complete Deployment manifest piece by piece.

First, let's look at the basic structure and metadata of a Deployment:

This looks similar to a Pod manifest, but notice the kind is Deployment and the apiVersion is apps/v1 instead of just v1. The metadata section includes a name for the Deployment and optional labels. These labels describe the Deployment itself, not the Pods it will create. Now let's add the spec section where the real configuration lives.

The selector field tells the Deployment which Pods it should manage. This is where the label selector system from Lesson 1 comes into play:

The matchLabels section defines the selector query. This Deployment will look for Pods that have both app=demo and tier=web labels. Any Pod with these labels will be considered part of this Deployment. This is exactly like using kubectl get pods -l app=demo,tier=web, but the Deployment uses this selector automatically to find its Pods.

Now let's put all the pieces together and create a complete Deployment. Save the following content to a file called deployment.yaml:

This Deployment will create and maintain one nginx Pod with the labels app=demo and tier=web. The selector ensures the Deployment can find and manage this Pod. The template defines exactly what the Pod should look like, including which container image to use and which port to expose.

Create the Deployment using kubectl apply:

You should see output confirming the Deployment was created:

That's it! With this single command, you've created a Deployment that will now manage Pods on your behalf. The Deployment immediately goes to work, checking if any Pods match its selector. Since none exist yet, it creates one Pod from the template. If you delete that Pod, the Deployment will create a replacement. If you change the replica count to 3, the Deployment will create two more Pods. All of this happens automatically.

Now that your Deployment is running, let's explore how to view and inspect it. Start by listing all Deployments in your cluster:

You'll see your Deployment with information about its current state:

The READY column shows 1/1, meaning one out of one desired Pod is ready. The UP-TO-DATE column shows how many Pods are running the latest template version. The AVAILABLE column shows how many Pods are ready to serve traffic. All of these should be 1 since we specified replicas: 1.

Now let's find the Pod that the Deployment created. Remember, the Deployment uses a selector to find its Pods, and you can use the same selector:

You'll see one Pod with an automatically generated name:

Notice the Pod name follows a pattern: nginx-deployment-7d64f8b9c4-x7k2m. The first part (nginx-deployment) comes from the Deployment name. The middle part (7d64f8b9c4) is a hash that identifies the Pod template version. The last part (x7k2m) is a random suffix that makes the name unique. Kubernetes generates these names automatically, so you never have to worry about naming conflicts when the Deployment creates multiple Pods.

Deployments automate Pod management by using the label selector system you learned in Lesson 1. A Deployment manifest has three key parts: a selector that defines which Pods to manage, a replica count that specifies how many Pods to maintain, and a template that defines what those Pods should look like. When you create a Deployment, Kubernetes automatically creates Pods from the template, names them systematically, and continuously monitors them to ensure the desired number are always running.

In the upcoming practice exercises, you'll create your own Deployments, explore how they manage Pods using selectors, and see how Kubernetes automatically maintains your desired state. In future lessons, you'll learn how to scale Deployments up and down, update them to new versions, and roll back when things go wrong.