Deployments and Pod Management

Introduction: The Problem with Managing Pods Manually

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.

What is a Deployment and How Does It Use Selectors?

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.

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

The Structure of a Deployment Manifest

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:

YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: demo

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:

YAML

spec:
  selector:
    matchLabels:
      app: demo
      tier: web

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.

Next comes the replicas field, which specifies how many identical Pods the Deployment should maintain:

YAML

spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
      tier: web

The replicas: 1 tells Kubernetes to keep exactly one Pod running at all times. If that Pod crashes or gets deleted, the Deployment will immediately create a replacement. You can set this to any number — replicas: 3 would maintain three identical Pods, replicas: 10 would maintain ten, and so on. The Deployment constantly monitors the actual number of running Pods and adjusts to match your desired replica count.

Finally, the template field defines what those Pods should look like. This is a complete Pod specification nested inside the Deployment:

YAML

spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo
      tier: web
  template:
    metadata:
      labels:
        app: demo
        tier: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80

The template section contains everything you'd normally put in a Pod manifest — the metadata with labels, and the spec with container definitions. Notice something crucial here: the labels in the template (app=demo and tier=web) must match the selector we defined earlier. This is required because the Deployment needs to be able to find the Pods it creates. If the template labels don't match the selector, the Deployment won't recognize its own Pods, and things will break.

Think of the template as a cookie cutter. Every time the Deployment needs to create a Pod, it uses this template to stamp out an identical copy. All Pods created from this template will have the same labels, the same container configuration, and the same specifications. This is how Deployments ensure consistency — they create Pods from a single template, so you know every Pod will be identical.

Viewing and Inspecting Deployments

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

Shell

kubectl get deployments

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

text

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   1/1     1            1           30s

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:

Shell

kubectl get pods -l app=demo,tier=web

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

text

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7d64f8b9c4-x7k2m   1/1     Running   0          1m

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.

To see detailed information about the Deployment, use kubectl describe:

Shell

kubectl describe deployment nginx-deployment

This shows a wealth of information about the Deployment's configuration and current state (shortened for brevity):

text

Name:                   nginx-deployment
Selector:               app=demo,tier=web
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
Pod Template:
  Labels:  app=demo
           tier=web
  Containers:
   nginx:
    Image:        nginx:1.25
    Port:         80/TCP
NewReplicaSet:   nginx-deployment-7d64f8b9c4 (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  2m    deployment-controller  Scaled up replica set nginx-deployment-7d64f8b9c4 to 1

Pay attention to the Selector line, which shows the label selector the Deployment uses. The Pod Template section shows the template used to create Pods. The NewReplicaSet line reveals something interesting: the Deployment created a ReplicaSet to manage the Pods.

A ReplicaSet is an intermediate controller that sits between the Deployment and the Pods. The Deployment creates and manages ReplicaSets, and the ReplicaSets create and manage Pods. You can see this ReplicaSet directly:

Shell

kubectl get replicasets

You'll see one ReplicaSet with a name that matches the hash in the Pod name:

text

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-7d64f8b9c4   1         1         1       3m

For now, just know that ReplicaSets exist and that Deployments use them behind the scenes. You typically don't interact with ReplicaSets directly — you work with Deployments, and they handle the ReplicaSets for you. This layered architecture is what enables advanced features like rolling updates and rollbacks, which you'll learn about in future lessons.

Introduction: The Problem with Managing Pods Manually

What is a Deployment and How Does It Use Selectors?

Join the 1M+ learners on CodeSignal

The Structure of a Deployment Manifest

Creating Your First Deployment

Viewing and Inspecting Deployments

Summary and Practice Preview