Day 26: Infrastructure GitOps with Crossplane
What We’re Building Today
Today you’ll deploy a complete Infrastructure-as-Code platform using Crossplane that provisions cloud resources through Git commits. We’ll create custom infrastructure abstractions that let developers request databases, storage, and compute without knowing the underlying cloud provider details. By the end, you’ll push a YAML file to Git and watch it automatically spin up an S3 bucket and PostgreSQL database in AWS.
High-Level Agenda:
Install Crossplane as your infrastructure control plane
Connect it to AWS/GCP as providers
Build composite resources that abstract cloud complexity
Implement GitOps workflows for infrastructure provisioning
Add policy enforcement and cost controls
Core Concepts: Infrastructure GitOps with Crossplane
What is Crossplane?
Crossplane turns Kubernetes into a universal control plane for managing any infrastructure, anywhere. Instead of writing Terraform files or clicking through cloud consoles, you define infrastructure as Kubernetes custom resources. When you apply these resources, Crossplane talks to cloud APIs and makes it happen.
Think of Crossplane as a translator: developers speak Kubernetes YAML, Crossplane translates to AWS/Azure/GCP API calls. This matters because your infrastructure becomes code that flows through the same Git workflow as your applications - reviewed, versioned, and automatically deployed.
Why This Matters: Companies like Upbound (Crossplane creators) use this to manage thousands of cloud resources across multiple providers from a single control plane. When you need to provision infrastructure in 20 different AWS accounts, clicking through consoles doesn’t scale - GitOps does.
The GitOps Infrastructure Loop
Traditional infrastructure provisioning has humans running scripts. GitOps flips this: Git becomes the single source of truth, and automated controllers reconcile reality to match Git’s desired state.
The Flow:
Developer commits infrastructure request (e.g., “I need a PostgreSQL database”)
ArgoCD/Flux detects the change and applies it to Kubernetes
Crossplane sees the new resource and translates it to cloud provider API calls
Cloud provider provisions the actual infrastructure
Crossplane continuously monitors and ensures the infrastructure matches the Git declaration
This creates an audit trail - every infrastructure change is a Git commit with an author, timestamp, and review history.
Composite Resources: Infrastructure Abstractions
Raw cloud resources are complex. An RDS database requires VPCs, security groups, parameter groups, subnet groups - dozens of resources. Composite Resources (XRs) bundle these into simple abstractions.
Example: Instead of developers knowing 15 AWS-specific parameters, you create a Database composite resource that takes just:
size: small/medium/largebackup: enabled/disabled
Behind the scenes, your XR definition maps “small” to “db.t3.micro with 20GB storage” and provisions everything needed. This is infrastructure abstraction working like APIs - simple interface, complex implementation hidden.
Architecture Deep Dive
