Deployments for Scaling

Introduction

In previous labs, you created a single Pod. While Pods are the basic building blocks, manual management of them is tedious. If a Pod dies, you have to restart it manually. If you want more copies, you have to create more Pods manually.

Enter the Deployment.

A deployment is a higher-level controller that manages replica sets and pods for you. You declare how many replicas should exist and what pod template they should use, and Kubernetes works to keep reality aligned with that declaration.

The key shift here is from managing an individual Pod to managing a repeatable workload. A single Pod is fragile because it is just one instance. A Deployment describes a pattern for creating Pods and a target count for how many should exist. That pattern is what makes scaling and self-healing possible.

In this lab, you will learn to:

• Create a strict Manager (Deployment) with a specific goal (3 replicas).
• Watch the Manager hire workers (Pods).
• "Kill" a worker to test the Manager's reaction (Self-Healing).
• Ask the Manager to hire more workers (Scaling).

Create Deployment YAML

In this step, you will write the job description for your Manager. This is a YAML file that defines what image to run and how many copies (replicas) you want.

Notice the extra structure compared with a plain Pod manifest. A Deployment contains a selector and a template. The selector tells Kubernetes which Pods belong to this Deployment, and the template describes how new Pods should be created. Those two parts must stay aligned, or the Deployment will not manage the intended Pods correctly.

First, verify you are in the project directory:

cd ~/project

Create a new file named deployment.yaml using nano:

nano deployment.yaml

Paste the following configuration into the file. Pay attention to the replicas: 3 line—this is where you define the headcount for your team.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:1.14.2
          ports:
            - containerPort: 80

To save: Press Ctrl+X, then Y, then Enter.

This file tells Kubernetes: "Create a Deployment named nginx-deployment. Ensure there are always 3 pods running the nginx:1.14.2 image. If you need to find these pods, look for the ones labeled app: nginx."

Apply and Watch

Now that you have the job description, let's hire the manager. Apply the configuration to the cluster:

When you create a Deployment, Kubernetes usually creates another object called a ReplicaSet behind the scenes. The ReplicaSet is the component directly responsible for keeping the requested number of Pods alive. Beginners do not need to manage ReplicaSets directly yet, but it is useful to know they exist because you will often see them in command output.

kubectl apply -f deployment.yaml

Kubernetes will confirm: deployment.apps/nginx-deployment created.

The Deployment (Manager) will immediately start creating 3 Pods. To see them fast, run:

kubectl get pods

You should see 3 different pods, all with names starting with nginx-deployment-:

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-66b6c48dd5-8j64w   1/1     Running   0          5s
nginx-deployment-66b6c48dd5-d95l2   1/1     Running   0          5s
nginx-deployment-66b6c48dd5-lzr5w   1/1     Running   0          5s

You can also check the status of the Deployment itself:

kubectl get deployments

It should show READY 3/3, confirming that all 3 requested replicas are up and running.

Test Self-Healing

One of the most powerful features of Kubernetes is Self-Healing. The Deployment guarantees that the actual number of pods always matches the desired number (3). If one goes missing, it replaces it immediately.

This works because Kubernetes is constantly reconciling actual state against desired state. Deleting one Pod does not change the desired replica count stored in the Deployment, so the system interprets the deletion as drift and creates a replacement.

Let's test this by manually deleting one of the pods.

First, list the pods again:

kubectl get pods

Copy the full name of one of the pods (e.g., nginx-deployment-66b6c48dd5-8j64w).

Now, delete that specific pod:

kubectl delete pod <paste-pod-name-here>

Kubernetes will say the pod is deleted. Immediately run kubectl get pods again:

kubectl get pods

You will see something amazing:

1. The old pod is terminating (or gone).
2. A new pod with a different name and a very young Age (e.g., 2 seconds) has already appeared!

The Deployment noticed a worker was missing and immediately hired a new one to keep the team size at 3. This ensures your application stays online even if individual servers or containers fail.

Scale Up

Imagine your website is getting popular. 3 web servers are no longer enough; you need 5. Do you need to manually create new files or rush to create pods?

Scaling a Deployment changes the declared desired count, not just the current set of running processes. That is why the new size survives beyond one manual action. Controllers continue to treat the updated replica number as the truth until you change it again.

No. You just tell the Manager to increase the count.

We can update the number of replicas on the fly using the kubectl scale command.

Change the replica count from 3 to 5:

kubectl scale deployment/nginx-deployment --replicas=5

Now, watch the magic happen:

kubectl get pods

You will now see 5 pods running. Two new ones were started to meet the new requirement.

You can also scale down. If traffic drops, you can save resources by reducing the count:

kubectl scale deployment/nginx-deployment --replicas=2

Run kubectl get pods again, and you'll see Kubernetes terminating the extra pods until only 2 remain.

This dynamic scaling is why companies love Kubernetes.

Summary

In this lab, you learned about the Deployment, the intelligent manager that keeps your applications running.

You successfully:

1. Created a Deployment with 3 worker Pods.
2. Verified that the Deployment automatically replaces failed Pods (Self-Healing).
3. Scaled the number of replicas up and down with a single command (Scaling).

Now you understand why we rarely create standalone Pods. Deployments give you reliability and flexibility, managing the complex work of scheduling and restarting so you don't have to.