> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Infrastructure Provisioning with Kubernetes
> Overview of Kubernetes-centric infrastructure provisioning comparing Crossplane, Terraform/OpenTofu and Cluster API for GitOps driven self-service platform engineering and cluster lifecycle management
All right — welcome to another core topic in CNPA Domain 4: Infrastructure Provisioning with Kubernetes.
This is a foundational area for modern platform engineering. In this lesson we’ll cover three major approaches that platform teams use to manage cloud resources in a Kubernetes-centric environment: Crossplane, Terraform/OpenTofu, and Cluster API. These are important concepts for the CNPA exam and for real-world platform design.
This lesson focuses on Kubernetes-native patterns and trade-offs between Crossplane, Terraform/OpenTofu, and Cluster API. Understanding when to use each will help you design self-service, GitOps-driven platforms.
Why re-think traditional provisioning? Consider this common scenario: your platform supports multiple development teams across AWS and Azure and needs to provide self-service provisioning for databases, storage, and networking — fast, without tickets — and integrated into the same GitOps workflow developers use for applications. You also want consistent behavior across clouds and Kubernetes-native integration.
The core goal is a single source of truth and developer self-provisioning that is GitOps-friendly and, ideally, Kubernetes-native. Below we describe three common approaches and how they differ by native integration, resource scope, and operational model.
## Crossplane — Kubernetes-native infrastructure control
Crossplane is a CNCF project that treats cloud resources as Kubernetes custom resources (CRDs). It runs controllers in-cluster to reconcile those CRs against cloud provider APIs, enabling a Kubernetes-native control plane for external resources. You can compose reusable infrastructure patterns (Compositions) and expose developer-friendly claim APIs (CompositeResourceDefinitions, XRDs).
Benefits:
* Cloud resources become first-class Kubernetes objects with continuous reconciliation.
* Compositions let you package complex infrastructure patterns as templates.
* GitOps-friendly and integrates with Kubernetes RBAC, admission controllers, and observability.
Typical flow for a Database-as-a-Service with Crossplane:
1. Define a CompositeResourceDefinition (XRD) that models what developers can request.
2. Create a Composition template that maps the XRD to concrete cloud resources (e.g., RDS instance, network, secrets).
3. Developers submit a claim (instance of the XRD) and Crossplane reconciles the Composition to provision resources.
Example: install a Crossplane AWS provider using Kubernetes YAML.
```yaml theme={null}
# Provider: Connects to cloud APIs
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-aws
spec:
package: xpkg.upbound.io/crossplane-contrib/provider-aws:v0.44.0
```
Example XRD (schema that defines what developers can request):
```yaml theme={null}
# XRD: Define what developers can request
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
name: xpostgresqlinstances.database.spr.com
spec:
group: database.spr.com
versions:
- name: v1alpha1
schema:
openAPIV3Schema:
properties:
spec:
properties:
storageGB:
type: integer
minimum: 20
engineVersion:
type: string
enum: ["13.7", "14.6", "15.1"]
```
Platform teams like Crossplane because it enforces Kubernetes patterns (reconciliation, RBAC, GitOps) across infrastructure, enabling self-service claims, templated compositions, and standard monitoring.
## Terraform / OpenTofu — mature IaC with operator integrations
Terraform (HashiCorp) is the long-standing infrastructure-as-code tool using HCL and a large provider ecosystem. Terraform’s license change led to community forks such as OpenTofu (a community-driven fork of Terraform); OpenTofu aims to preserve an open-source path while maintaining compatibility with Terraform modules and HCL.
Terraform/OpenTofu characteristics:
* Mature ecosystem and provider coverage.
* HCL language and state management (remote state backends).
* Often used outside the cluster (CI/CD pipelines) or integrated into-cluster via operators.
You can run Terraform from CI (recommended for many teams), or use an in-cluster Terraform Operator that exposes Terraform runs via CRs. A typical pattern is to keep Terraform modules as the canonical module source and trigger runs from a GitOps pipeline or operator.
Example of a Terraform custom resource that triggers an in-cluster Terraform operator:
```yaml theme={null}
# Terraform Operator in Kubernetes
apiVersion: tf.isaaguilar.com/v1alpha1
kind: Terraform
metadata:
name: pony-database-infrastructure
spec:
terraformModule:
source: "git::https://github.com/spr/terraform-modules//rds-postgres"
outputsToSecret:
name: pony-db-connection
```
Notes on trade-offs:
* Terraform/OpenTofu have broad provider coverage and module ecosystems.
* They are not inherently Kubernetes-native; you integrate them into GitOps workflows or run them from CI/CD.
* Crossplane provides tighter Kubernetes-native reconciliation, but Terraform has a lower initial learning curve for many teams and more mature provider modules.
## Cluster API — declarative cluster lifecycle management
Cluster API (CAPI) is a CNCF project that focuses on Kubernetes cluster lifecycle management (provisioning, scaling, upgrades, machine lifecycle) using Kubernetes-style declarative APIs. It’s effectively “Kubernetes managing Kubernetes” — controllers in a management cluster reconcile Cluster and Machine CRs to provision and operate workload clusters.
Cluster API is best suited for:
* Cluster lifecycle: creating, upgrading, and scaling Kubernetes clusters.
* Multi-cloud/hybrid/edge consistent cluster management.
* Use-cases where you want cluster standardization and automation of node and control-plane lifecycle.
Cluster API components include management cluster controllers, control plane controllers, machine controllers, and MachineHealthCheck controllers that automate node lifecycle and control plane operations.
Cluster API example: a Cluster resource that references an AWS infrastructure provider to declare a Kubernetes cluster.
```yaml theme={null}
# Cluster API Cluster resource
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: pony-production-cluster
spec:
clusterNetwork:
pods:
cidrBlocks: ["192.168.0.0/16"]
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: AWSCluster
name: pony-production-cluster
```
Key point: Cluster API is focused on clusters themselves. It is not a general-purpose cloud resource orchestrator like Crossplane or Terraform. You’ll often combine Cluster API with Crossplane or Terraform for underlying networking and cloud resources.
## Comparing the three approaches
* Crossplane: Kubernetes-native, manages a wide range of cloud resources via CRDs and Compositions; excellent for GitOps-driven, self-service platforms. Requires deeper Kubernetes expertise to design compositions effectively.
* Terraform/OpenTofu: Mature IaC, extensive provider ecosystem and modules, generally managed outside the cluster (or integrated via operators). Familiar, approachable HCL workflow and broad community adoption.
* Cluster API: Specialized for Kubernetes cluster lifecycle management. Narrow scope but deep capability for cluster provisioning, scaling, and upgrades.
Team expertise considerations:
* Crossplane: deep Kubernetes skills, composition design, and provider wiring.
* Terraform/OpenTofu: HCL proficiency, state and module management; easier ramp for many teams.
* Cluster API: Kubernetes and cluster operations experience — focused but narrower in scope.
## Patterns and best practices (2025)
Aim for layered abstractions and GitOps-first workflows. Reusable compositions and modules reduce one-off “unicorns.” Policy-as-code and built-in observability ensure compliance and operational visibility across teams.
Implementation guidance (example timeline):
1. Start experimenting with Cluster API to standardize and manage cluster lifecycles.
2. Add Crossplane to model application infrastructure as Kubernetes resources and provide self-service compositions.
3. Keep Terraform/OpenTofu for complex foundational networking, or for teams that already rely on a large Terraform module ecosystem.
4. Expose multiple abstraction levels (platform operators, SREs, and developers) according to persona.
At SparklePonyRanch, the team roles reflect these choices: Swati (SRE) focuses on SLOs/SLA and Cluster API for cluster operations; Alan (Infrastructure) maintains Terraform/OpenTofu modules and Crossplane compositions for application infrastructure; Phuong (Developer) consumes the self-service APIs and GitOps workflows.
## Key takeaways
* Crossplane (CNCF): represents Kubernetes-native infrastructure control using CRDs and composition patterns; ideal when you want infrastructure as Kubernetes objects and tight GitOps integration.
* Terraform / OpenTofu: mature IaC ecosystem using HCL and modules; often the quickest way to adopt IaC at scale and has the largest provider coverage.
* Cluster API (CNCF): specialized for Kubernetes cluster lifecycle management — provisioning, upgrading, scaling — and not a general cloud resource orchestrator.
* Design your platform with layered abstractions, GitOps, policy-as-code, and observability to enable self-service while preserving security and compliance.
Thanks for reading.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.