Horizontal Pod Autoscaler in Microservices - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

How does Horizontal Pod Autoscaler decide to scale pods?

Imagine you have a service running in Kubernetes. The Horizontal Pod Autoscaler (HPA) adjusts the number of pods based on certain metrics. Which metric does HPA primarily use to decide when to add or remove pods?

A Number of active network connections to the pods

B CPU utilization of the pods compared to a target threshold

C Total disk space used by the pods

D Number of pods currently running

💡 Hint

Think about what resource usage usually indicates workload intensity.

The HPA primarily monitors CPU utilization (or other specified metrics) to decide if more pods are needed to handle the load or if some pods can be removed to save resources.

❓ Architecture

intermediate

Which component in Kubernetes is responsible for implementing Horizontal Pod Autoscaler?

In Kubernetes architecture, which component actively monitors metrics and adjusts the number of pods for Horizontal Pod Autoscaler?

A kube-controller-manager

B kube-scheduler

C kube-proxy

D etcd

💡 Hint

Think about which component manages controllers and their loops.

The kube-controller-manager runs controllers including the Horizontal Pod Autoscaler controller, which monitors metrics and updates pod counts accordingly.

❓ scaling

advanced

What happens if the metrics server is unavailable for Horizontal Pod Autoscaler?

Consider a Kubernetes cluster where the metrics server stops responding. What is the expected behavior of the Horizontal Pod Autoscaler during this period?

A HPA scales pods randomly without metrics

B HPA immediately scales down all pods to zero

C HPA stops scaling and keeps the current number of pods until metrics are available again

D HPA scales pods up to the maximum limit regardless of load

💡 Hint

Think about how autoscaling depends on metrics and what happens if metrics are missing.

Without metrics, HPA cannot make informed scaling decisions, so it maintains the current pod count until metrics become available again.

❓ tradeoff

advanced

What is a tradeoff when setting a very low CPU utilization target in HPA?

If you configure the Horizontal Pod Autoscaler with a very low CPU utilization target (e.g., 10%), what is a likely tradeoff?

A Pods will scale up quickly, increasing resource costs but improving responsiveness

B Pods will scale down to zero frequently, causing downtime

C Pods will never scale up, causing slow response times

D Pods will ignore CPU usage and scale based on memory instead

💡 Hint

Consider what happens if the threshold to add pods is very low.

A low CPU target causes HPA to add pods more aggressively, which improves responsiveness but increases resource usage and cost.

❓ estimation

expert

Estimate the number of pods needed with HPA given load and CPU usage

Your service currently runs 5 pods, each with 50% CPU utilization. The target CPU utilization for HPA is 40%. If the incoming load doubles, approximately how many pods will HPA scale to maintain the target?

A 5 pods

B 20 pods

C 7 pods

D 10 pods

💡 Hint

Think about how doubling load affects CPU usage and how many pods are needed to keep utilization at 40%.

Doubling load doubles CPU usage per pod from 50% to 100%. To reduce utilization to 40%, pods must increase proportionally: (100% / 40%) * 5 pods = 12.5 pods, rounded to 10 or more. 10 pods is the closest reasonable estimate.

Practice

1. What is the primary purpose of a Horizontal Pod Autoscaler in a Kubernetes microservices environment?

easy

A. Store persistent data for pods

B. Manually restart pods when they fail

C. Balance network traffic between pods

D. Automatically adjust the number of pods based on CPU or custom metrics

Solution

1. Step 1: Understand the role of Horizontal Pod Autoscaler

   It is designed to monitor resource usage like CPU or custom metrics and adjust pod count automatically.

2. Step 2: Compare options with this role

   Only Automatically adjust the number of pods based on CPU or custom metrics describes automatic scaling based on load, which matches the autoscaler's purpose.

3. Final Answer:

   Automatically adjust the number of pods based on CPU or custom metrics -> Option D

4. Quick Check:

   Autoscaler adjusts pods automatically = A [OK]

Hint: Autoscaler changes pod count automatically based on load [OK]

Common Mistakes:

• Confusing autoscaler with manual pod management
• Thinking it balances network traffic
• Assuming it stores data persistently

2. Which of the following is the correct YAML snippet to define a Horizontal Pod Autoscaler targeting CPU utilization at 50% for a deployment named web-app?

easy

A. apiVersion: autoscaling/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: web-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: web-app\n minReplicas: 1\n maxReplicas: 5\n metrics:\n - type: Resource\n resource:\n name: cpu\n target:\n type: Utilization\n averageUtilization: 70

B. apiVersion: v1\nkind: Pod\nmetadata:\n name: web-app\nspec:\n containers:\n - name: web-app\n image: web-app:latest

