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.