How do you integrate Flux with Crossplane to manage both Kubernetes workloads and cloud infrastructure from a single GitOps workflow?

The combination of Flux and Crossplane represents a powerful pattern for full-stack GitOps, where both application workloads and their cloud infrastructure dependencies are declared in Git and reconciled automatically. Crossplane extends Kubernetes with providers that can provision and manage cloud resources like RDS databases, ElastiCache clusters, S3 buckets, and IAM roles through Kubernetes custom resources. Flux provides the Git-based reconciliation layer that applies these Crossplane resources along with application manifests, creating a unified workflow where a single pull request can provision a database, create a Kubernetes secret with the connection string, and deploy the application that uses it.

The architecture requires careful ordering of components. Crossplane itself must be installed before any providers or compositions, providers must be installed and healthy before managed resources or composite resources, and infrastructure resources must be ready before applications that depend on them. Flux handles this through the dependsOn field in Kustomization resources. A typical setup has three Kustomizations: one for Crossplane core and providers, one for compositions and composite resource definitions, and one for the actual infrastructure claims and application workloads. Each depends on the previous one, ensuring the proper installation order. Health checks on the Crossplane providers verify they are installed and ready before compositions are applied.

Compositions are where Crossplane becomes powerful for platform teams. A Composition defines how a high-level claim like a DatabaseClaim maps to low-level cloud resources like an RDS instance, a subnet group, a security group, and a Kubernetes secret containing the connection details. Platform engineers write these compositions and store them in Git, where Flux applies them to the cluster. Application developers then create simple claims that reference these compositions, abstracting away cloud provider details. For example, a payments-api team can request a PostgreSQL database by creating a DatabaseClaim with size small and the Composition handles provisioning an RDS db.t3.medium instance with appropriate backup settings, encryption, and network configuration.

Connection details flow from Crossplane-provisioned resources to applications through Kubernetes secrets. When Crossplane creates an RDS instance, it writes the endpoint, port, username, and password to a connection secret. Flux can then reference this secret in application Kustomizations through variable substitution or through standard Kubernetes secret references in pod specs. The challenge is timing: the secret does not exist until Crossplane finishes provisioning, which can take several minutes for resources like RDS instances. Flux health checks and retries handle this naturally, as the application Kustomization will retry until the secret exists and the deployment can start successfully.

Operating this stack in production requires monitoring both Flux reconciliation status and Crossplane resource health. Crossplane managed resources have conditions that indicate whether the cloud resource is synced, ready, or in an error state. Flux notification-controller can alert on reconciliation failures, but teams should also monitor Crossplane-specific metrics for provisioning latency, API throttling from cloud providers, and drift between the desired Crossplane state and actual cloud resource configuration. Cost management is another consideration, as a Git commit can now provision expensive cloud resources. Teams implement Crossplane usage policies and OPA Gatekeeper constraints to prevent accidental provisioning of oversized instances, and use separate Git branches with approval requirements for infrastructure changes.