Desired replicas vs actual replicas in Kubernetes - CLI Comparison

Introduction

When you run an app on Kubernetes, you tell it how many copies (replicas) you want. Kubernetes then works to make sure the actual number of running copies matches what you asked for. This helps keep your app available and balanced.

When you want to make sure your app always has a certain number of copies running for reliability.

When you update your app and want to increase or decrease the number of running copies smoothly.

When you want to check if Kubernetes is keeping your app healthy by matching the desired number of copies.

When you notice your app is slow or down and want to see if the number of running copies is less than expected.

When you want to scale your app up or down based on user demand.

Config File - deployment.yaml

deployment.yaml

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

This file tells Kubernetes to run 3 copies (replicas) of an Nginx app. The replicas field is the desired number of copies. Kubernetes will try to keep the actual running copies equal to this number.

The selector and template define which pods belong to this deployment and what each pod runs.

Commands

This command creates or updates the deployment with the desired number of replicas defined in the file.

Terminal

kubectl apply -f deployment.yaml

Expected Output

deployment.apps/example-deployment created

This command shows the deployment status, including desired replicas and actual replicas running.

Terminal

kubectl get deployment example-deployment

Expected Output

NAME                 READY   UP-TO-DATE   AVAILABLE   AGE

example-deployment   3/3     3            3           10s

This command gives detailed information about the deployment, including events if replicas are not matching.

Terminal

kubectl describe deployment example-deployment

Expected Output

Name:                   example-deployment

Namespace:              default

CreationTimestamp:      Thu, 01 Jun 2023 12:00:00 +0000

Labels:                 <none>

Annotations:            <none>

Selector:               app=example-app

Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable

StrategyType:           RollingUpdate

Pods Status:            3 Running / 0 Waiting / 0 Succeeded / 0 Failed

Events:

  Type    Reason             Age   From                   Message

  ----    ------             ----  ----                   -------

  Normal  ScalingReplicaSet  10s   deployment-controller  Scaled up replica set example-deployment-xxxxx to 3

This command lists all pods with the label app=example-app to see the actual running copies.

Terminal

kubectl get pods -l app=example-app

Expected Output

NAME                                   READY   STATUS    RESTARTS   AGE

example-deployment-xxxxx-abcde         1/1     Running   0          15s

example-deployment-xxxxx-fghij         1/1     Running   0          15s

example-deployment-xxxxx-klmno         1/1     Running   0          15s

Key Concept

If you remember nothing else from this pattern, remember: Kubernetes always tries to keep the actual number of running replicas equal to the desired number you set.

Common Mistakes

Not checking the deployment status after applying changes.

You might think your app is running the desired number of copies, but Kubernetes may still be creating or restarting pods.

Always run 'kubectl get deployment' or 'kubectl describe deployment' to verify the actual replicas match the desired replicas.

Setting replicas to zero unintentionally.

This stops all pods, making your app unavailable.

Double-check the replicas field in your deployment file before applying changes.

Ignoring pod labels when checking pods.

You may see pods unrelated to your deployment, causing confusion about actual replicas.

Use label selectors like '-l app=example-app' to list only the pods belonging to your deployment.

Summary

Create or update a deployment with a desired number of replicas using 'kubectl apply -f deployment.yaml'.

Check the deployment status with 'kubectl get deployment' to see desired vs actual replicas.

Use 'kubectl describe deployment' for detailed info and events about replica changes.

List pods with matching labels to see actual running copies.

Practice

1. What does the desired replicas value represent in a Kubernetes Deployment?

easy

A. The number of pods currently running

B. The number of containers inside a pod

C. The number of nodes in the cluster

D. The number of pod copies Kubernetes should run

Solution

1. Step 1: Understand the role of desired replicas

   Desired replicas specify how many copies of a pod Kubernetes should maintain to run your app.

2. Step 2: Differentiate from actual replicas

   Actual replicas show how many pods are currently running, which may differ temporarily.

3. Final Answer:

   The number of pod copies Kubernetes should run -> Option D

4. Quick Check:

   Desired replicas = target pod count [OK]

