Scaling Deployments in Kubernetes - Commands & Configuration

Introduction

Sometimes your app needs more copies running to handle more users or work. Scaling deployments means increasing or decreasing the number of app copies automatically or by command to keep your app fast and available.

When your website gets more visitors and you want it to stay fast without crashing

When you want to save resources by running fewer app copies during quiet times

When you deploy a new version and want to test it with a few copies before full rollout

When you want to handle sudden spikes in traffic without manual intervention

When you want to keep your app running even if some copies fail

Config File - deployment.yaml

deployment.yaml

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

This file defines a Deployment named example-deployment that runs 2 copies (replicas) of an Nginx container. The replicas field controls how many copies run. The selector and template ensure the Deployment manages the right pods.

Commands

This command creates the Deployment in Kubernetes using the configuration file. It starts 2 copies of the app as defined.

Terminal

kubectl apply -f deployment.yaml

Expected Output

deployment.apps/example-deployment created

This command lists all deployments to check if our example-deployment is running and how many replicas it has.

Terminal

kubectl get deployments

Expected Output

NAME                READY   UP-TO-DATE   AVAILABLE   AGE

example-deployment   2/2     2            2           10s

This command changes the number of running copies to 5, scaling up the deployment to handle more load.

Terminal

kubectl scale deployment example-deployment --replicas=5

Expected Output

deployment.apps/example-deployment scaled

→

--replicas - Sets the desired number of pod copies

This command lists all pods with the label app=example-app to verify that 5 pods are running after scaling.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                   READY   STATUS    RESTARTS   AGE

example-deployment-6f7d8c9b7f-abc12   1/1     Running   0          10s

example-deployment-6f7d8c9b7f-def34   1/1     Running   0          10s

example-deployment-6f7d8c9b7f-ghi56   1/1     Running   0          5s

example-deployment-6f7d8c9b7f-jkl78   1/1     Running   0          5s

example-deployment-6f7d8c9b7f-mno90   1/1     Running   0          5s

→

-l - Filters pods by label

Key Concept

If you remember nothing else from this pattern, remember: scaling changes how many copies of your app run to match demand and keep it available.

Common Mistakes

Trying to scale a deployment that does not exist

Kubernetes will return an error because it cannot find the deployment to scale.

Make sure the deployment is created first with kubectl apply before scaling.

Setting replicas to zero without intending to stop the app

This stops all copies, making the app unavailable.

Use scaling to reduce replicas carefully and confirm the app can handle zero replicas if needed.

Not using the correct label selector when checking pods

You may not see the pods related to your deployment and think scaling failed.

Use the exact label used in the deployment spec with -l flag to list the right pods.

Summary

Create a deployment with a set number of replicas using a YAML file and kubectl apply.

Check the deployment status and number of running replicas with kubectl get deployments.

Scale the deployment up or down using kubectl scale with the --replicas flag.

Verify the number of running pods matches the desired replicas using kubectl get pods with label filtering.

Practice

1. What does scaling a Kubernetes deployment do?

easy

A. Changes the number of running copies (pods) of the app

B. Updates the app's source code automatically

C. Deletes the deployment from the cluster

D. Changes the app's network settings

Solution

1. Step 1: Understand the purpose of scaling

   Scaling means adjusting how many copies of an app run to handle load or save resources.

2. Step 2: Identify what scaling affects

   Scaling changes the number of pods, which are running instances of the app.

3. Final Answer:

   Changes the number of running copies (pods) of the app -> Option A

4. Quick Check:

   Scaling = Change pod count [OK]

Hint: Scaling means changing pod count, not code or network [OK]

Common Mistakes:

• Thinking scaling updates app code
• Confusing scaling with deleting deployments
• Assuming scaling changes network settings

2. Which is the correct command to scale a deployment named webapp to 5 replicas?

easy

A. kubectl scale pods webapp --count=5

B. kubectl update deployment webapp --replicas 5

C. kubectl set replicas webapp 5

D. kubectl scale deployment webapp --replicas=5

Solution

1. Step 1: Recall the correct kubectl scale syntax

   The command to scale is kubectl scale deployment [name] --replicas=[number].

2. Step 2: Match the command to the options

   kubectl scale deployment webapp --replicas=5 matches the correct syntax exactly for deployment webapp to 5 replicas.

3. Final Answer:

   kubectl scale deployment webapp --replicas=5 -> Option D

4. Quick Check:

   Correct scale syntax = kubectl scale deployment webapp --replicas=5 [OK]

Hint: Use 'kubectl scale deployment NAME --replicas=N' exactly [OK]

Common Mistakes:

• Using 'pods' instead of 'deployment'
• Wrong flag like --count instead of --replicas
• Using 'kubectl update' which is invalid for scaling

3. Given this command:
kubectl scale deployment frontend --replicas=3
What will be the number of pods running for the frontend deployment after execution?

medium

A. 0

B. 1

C. 3

D. Depends on cluster resources

Solution

1. Step 1: Understand the scale command effect

   The command sets the number of replicas (pods) to 3 explicitly.

2. Step 2: Determine the pod count after scaling

   After running, Kubernetes will ensure exactly 3 pods for the frontend deployment.

3. Final Answer:

   3 -> Option C

4. Quick Check:

   --replicas=3 means 3 pods [OK]

Hint: Replicas number = pods count after scaling [OK]

Common Mistakes:

• Assuming pods stay at 1 by default
• Thinking scaling depends on cluster resources
• Confusing replicas with CPU or memory

4. You run kubectl scale deployment backend --replicas=two but get an error. What is the problem?

medium

A. The deployment name 'backend' is invalid

B. The replicas value must be a number, not a word

C. The command should use 'kubectl update' instead

D. You need to add --force flag to scale

Solution

1. Step 1: Check the replicas argument type

   The replicas flag requires a numeric value, not a word like 'two'.

2. Step 2: Identify the cause of the error

   Using 'two' causes a syntax error because Kubernetes expects an integer.

3. Final Answer:

   The replicas value must be a number, not a word -> Option B

4. Quick Check:

   Replicas must be numeric [OK]

Hint: Replicas must be a number, not text [OK]

Common Mistakes:

• Using words instead of numbers for replicas
• Thinking deployment name is invalid without checking
• Trying to use 'kubectl update' for scaling

5. You want to scale a deployment named api-server from 2 to 10 replicas but only 6 nodes are available in your cluster. What will happen after running kubectl scale deployment api-server --replicas=10?

hard

A. Only 6 pods will run because of node limits, others stay pending

B. The deployment will scale to 2 pods automatically

C. The command will fail with an error about node count

D. Kubernetes will create 10 pods regardless of node count

Solution

1. Step 1: Understand Kubernetes scheduling with limited nodes

   Kubernetes tries to run all requested pods but can only schedule as many as fit on available nodes.

2. Step 2: Predict pod status with 10 replicas but 6 nodes

   Only 6 pods will be scheduled and running; the other 4 pods remain pending until resources free up.

3. Final Answer:

   Only 6 pods will run because of node limits, others stay pending -> Option A

4. Quick Check:

   Pods limited by nodes = pending pods [OK]

Hint: Pods > nodes means some pods stay pending [OK]

Common Mistakes:

• Assuming all pods run regardless of nodes
• Expecting command to fail on node shortage
• Thinking deployment scales down automatically