Scaling Deployments in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Scaling a Deployment Using kubectl

You have a Kubernetes deployment named webapp currently running 3 replicas. You run the command kubectl scale deployment webapp --replicas=5. What will be the state of the deployment after this command completes?

A The deployment will have 5 pods running, scaling up from 3.

B The deployment will remain at 3 pods because scaling requires editing the YAML file.

C The deployment will have 8 pods running, adding 5 to the existing 3.

D The deployment will be deleted and recreated with 5 pods.

💡 Hint

Think about what the --replicas flag does in the scale command.

The kubectl scale command sets the desired number of replicas to the specified count. It does not add to the existing number but sets it exactly. So the deployment will have 5 pods running.

🧠 Conceptual

intermediate

Understanding Horizontal Pod Autoscaler (HPA)

Which statement correctly describes how the Horizontal Pod Autoscaler (HPA) works in Kubernetes?

A HPA automatically adjusts the number of pod replicas based on observed CPU utilization or other select metrics.

B HPA manually scales pods only when a user runs a scaling command.

C HPA replaces the deployment controller to manage pods.

D HPA scales the number of nodes in the cluster based on pod demand.

💡 Hint

Think about what metrics HPA uses to decide scaling.

HPA watches metrics like CPU usage and automatically increases or decreases pod replicas to meet the target utilization.

❓ Configuration

advanced

Configuring a Deployment for Auto Scaling

You want to create a Horizontal Pod Autoscaler for a deployment named api-server that scales between 2 and 10 replicas based on CPU usage targeting 60%. Which YAML snippet correctly defines this HPA?

A

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  replicas: 5
  targetCPUUtilizationPercentage: 60

B

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 10
  maxReplicas: 2
  targetCPUUtilizationPercentage: 60

C

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 60

D

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

💡 Hint

Check minReplicas and maxReplicas values and metric type.

Option D correctly uses autoscaling/v2 API with minReplicas 2, maxReplicas 10, and CPU utilization metric targeting 60%. Option D has min and max reversed. Option D uses memory metric instead of CPU. Option D uses 'replicas' which is invalid in HPA spec.

❓ Troubleshoot

advanced

Troubleshooting Failed Scaling of Deployment

You applied an HPA to scale your deployment frontend based on CPU usage, but the number of pods never changes even when CPU usage is high. Which of the following is the most likely cause?

A The deployment has a fixed replica count set in its YAML file.

B The metrics-server is not installed or not running in the cluster.

C The pods are using too much memory instead of CPU.

D The HPA resource is missing the minReplicas field.

💡 Hint

HPA depends on metrics to decide scaling.

HPA requires metrics-server to provide CPU usage data. Without it, HPA cannot detect load and will not scale pods.

🔀 Workflow

expert

Scaling Deployment with Zero Downtime

You need to scale your payment-service deployment from 3 to 6 replicas without causing downtime. Which sequence of commands ensures zero downtime during scaling?

A

kubectl set image deployment payment-service payment-service=payment-service:v2
kubectl scale deployment payment-service --replicas=6

B

kubectl delete pods -l app=payment-service
kubectl scale deployment payment-service --replicas=6

C

kubectl scale deployment payment-service --replicas=6
kubectl rollout status deployment payment-service

D

kubectl scale deployment payment-service --replicas=6
kubectl rollout undo deployment payment-service

💡 Hint

Think about how Kubernetes manages pods during scaling and rollout.

Scaling with kubectl scale increases replicas without deleting pods, and kubectl rollout status waits for pods to be ready, ensuring zero downtime. Deleting pods manually or undoing rollout can cause downtime or revert changes.

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