How do you implement GitOps for infrastructure provisioning with Crossplane and Cluster API?

Both Crossplane and Cluster API extend the Kubernetes API with CRDs that represent infrastructure resources. Because the desired state is expressed as Kubernetes objects, a standard GitOps operator (Argo CD or Flux) can manage those objects from Git — giving you continuous reconciliation and drift detection for cloud infrastructure, not just application workloads.

Crossplane manages cloud resources (RDS, S3, GKE clusters, IAM roles) through provider plugins. You define a CompositeResourceDefinition (XRD) that creates a new API type, and a Composition that maps it to provider-specific resources. Developers then create a Composite Resource Claim (XRC) stored in the GitOps repo — Crossplane provisions the cloud resource and injects connection secrets into the cluster.

# Developer commits this Claim to the GitOps config repo
apiVersion: database.example.org/v1alpha1
kind: PostgreSQLInstance
metadata:
  name: app-db
  namespace: production
spec:
  parameters:
    storageGB: 20
    version: "14"
    region: eu-west-1
  compositionRef:
    name: postgresql-aws-rds
  writeConnectionSecretToRef:
    name: app-db-credentials

Cluster API (CAPI) manages the lifecycle of Kubernetes clusters themselves as Kubernetes objects on a management cluster. Cluster, MachineDeployment, and infrastructure-provider-specific CRs (AWSManagedControlPlane, AzureManagedMachinePool, etc.) are stored in Git. A GitOps operator syncs them to the management cluster; CAPI provisions, upgrades, and scales workload clusters accordingly.

The combined pattern: Cluster API provisions workload clusters, Crossplane provisions cloud dependencies (databases, queues, buckets), and a second GitOps instance (Argo CD or Flux) on the new workload cluster deploys the application — all driven from a single Git repository hierarchy, each layer's CRs committed and reconciled continuously.