← Problem Library
K8s L6 K8S 1321 · 16 min

An admission webhook serves the right certificate and still times out

Pod level checks pass, yet admission calls fail because the apiserver network path does not use the same resolution or routing assumptions as ordinary workloads.

K8sPlatform ReliabilityLevel 6Pro16 min
Scenario

A webhook looks healthy from test pods and later still fails every admission request after a network policy or DNS fix.

What to check first
  • Identify the primary failure signal in the Pods Could Reach the Webhook, the API Server Took Another Path 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 the apiserver to webhook path directly before modifying the webhook deployment again.

Questions worth viewing together
What should you verify first when An admission webhook serves the right certificate and still times out appears?

Community-field Kubernetes problem inspired by Discuss Kubernetes patterns where admission webhooks were reachable from pods but not from the API server... Webhook reachability must be proven from the API server perspective, not only from regular pods.

What usually causes An admission webhook serves the right certificate and still times out in production?

Teams often blame certificate rotation when the real issue is the control-plane network path.

What should you document after resolving An admission webhook serves the right certificate and still times out?

Control-plane initiated traffic may bypass the service path assumptions workload engineers normally test.