Kubernetes CRD Design Patterns
Use these patterns when designing and implementing CRDs, webhooks, controllers, and RBAC for Kubernetes operators.
Problem Framing
Before writing code:
- Summarize the user problem in one sentence.
- List the CRD's top three responsibilities.
- Identify safety risks if the controller misbehaves.
CRD Schema Design
Propose:
specfields with types, validation markers, and requirednessstatusfields for observed state, conditions, and generation tracking- default markers for safe optional fields
- validation markers for enum, minimum, pattern, and cross-field rules
- printer columns for useful
kubectl getoutput
Enable the status subresource when the CR reports status.
Webhook Design
Validating Webhook
- Block invalid creates and updates.
- Enforce immutable fields on update.
- Validate cross-field constraints.
- Return clear, user-facing error messages.
Mutating Webhook
- Default only safe, optional fields.
- Do not overwrite explicit user input.
- Add only predictable labels or annotations the controller depends on.
Failure Policy
- Use
Ignorein local dev if availability matters more than strict enforcement. - Use
Failwhen the environment requires safety over availability.
Reconcile Loop
Follow this sequence:
- Fetch the CR.
- Handle deletion and finalizers.
- Compute desired state from the spec.
- Create, update, or delete owned resources.
- Update status and conditions.
- Requeue only when needed.
Keep the reconcile function idempotent and level-triggered.
RBAC Minimization
Grant only the verbs and resources the controller needs:
- CRD:
get,list,watch,patch,updateon status if used - owned resources: the minimal CRUD verbs actually exercised
- events:
createandpatch
Avoid wildcards and cluster-wide scope unless the resource model requires it.
Test Outline
Minimum coverage:
- table-driven unit tests for reconcile logic
- envtest or equivalent integration tests for webhook validation
- valid and invalid sample CRs for manual verification