A webhook appears healthy from workload probes and later still fails every admission request after a network policy hardening change.
A webhook certificate is valid and admission still times out
Pods can curl the endpoint, yet admission requests fail because the control plane was never whitelisted through the same path.
Scenario
What to check first
- Identify the primary failure signal in the Pods Reached the Webhook and the API Server Came From Somewhere Else scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
Checking checklist
- Summarize the current impact and the last known change.
- Collect direct evidence from logs, runtime state, and configuration before changing anything.
- Separate immediate recovery from permanent prevention work.
Recovery and prevention
Test control-plane reachability directly before changing TLS or redeploying the webhook.
Questions worth viewing together
Community-field Kubernetes problem inspired by webhook discussions where pod tests passed but the apiserver path was blocked. Pod reachability is not proof of apiserver reachability for admission webhooks.
Teams often blame certificate issues when the apiserver source path is what the policy blocks.
Webhook policy should explicitly account for control-plane source CIDRs and paths.
Similar cases seen in the field