C. apiVersion: autoscaling/v1\nkind: HorizontalPodAutoscaler\nmetadata:\n name: web-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: web-app\n minReplicas: 2\n maxReplicas: 10\n targetCPUUtilizationPercentage: 50

D. apiVersion: autoscaling/v2beta2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: web-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: web-app\n minReplicas: 1\n maxReplicas: 5\n metrics:\n - type: Resource\n resource:\n name: memory\n target:\n type: Utilization\n averageUtilization: 50

Solution

1. Step 1: Identify correct API version and fields for CPU target

   autoscaling/v1 supports targetCPUUtilizationPercentage directly; v2 requires metrics array.

2. Step 2: Check min/max replicas and target CPU utilization

   apiVersion: autoscaling/v1\nkind: HorizontalPodAutoscaler\nmetadata:\n name: web-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps/v1\n kind: Deployment\n name: web-app\n minReplicas: 2\n maxReplicas: 10\n targetCPUUtilizationPercentage: 50 uses autoscaling/v1 with minReplicas 2, maxReplicas 10, and targetCPUUtilizationPercentage 50, which is valid syntax.

3. Final Answer:

   YAML with autoscaling/v1 and targetCPUUtilizationPercentage 50% -> Option C

4. Quick Check:

   autoscaling/v1 + targetCPUUtilizationPercentage = B [OK]

Hint: autoscaling/v1 uses targetCPUUtilizationPercentage field [OK]

Common Mistakes:

• Using wrong apiVersion for the fields
• Confusing CPU with memory metrics
• Setting minReplicas higher than maxReplicas

3. Given this Horizontal Pod Autoscaler configuration:

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

If the current CPU usage is 90% and there are 3 pods running, how many pods will the autoscaler try to set?

medium

A. 5 pods

B. 3 pods

C. 6 pods

D. 4 pods

Solution

1. Step 1: Understand scaling formula based on CPU utilization

   Desired replicas = current replicas * (current CPU / target CPU) = 3 * (90/60) = 4.5

2. Step 2: Round up and check min/max limits

   4.5 rounds up to 5, which is between minReplicas 2 and maxReplicas 6, so 5 pods will be set.

3. Final Answer:

   5 pods -> Option A

4. Quick Check:

   3 * (90/60) = 4.5 -> 5 pods [OK]

Hint: Multiply current pods by (current CPU ÷ target CPU) [OK]

Common Mistakes:

• Rounding down instead of up
• Ignoring min/max replica limits
• Using target CPU as current CPU

4. You configured a Horizontal Pod Autoscaler but notice it never scales pods beyond the minimum replicas even under high load. What is the most likely cause?

medium

A. The maxReplicas is set lower than minReplicas

B. The metrics server is not running or not providing metrics

C. The deployment has too many replicas already

D. The pods are using too little CPU

Solution

1. Step 1: Check autoscaler dependency on metrics

   Horizontal Pod Autoscaler requires metrics server to get CPU or custom metrics to decide scaling.

2. Step 2: Understand effect of missing metrics

   If metrics server is missing or not providing data, autoscaler cannot detect load and keeps pods at minReplicas.

3. Final Answer:

   The metrics server is not running or not providing metrics -> Option B

4. Quick Check:

   Missing metrics = no scaling beyond minReplicas [OK]

Hint: Autoscaler needs metrics server to scale pods [OK]

Common Mistakes:

• Assuming maxReplicas lower than minReplicas causes this
• Thinking high load always triggers scaling
• Ignoring metrics server setup

5. You want to design a microservices system that scales pods horizontally based on both CPU usage and custom queue length metrics. Which approach best uses Horizontal Pod Autoscaler to achieve this?

hard

A. Configure HPA with multiple metrics: CPU utilization and custom queue length, setting thresholds for both

B. Use two separate HPAs, one for CPU and one for queue length, targeting the same deployment

C. Scale pods manually based on CPU and queue length metrics collected externally

D. Configure HPA to scale only on CPU and ignore queue length metrics

Solution

1. Step 1: Understand HPA multi-metric support

   Horizontal Pod Autoscaler supports multiple metrics in a single configuration to scale pods based on combined criteria.

2. Step 2: Evaluate options for best practice

   Configure HPA with multiple metrics: CPU utilization and custom queue length, setting thresholds for both uses multiple metrics in one HPA, which is efficient and avoids conflicts from multiple HPAs targeting the same deployment.

3. Final Answer:

   Configure HPA with multiple metrics: CPU utilization and custom queue length, setting thresholds for both -> Option A

4. Quick Check:

   Single HPA with multiple metrics = A [OK]

Hint: Use one HPA with multiple metrics for combined scaling [OK]

Common Mistakes:

• Using multiple HPAs on same deployment causing conflicts
• Ignoring custom metrics support
• Relying only on CPU metrics