Demo Compositions with Crossplane

Crossplane is where platform engineering becomes practical and powerful. It lets platform teams expose a simple Kubernetes API (for example, a Database resource) and have Crossplane provision and manage the underlying infrastructure on behalf of users. Consumers declare intent; the platform handles the implementation details. Key concepts:

XRD (CompositeResourceDefinition) — defines the user-facing API and which fields users can set.
Composition — implements the XRD by creating provider or Kubernetes resources and applying patches/transforms.

In this lesson we will:

Inspect the Crossplane control plane components.
Review a Database XRD and its Composition.
Create two example Database composite resources and show how inputs are transformed into provider or Kubernetes resources.

What is running in the control plane

Check the Crossplane controllers, the RBAC manager, the patch-and-transform function and the Kubernetes provider:

controlplane ~ ➜ kubectl get pods -n crossplane-system
NAME                                                         READY   STATUS    RESTARTS   AGE
crossplane-5cb76b766d-zh6fd                                   1/1     Running   0          24m
crossplane-rbac-manager-74494cb9bf-55wgx                      1/1     Running   0          24m
function-patch-and-transform-c05a9add149b-5bf6d6868d-qwbr2    1/1     Running   0          21m
provider-kubernetes-fd54bbc7f877-574d9bdb9-g9dxs               1/1     Running   0          23m

List the XRDs available:

controlplane ~ ➜ kubectl get xrd
NAME                            ESTABLISHED   OFFERED   AGE
databases.platform.example.com  True          20m

Quick commands (useful references while following this demo):

Action	Command
List Crossplane pods	`kubectl get pods -n crossplane-system`
List XRDs	`kubectl get xrd`
Describe a composite instance	`kubectl describe database <name> -n <namespace>`
Get generated provider/Kubernetes resource (example)	`kubectl get configmap db-config -n <targetNamespace> -o yaml`

Inspect the XRD

An XRD (CompositeResourceDefinition) looks similar to a CRD. It defines:

the composite’s API group and kind,
its scope (Namespaced or Cluster),
and the openAPI schema for the user-facing spec.

Here is the Database XRD used in this demo:

apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  creationTimestamp: "2026-04-13T03:09:00Z"
  finalizers:
  - defined.apiextensions.apiextensions.io
  generation: 1
  name: databases.platform.example.com
  resourceVersion: "5514"
  uid: dff98277-ba0c-4b63-8d5d-8b8a793fc6a1
spec:
  defaultCompositeDeletePolicy: Background
  defaultCompositionUpdatePolicy: Automatic
  group: platform.example.com
  names:
    kind: Database
    plural: databases
  scope: Namespaced
  versions:
  - name: v1
    referenceable: true
    schema:
      openAPIV3Schema:
        properties:
          spec:
            properties:
              engine:
                enum:
                - postgresql
                - mysql
                type: string
              environment:
                type: string
              size:
                enum:
                - small
                - medium
                - large
                type: string
              targetNamespace:
                type: string
            required:
            - engine
            - size
            - environment
            - targetNamespace
            type: object
        type: object
  served: true
status:
  conditions:
  - lastTransitionTime: "2026-04-13T03:09:01Z"

The scope controls where composite instances live. Namespaced means users create Database resources in a namespace (and RBAC applies at namespace level). Cluster scope makes them cluster-wide. Choose scope deliberately to match your platform UX and RBAC model.

Inspect the Composition

Compositions map a composite type (the XRD) to concrete provider or Kubernetes resources. This example uses a pipeline Composition with a function that applies patches and transformations. The Composition is bound to the Database XRD via compositeTypeRef.

apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
  name: database-kubernetes
spec:
  compositeTypeRef:
    apiVersion: platform.example.com/v1
    kind: Database
  mode: Pipeline
  pipeline:
  - functionRef:
      name: function-patch-and-transform
    input:
      apiVersion: pt.fn.crossplane.io/v1beta1
      kind: Resources
      resources:
      - name: database-config
        base:
          apiVersion: kubernetes.m.crossplane.io/v1alpha1
          kind: Object
          spec:
            forProvider:
              manifest:
                apiVersion: v1
                kind: ConfigMap
                metadata:
                  name: db-config
                  namespace: default
                data: {}
            providerConfigRef:
              kind: ClusterProviderConfig
              name: default
        patches:
        - fromFieldPath: spec.targetNamespace
          toFieldPath: spec.forProvider.manifest.metadata.namespace
          type: FromCompositeFieldPath
        - fromFieldPath: spec.engine
          toFieldPath: spec.forProvider.manifest.data.engine
          type: FromCompositeFieldPath
        - fromFieldPath: spec.environment
          toFieldPath: spec.forProvider.manifest.data.environment
          type: FromCompositeFieldPath
        - fromFieldPath: spec.size
          toFieldPath: spec.forProvider.manifest.data.instanceClass
          transforms:
          - type: map
            map:
              large: db.r5.large
              medium: db.t3.medium
              small: db.t3.micro
    step: patch-and-transform

Why this Composition matters:

The base resource is a Kubernetes Object (here a ConfigMap) which Crossplane will create in the target cluster and namespace.
patches copy fields from the composite spec into the provider/Kubernetes resource.
The map transform translates user-friendly choices (small, medium, large) into provider-specific instance classes.

