Adding a required field to a live CRD

WHAT THIS TESTS Whether you understand CRD versioning, schema validation against stored objects, and backward-compatible API evolution.

A GOOD ANSWER COVERS The danger is that making a field required in the existing version breaks validation for every already-stored resource that lacks it, and can wedge the controller and updates. The safe path is incremental. First, add the field as optional, and where it has a sensible default, declare a default in the schema so the API server backfills it on read and write, immediately giving existing objects a value without anyone editing them. If you truly need it required, introduce a new CRD version, for example v1beta2 alongside v1beta1, and mark one as the storage version. Provide a conversion strategy, often a conversion webhook, so objects can move between versions, and the field can be required in the new version while optional or defaulted in the old. Then migrate stored objects to the new version, update clients and the controller, and only after everything is on the new version deprecate and stop serving the old one. Throughout, both versions remain served so nothing breaks.

COMMON WRONG ANSWERS Immediately editing the live CRD to mark the field required, which invalidates existing resources; forgetting defaults; or skipping a new version and conversion webhook when a genuinely required field is needed.

LIKELY FOLLOW-UPS How do storage versions and conversion webhooks work? What is the difference between served and storage versions? How do you migrate existing stored objects?

ONE CONCRETE EXAMPLE You need a required region field. You first ship it in v1 as optional with a default of us-east-1, so all existing objects gain a value automatically. Later you add v1beta2 where region is required with no default, set it as storage version with a conversion webhook, migrate objects, point the controller and clients at v1beta2, and finally stop serving the older optional version.