Admission failures appear random after a service rename because only certain nodes run through a different DNS path.
A validating webhook only times out on node-local DNS nodes because the stub domain config there never learned the internal zone the webhook target now uses
Most nodes admit pods normally, yet one subset fails because their local DNS chain cannot resolve the webhook backend's newer internal name.
Scenario
What to check first
- Identify the primary failure signal in the Webhook Path Depends on a DNS Layer Only Some Nodes Use 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
Compare node-local DNS config and upstream zone knowledge before rotating webhook certs.
Questions worth viewing together
Community-field Kubernetes problem inspired by Discuss Kubernetes patterns where node-local DNS caused selective webhook timeouts. Webhook outages can be name-resolution path splits, not always network path splits.
Teams often rebuild webhook deployments when the failure exists entirely in node-local DNS configuration.
Per-node DNS optimizations create extra resolution contracts that cluster-wide testing can miss.
Similar cases seen in the field