Prompt and context
Kubernetes v1.36 promoted Declarative Validation to GA and enabled the DeclarativeValidation feature gate by default. Rules are written as +k8s: markers next to type definitions, then generated by validation-gen. The question tests whether you can connect API contracts, generators, compatibility, and release operations.
What the interviewer evaluates
- Whether you can explain maintenance and consistency risks in handwritten validation.
- Whether you distinguish declarative rules, generated code, OpenAPI exposure, and runtime rejection.
- Whether you correctly explain how ambient ratcheting affects updates to old objects.
- Whether you design tests, rollback, and gradual migration so tightened rules do not break stored objects.
Questions to clarify first
Confirm whether the API is a Kubernetes native type or a CRD, whether clients depend on OpenAPI, and whether the constraint is new, relaxed, or tightened. Also confirm whether old objects contain values that were historically accepted and which generator, linter, and server versions must interoperate.
A 30-second answer
Declarative validation places constraints beside type definitions, lets one generator produce consistent code, and makes rules available for OpenAPI. The plan must cover rule design, generation and static checks, server runtime validation, old-object compatibility, and rollback. When tightening a rule, ambient ratcheting protects an unchanged legacy field, but new values still need compatibility review and staged validation.
Step-by-step deep dive
1. Define the rule source
Use markers such as +k8s:required, +k8s:minimum=0, or enum constraints so rules are discoverable beside fields. For cross-field invariants, document the invariant, error message, and supported versions instead of hiding business logic outside the generator.
2. Generate and verify
validation-gen parses markers, generates Go validation functions, and registers them with the API scheme. CI runs the generator, unit tests, kube-api-linter, and OpenAPI diff checks so markers, generated code, and the public schema cannot drift. Generated files must be reproducible and never hand-edited.
3. Handle version evolution
Evaluate stored objects and client behavior before adding a constraint. Ambient ratcheting compares old and new objects: if a field is semantically unchanged, the new rule does not block the update because of its old value; if the field changes, the new rule applies. Tightening still needs migration tooling, audit metrics, and clear errors.
4. Release and rollback
Measure rejection rates in compatibility suites and shadow validation before staged rollout. Monitor API error codes, resource versions, and client retries. If error rates spike, roll back the generator or rule version while keeping accepted objects readable. A GA feature gate enabled by default does not remove migration testing.
Example of a strong answer
I treat validation as a versioned API contract. Markers such as +k8s: express field constraints, validation-gen produces reproducible Go code, and CI uses unit tests, a linter, and OpenAPI diffs to keep the three views aligned. Cross-field invariants need dedicated tests and stable errors, and generated files must not be edited manually.
Before tightening a rule, I replay stored objects and measure client behavior. Ambient ratcheting exempts only an unchanged legacy value; once a user edits that field, the new rule applies, so migration tooling and staged rollout remain necessary. After launch I watch rejection rates, version distribution, and retries, rolling back the rule version if needed. GA provides a unified mechanism, not a substitute for compatibility governance.
Common mistakes
- Treating the generator as a formatting tool and missing its role in server runtime behavior.
- Treating OpenAPI as the only validation point while ignoring generated server code and version compatibility.
- Misreading ambient ratcheting as a permanent relaxation even though edited fields still undergo new validation.
- Adding rules without a migration plan, rollout metrics, or rollback path for stored objects.
Follow-up questions and responses
Why not keep writing validation functions by hand?
Handwritten logic is scattered, hard to discover, and prone to inconsistent behavior across resources. Markers, a generator, and a linter make rules reviewable, reproducible, and easier to publish through OpenAPI.
Would tightening a minimum immediately break old objects?
An update that leaves the field unchanged can keep its historical value through ambient ratcheting. Creating an object or editing that field must satisfy the new rule, so clients that read, copy, or rewrite objects still need review.
How do you prove generated code has not drifted?
Pin the generator in CI, run generation, and fail if the working tree changes. Compare OpenAPI, unit tests, and end-to-end rejection behavior; review the generated diff before rolling out a generator upgrade.