Hint: Desired replicas = target pods Kubernetes tries to run [OK]

Common Mistakes:

• Confusing desired replicas with actual running pods
• Thinking desired replicas count containers, not pods
• Mixing desired replicas with cluster node count

2. Which of the following is the correct YAML snippet to set desired replicas to 3 in a Deployment?

easy

A. replicaCount: 3

B. desiredReplicas: 3

C. replicas: 3

D. pods: 3

Solution

1. Step 1: Identify the correct field name in Deployment spec

   The correct field to set desired replicas is replicas under the spec section.

2. Step 2: Verify syntax correctness

   Using replicas: 3 is valid YAML and recognized by Kubernetes.

3. Final Answer:

   replicas: 3 -> Option C

4. Quick Check:

   Use 'replicas' to set desired pod count [OK]

Hint: Use 'replicas' key in Deployment spec to set desired pods [OK]

Common Mistakes:

• Using incorrect field names like desiredReplicas or replicaCount
• Placing replicas outside the spec section
• Using plural 'pods' instead of 'replicas'

3. You run kubectl get deployment myapp and see:
DESIRED=4, CURRENT=3, UP-TO-DATE=3, AVAILABLE=3
What does this mean?

medium

A. One pod has crashed and won't restart

B. Kubernetes is still creating the 4th pod

C. All pods are running as expected

D. Deployment is scaled down to 3 pods

Solution

1. Step 1: Compare desired and current replicas

   Desired is 4 but current is 3, so Kubernetes aims for 4 pods but only 3 are running now.

2. Step 2: Interpret the status fields

   Up-to-date and available are 3, meaning 3 pods are ready and updated; the 4th pod is likely starting.

3. Final Answer:

   Kubernetes is still creating the 4th pod -> Option B

4. Quick Check:

   Desired > Current means pods are still launching [OK]

Hint: Desired > Current means pods are starting or recovering [OK]

Common Mistakes:

• Assuming pods crashed without checking events
• Thinking deployment scaled down when desired is higher
• Confusing available with desired replicas

4. You notice your Deployment's desired replicas is 5 but actual replicas stays at 3. Which is the most likely cause?

medium

A. Pods are stuck in Pending state due to resource limits

B. Deployment YAML has syntax errors

C. kubectl command was typed incorrectly

D. Actual replicas always match desired replicas instantly

Solution

1. Step 1: Understand why actual replicas lag behind desired

   If actual replicas are less than desired, pods may be stuck starting, often due to resource constraints.

2. Step 2: Eliminate other options

   Syntax errors prevent deployment creation, incorrect kubectl commands won't show this state, and actual replicas do not update instantly.

3. Final Answer:

   Pods are stuck in Pending state due to resource limits -> Option A

4. Quick Check:

   Pending pods cause actual < desired replicas [OK]

Hint: Check pod status if actual replicas < desired replicas [OK]

Common Mistakes:

• Assuming syntax errors cause replica mismatch
• Expecting instant replica count update
• Ignoring pod scheduling issues

5. You want to ensure your Deployment always has 3 pods running. You set replicas: 3 but sometimes kubectl get pods shows only 2 running pods. What should you do to fix this?

hard

A. Check pod events and logs to find why one pod is not running and fix the issue

B. Increase replicas to 4 to force Kubernetes to create more pods

C. Delete the Deployment and recreate it with replicas set to 3

D. Ignore it; actual replicas will eventually match desired without intervention

Solution

1. Step 1: Investigate why pods are missing

   Check pod events and logs to identify issues like crashes, scheduling failures, or resource limits causing pods not to run.

2. Step 2: Fix the root cause

   Resolve the identified problem (e.g., fix image, increase resources) so Kubernetes can maintain 3 running pods as desired.

3. Final Answer:

   Check pod events and logs to find why one pod is not running and fix the issue -> Option A

4. Quick Check:

   Fix pod issues to match actual to desired replicas [OK]

Hint: Always check pod status and logs if replicas don't match [OK]

Common Mistakes:

• Scaling replicas blindly without fixing pod issues
• Deleting Deployment unnecessarily
• Assuming Kubernetes fixes pod issues automatically