English for Crossplane Developers

Crossplane extends Kubernetes vocabulary into infrastructure provisioning, so a platform engineer needs to layer new terms — composition, claim, provider — on top of concepts already familiar from Terraform or plain Kubernetes.

Key Vocabulary

Provider — a Crossplane extension that adds support for a specific cloud or service, such as AWS or GCP, registering the custom resources needed to manage that platform’s infrastructure. “That resource type doesn’t exist yet because we haven’t installed the provider for it — check whether it’s covered by the AWS provider before writing a custom one.”

Composition — a template that defines how a higher-level, platform-team-defined resource maps to one or more underlying cloud resources, encapsulating implementation details from application teams. “Update the composition, not each team’s claim — that’s the whole point of centralizing the implementation in one place.”

Claim — a namespaced request from an application team for infrastructure, written against a simplified API the platform team defined, that Crossplane fulfills using a matching composition. “App teams just submit a claim for a database — they don’t need to know whether it provisions RDS or Cloud SQL underneath.”

Composite resource (XR) — the cluster-scoped resource Crossplane creates in response to a claim, representing the actual bundle of underlying cloud resources being managed. “Check the composite resource’s status, not just the claim — the claim can look healthy while the underlying XR is still reconciling.”

Reconciliation — Crossplane’s continuous process of comparing desired state, as declared in compositions and claims, against actual cloud state, and correcting any drift automatically. “Someone changed the instance size directly in the AWS console — reconciliation will revert it back to what’s declared, so make the change through the claim instead.”

Common Phrases

• “Is this provider actually installed, or is the resource type just not available yet?”
• “Should this change go in the composition, or does it only affect one team’s claim?”
• “Is the claim healthy, or is the underlying composite resource still stuck reconciling?”
• “Did someone modify this outside Crossplane? Reconciliation should catch and revert manual drift.”
• “Does this composition abstract enough detail, or are app teams still exposed to cloud-specific parameters?”

Example Sentences

Debugging a drift issue: “Someone resized the database directly in the cloud console, and reconciliation just reverted it — if that change was intentional, it needs to go through the claim, not the console.”

Explaining an architecture choice: “We built one composition for ‘standard database’ that app teams claim against, so they never have to know or care whether it’s backed by RDS or Cloud SQL.”

Reviewing a pull request: “This hardcodes a specific instance type inside the claim — that detail belongs in the composition so it can be tuned centrally without every team’s claim changing.”

Professional Tips

• Distinguish claim from composite resource precisely — the claim is the namespaced request, the XR is what actually got provisioned, and conflating them makes status debugging confusing.
• Say composition when describing where implementation details should live — it’s the platform team’s abstraction layer, and naming it correctly clarifies ownership.
• Reference provider explicitly when a resource type is missing — it’s usually a missing or outdated provider installation, not a Crossplane bug.
• Use reconciliation to explain automatic drift correction — it reframes “why did my manual change get reverted” from a bug report into expected behavior.

Practice Exercise

1. Explain the difference between a claim and a composite resource.
2. Describe what a composition abstracts away from application teams and why that matters.
3. Write a sentence explaining what reconciliation does when someone makes a manual change outside Crossplane.