A forbidden manifest is rejected from one kubectl client and accepted from another behind a load-balanced API endpoint.
A Gatekeeper policy rollout works on most requests and one API server still...
The policy is updated, yet one API server still validates against the earlier schema because its webhook conversion cache did not refresh with the rest of the control plane.
- Identify the primary failure signal in the The Cluster Learned the New Template and One API Server Kept an Old Copy Folded in Its Pocket scenario.
- Separate visible symptoms from the underlying technical dependency.
- Describe the safest recovery path and the follow-up prevention work.
- 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.
Inspect webhook and control-plane cache refresh behavior before disabling the constraint or widening the policy.
Community-field Kubernetes problem inspired by Gatekeeper and control-plane discussions where one API server retained a stale conversion schema. Control-plane partial restarts can leave admission and conversion behavior inconsistent across API servers longer than expected.
Teams often blame race conditions in kubectl when one API server is simply evaluating the older schema.
Admission controller rollouts should verify behavior against every API server path, not only one aggregated endpoint.