Over the past few weeks I’ve been building something I’ve wanted to try for a while: a GitOps-managed, multi-cloud control plane using Crossplane.
🍀The core idea🍀
Instead of running Terraform apply every time infrastructure needs to change, the management cluster (`gke-mgmt`) runs Crossplane, which continuously reconciles the desired state described in Git against the actual state in the cloud. Add a YAML file describing a database, push it, and Crossplane creates it. Delete the file, and it tears it down. No manual `apply`, no drift between what’s documented and what’s running.
FluxCD handles the GitOps loop; Crossplane handles the actual cloud API calls; OpenBao handles secrets, synced into clusters via External Secrets Operator.
Crossplane’s provider ecosystem covers essentially every major cloud (AWS, Azure, and more), Helm provider, Kubernetes provider. «Multi-cloud» here it means one declarative pattern that doesn’t care where the API endpoint lives.
🍀Two kinds of repositories, on purpose🍀
One decision that paid off: infrastructure and application code live in separate repositories, with separate lifecycles. Three repositories handle infrastructure — one for the Terraform bootstrap layer, one for the management cluster’s GitOps state, one per workload cluster. Everything else — the actual applications running on top lives in its own repository with its own CI pipeline, building and pushing container images that the infrastructure layer picks up automatically via Flux’s image automation. Infrastructure changes and application deploys never touch the same pull request, and each repo has exactly the access it needs — nothing more.
🍀You still need Terraform first🍀
Crossplane needs somewhere to run — Kubernetes cluster, which itself needs to be created by something.
So the real architecture is a two-layer bootstrap:
- Terraform (for example) creates the management cluster, core IAM/OIDC trust relationships, and KMS keys infrastructure that changes rarely and needs a human in the loop.
- Crossplane, running inside that cluster, takes over everything downstream: additional clusters (including on other clouds), managed databases, storage buckets and etc.
You can pause the management cluster when you’re not actively changing infrastructure. The GKE dev cluster, the Cloud SQL instance, the storage bucket — none of them depend on Crossplane being «up» to keep running. It only needs to be running when you want reconciliation, drift correction, or new resources.
The honest caveat: while it’s paused, nothing gets corrected if something drifts, and any secret rotation that depends on it pauses too. It’s a real cost-saving lever, but for a personal use.
🍀🍀🍀🍀🍀🍀🍀🍀🍀
#Crossplane#MultiCloud#IaC#FluxCD#GitOps
