Author an `CompositeResourceDefinition` (XRD) manifest with `apiVersion: apiextensions.crossplane.io/v1` and `spec.group`, `spec.names.kind`, and `spec.versions` fields defining the claim API schema.
Note: `apiextensions.crossplane.io/v2` XRDs use a `scope` field and do not support Claims; for namespaced claim-based access use `apiextensions.crossplane.io/v1` with `spec.claimNames`.
Author a `Composition` manifest with `apiVersion: apiextensions.crossplane.io/v1` that lists composed resources (RDS instance, subnet group, parameter group) using `spec.resources[].base` and patch transforms.
Apply both manifests: `kubectl apply -f xrd.yaml -f composition.yaml`; Crossplane registers new CRDs within seconds.
Create a `Claim` resource (the namespaced user-facing kind defined in `spec.claimNames`) and verify that Crossplane creates the corresponding `CompositeResource` and provisions all composed managed resources.
Use `kubectl get compositeresourcedefinitions` and `kubectl get compositions` to verify status; use `kubectl describe` on the composite resource to trace provision failures.
Known gotchas
Crossplane v2 changed default XRD scope to Namespaced and removed Claims from the v2 API; if upgrading from v1 to v2 XRDs, verify that your claim-based workflows are migrated to the new namespaced composite resource model.
Patch transforms in Compositions run in order; a missing field in the claim that a patch references will leave the composed resource field unset, often resulting in a provider validation error.
Crossplane requires the relevant Provider (e.g., provider-aws) to be installed and configured with credentials before Compositions that reference its managed resource types can reconcile.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp