← Problem Library
K8s L4 K8S 1381 · 12 min

Metrics Server stays ready and the HPA still shows unknown

Metrics exist, yet the aggregator chooses a node address family that the control plane cannot reach after the network change.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

A cluster subnet rework lands and later HPAs lose metrics even though Metrics Server looks healthy.

What to check first
  • Identify the primary failure signal in the The Metrics Server Was Healthy and the Control Plane Chased the Wrong Node Address scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Validate effective node address preference before touching RBAC, TLS, or HPA queries.

Questions worth viewing together
What should you verify first when Metrics Server stays ready and the HPA still shows unknown appears?

Community-field Kubernetes problem inspired by metrics-server discussions where address preference shifted to an unreachable subnet. Autoscaling failures often come from address selection drift between components rather than missing metrics generation.

What usually causes Metrics Server stays ready and the HPA still shows unknown in production?

Teams often blame Metrics Server instability when the control plane is simply dialing an unreachable node address.

What should you document after resolving Metrics Server stays ready and the HPA still shows unknown?

Address-type preference should be reviewed after any node subnet or routing change.