← Problem Library
K8s L6 K8S 1392 · 15 min

A Gatekeeper policy looks unchanged and one namespace starts failing admission

The policy object is present, yet one control-plane path evaluates an earlier schema version and rejects resources the new template should allow.

K8sPlatform ReliabilityLevel 6Pro15 min
Scenario

A control-plane upgrade finishes and later policy behavior differs by admission path for the same resource kind.

What to check first
  • Identify the primary failure signal in the The Policy Was the Same and One API Server Brought Yesterday's Schema to the Meeting 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

Inspect CRD conversion behavior per API server before editing constraints or disabling Gatekeeper.

Questions worth viewing together
What should you verify first when A Gatekeeper policy looks unchanged and one namespace starts failing admission appears?

Community-field Kubernetes problem inspired by admission-control discussions where one API server returned a stale Gatekeeper schema. Admission drift can hide in CRD conversion and schema-serving paths across partially upgraded control planes.

What usually causes A Gatekeeper policy looks unchanged and one namespace starts failing admission in production?

Teams often blame policy logic when one API server is still converting against an older template schema.

What should you document after resolving A Gatekeeper policy looks unchanged and one namespace starts failing admission?

Rolling control-plane upgrades should validate CRD conversion webhooks and schema parity across every API server.