← Problem Library
K8s L6 K8S 1307 · 16 min

The metrics adapter serves custom metrics but the HPA still fails because the aggregation layer sees a TLS name that no longer matches after the adapter service was renamed

Metrics endpoints work when tested directly, yet autoscaling stays broken because the APIService layer rejects the adapter certificate identity.

K8sPlatform ReliabilityLevel 6Pro16 min
Scenario

A service rename or chart refactor leaves autoscaling frozen even though direct adapter requests look healthy.

What to check first
  • Identify the primary failure signal in the Adapter Works Directly but Fails Through Aggregation TLS 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 APIService TLS identity separately from the adapter pod health.

Questions worth viewing together
What should you verify first when The metrics adapter serves custom metrics but the HPA still fails appears?

Community-field Kubernetes problem inspired by Discuss Kubernetes patterns where custom metrics adapters broke after service rename TLS drift. An adapter can be healthy and still unusable if the aggregation layer rejects its certificate.

What usually causes The metrics adapter serves custom metrics but the HPA still fails in production?

Teams often blame missing metrics when the real issue is TLS identity at the APIService boundary.

What should you document after resolving The metrics adapter serves custom metrics but the HPA still fails?

Service renames ripple into aggregated API certificate expectations.