Scenario
A control-plane migration completes and later certificate renewals begin failing even though the webhook deployment appears healthy from workload tests.
A cert-manager renewal job stays Pending (webhook-networkpolicy-still-whitelisted-old-apiserver-cidr)
Pods can curl the webhook, yet the control plane cannot because the apiserver now originates from a different CIDR range than the old cluster.
What to check first
- Identify the primary failure signal in the The Webhook Was Open to Workloads and Closed to the New Control Plane 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 the control-plane source path rather than only pod reachability before editing cert-manager resources.
Questions worth viewing together
Community-field Kubernetes problem inspired by webhook and NetworkPolicy community cases where the apiserver CIDR changed after control-plane migration. Admission and webhook traffic often comes from a control-plane CIDR your workload probes never exercise.
Teams often blame webhook certificates when the apiserver source itself is no longer allowed by NetworkPolicy.
Control-plane migrations should trigger a review of any webhook or admission policy that whitelists source CIDRs.
Similar cases seen in the field