Comparison: XRD vs Composition

Component	Purpose	Example from demo
XRD (CompositeResourceDefinition)	Define the user-facing API and schema	`databases.platform.example.com` defining `spec.engine`, `spec.size`, etc.
Composition	Implement the XRD by creating provider/Kubernetes resources and applying patches/transforms	`database-kubernetes` creating a `ConfigMap` and mapping values with `map` transform

We will now demonstrate two user-facing Database resources and observe what Crossplane creates.

Example 1 — orders-db (postgresql, large)

User creates a Database composite resource named orders-db:

# orders-db.yaml
apiVersion: platform.example.com/v1
kind: Database
metadata:
  name: orders-db
  namespace: default
spec:
  engine: postgresql
  size: large
  environment: prod
  targetNamespace: team-frontend

Apply it:

controlplane ~ ➜ kubectl apply -f orders-db.yaml
database.platform.example.com/orders-db created

Check the composite instance:

controlplane ~ ➜ kubectl get database orders-db
NAME       SYNCED   READY   COMPOSITION            AGE
orders-db  True     True    database-kubernetes   17s

Crossplane used the Composition to create a ConfigMap in the team-frontend namespace. Inspect the generated ConfigMap:

controlplane ~ ➜ kubectl get configmap db-config -n team-frontend -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-config
  namespace: team-frontend
  creationTimestamp: "2026-04-13T03:33:04Z"
  resourceVersion: "9044"
  uid: b53a553a-5c5f-4e8e-a0a7-607ef629f6d3
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","data":{"engine":"postgresql","environment":"prod","instanceClass":"db.r5.large"},"kind":"ConfigMap","metadata":{"name":"db-config","namespace":"team-frontend"}}'
data:
  engine: postgresql
  environment: prod
  instanceClass: db.r5.large

Observation:

The user specified size: large; the Composition mapped that to instanceClass: db.r5.large using a map transform. The platform handled provider-specific details, so the user didn’t need to know the exact instance class name.

Example 2 — small-db (mysql, small)

Create a second Database with smaller size and a different target namespace:

# small-orders-db.yaml
apiVersion: platform.example.com/v1
kind: Database
metadata:
  name: small-db
  namespace: default
spec:
  engine: mysql
  size: small
  environment: dev
  targetNamespace: team-backend

Apply it:

controlplane ~ ➜ kubectl apply -f small-orders-db.yaml
database.platform.example.com/small-db created

Check the composite and the generated ConfigMap:

controlplane ~ ➜ kubectl get database small-db
NAME       SYNCED   READY   COMPOSITION            AGE
small-db   True     True    database-kubernetes   12s

controlplane ~ ➜ kubectl get configmap db-config -n team-backend -o yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-config
  namespace: team-backend
  creationTimestamp: "2026-04-13T03:36:32Z"
  resourceVersion: "9548"
  uid: cae60d0b-b1e7-4548-8db5-34e024fd56b9
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: '{"apiVersion":"v1","data":{"engine":"mysql","environment":"dev","instanceClass":"db.t3.micro"},"kind":"ConfigMap","metadata":{"name":"db-config","namespace":"team-backend"}}'
data:
  engine: mysql
  environment: dev
  instanceClass: db.t3.micro

Again, the size: small value from the composite was translated to db.t3.micro in the generated ConfigMap by the Composition’s map transform.

To diagnose Crossplane-managed resources, inspect resource conditions first. Use kubectl describe (for example, kubectl describe database orders-db) and review the .status.conditions fields. Synced and Ready follow the same operator-style condition patterns used by Kubernetes controllers.

Summary

XRDs define the user-facing API and schema; Compositions implement that API by provisioning provider or Kubernetes resources.
Patches and transforms in Compositions allow platform authors to expose simple, user-friendly fields while mapping them to provider-specific configuration.
Transform types like map let platform authors present meaningful choices (small/medium/large) and translate these to concrete provider settings (db.t3.micro, db.t3.medium, db.r5.large).
Users declare high-level intent (engine, size, environment, targetNamespace); Crossplane translates that intent into real resources in the correct namespaces with provider-specific values.

Next steps:

Open the Composition and explore additional transform types (e.g., string, fromCompositeFieldPath, math transforms).
Try adding or modifying transforms in the Composition to observe how they change the generated provider resources.

Links and references

Crossplane Documentation
Crossplane Composition transforms reference (search for transforms and functions)
Kubernetes documentation - CustomResourceDefinitions

Course Introduction

Platform Architecture and Infrastructure

GitOps and Continuous Delivery

Platform APIs and Self-Service Capabilities

Observability and Operations

Security and Policy Enforcement

Conclusion

Demo Compositions with Crossplane

What is running in the control plane

Inspect the XRD

Inspect the Composition

Example 1 — orders-db (postgresql, large)

Example 2 — small-db (mysql, small)

Summary

Links and references

Watch Video

Practice Lab

​What is running in the control plane

​Inspect the XRD

​Inspect the Composition

​Example 1 — orders-db (postgresql, large)

​Example 2 — small-db (mysql, small)

​Summary

​Links and references

Watch Video

Practice Lab

What is running in the control plane

Inspect the XRD

Inspect the Composition

Example 1 — orders-db (postgresql, large)

Example 2 — small-db (mysql, small)

Summary

Links and references