A Crossplane composition turns a simple infrastructure request into the resources needed to fulfill it. Provisioning a database may also require network configuration, credentials, and connection details. A platform team defines that implementation; an application team requests the capability through a Kubernetes resource without managing each underlying component. section 5.2.1 section 5.2.2
The request and its implementation are separate:
- A Composite Resource Definition (XRD) defines the interface, such as a Database resource with parameters for size and mock data. section 5.3
- A Composition names the resources that fulfill the request and identifies the composite type it implements. A local key/value Database composition uses a Crossplane Helm provider Release for Redis; a SQL composition uses a PostgreSQL release. section 5.3
- The requested resource selects an implementation with compositionSelector.matchLabels. Labels distinguish local key/value and SQL options; another SQL request selects a GCP implementation. section 5.3
Listing 5.7 Key/value Database Crossplane composition
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: keyvalue.db.local.salaboy.com #1
labels: #2
type: dev
provider: local
kind: keyvalue
spec:
writeConnectionSecretsToNamespace: crossplane-system
compositeTypeRef: #3
apiVersion: salaboy.com/v1alpha1
kind: Database
resources:
- name: redis-helm-release #4
base:
apiVersion: helm.crossplane.io/v1beta1
kind: Release
metadata:
annotations:
crossplane.io/external-name: # patched
spec:
rollbackLimit: 3
forProvider:
namespace: default
chart: #5
name: redis
repository: https://charts.bitnami.com/bitnami
version: "17.8.0"
values:
architecture: standalone
providerConfigRef: #6
name: default
patches: #7
- fromFieldPath: metadata.name
toFieldPath: metadata.annotations[crossplane.io/external-name]
policy:
fromFieldPath: Required
- fromFieldPath: metadata.name
toFieldPath: metadata.name
transforms:
- type: string
string:
fmt: "%s-redis"
readinessChecks: #8
- type: MatchString
fieldPath: status.atProvider.state
matchString: deployed
The key/value Database Composition declares its composite type and a Redis Helm Release, showing where the simple Database interface meets its implementation. section 5.3
Connect the Conference application
The Conference application needs Redis, PostgreSQL, and Kafka. For a local walking skeleton, the Crossplane Helm provider provisions them separately from the application chart. Request Database and MessageBroker resources, then check `kubectl get dbs` and `kubectl get mbs` for READY status. Install the application with its bundled infrastructure disabled (`install.infrastructure=false`) and supply a values file containing the provisioned service names and database Secret names. This separation lets the application use infrastructure managed outside its own Helm dependencies. section 5.3 section 5.3.1
Compositions can also expose development environments. An Environment request can select a composition that provisions an isolated virtual cluster through the Helm provider and installs the Conference application. Other environment implementations can use a namespace or a cloud cluster. The requesting team uses the same resource-facing workflow while the platform team chooses how isolation is delivered. section 6.3 section 6.3.2
This abstraction reduces the cloud-specific work application teams must handle, but it does not remove operational responsibility: teams running Crossplane need Kubernetes skills. The local Helm-provider example demonstrates the request pattern without requiring cloud access; a cloud-provider composition can fulfill the same kind of request differently. section 5.3 section 5.4
