Crossplane Kubernetes Infrastructure Management
Crossplane Kubernetes infrastructure management extends the Kubernetes API to provision and manage cloud resources using the same declarative approach you use for containers. Therefore, platform teams can offer self-service infrastructure through standard Kubernetes tooling. This guide covers production deployment patterns for multi-cloud environments.
Why Kubernetes-Native Infrastructure
Terraform and Pulumi require separate toolchains, state management, and access controls from your application platform. Moreover, developers must learn additional tools and workflows to provision infrastructure. As a result, platform teams become bottlenecks for resource provisioning.
In contrast, Crossplane lets developers request infrastructure using kubectl and standard Kubernetes manifests. Consequently, the same GitOps workflows that manage applications also manage infrastructure.
Kubernetes-native infrastructure management across cloud providers
Crossplane Kubernetes Infrastructure with Compositions
Compositions define reusable infrastructure templates that abstract cloud-specific details. Specifically, a platform team creates a composition for a database that works across AWS, GCP, and Azure:
apiVersion: apiextensions.crossplane.io/v1
kind: Composition
metadata:
name: database.platform.example.com
spec:
compositeTypeRef:
apiVersion: platform.example.com/v1alpha1
kind: Database
resources:
- name: rds-instance
base:
apiVersion: rds.aws.upbound.io/v1beta1
kind: Instance
spec:
forProvider:
engine: postgres
engineVersion: "16"
instanceClass: db.t3.medium
allocatedStorage: 50
publiclyAccessible: false
Developers then request databases through simple claims without knowing the underlying cloud provider. Therefore, infrastructure provisioning becomes as simple as deploying a pod.
Provider Configuration and Authentication
Crossplane providers connect to cloud APIs using provider configs with credentials stored in Kubernetes secrets. Furthermore, IRSA on AWS and Workload Identity on GCP enable credential-free authentication. Additionally, provider packages install cloud-specific CRDs automatically.
However, managing provider versions requires careful planning. As a result, pin provider versions in production and test upgrades in staging first.
Multi-cloud provider configuration with unified Kubernetes control plane
GitOps Integration with ArgoCD
Crossplane resources are standard Kubernetes objects, making ArgoCD integration seamless. Specifically, infrastructure definitions live alongside application manifests in Git repositories. Moreover, ArgoCD detects drift between desired and actual infrastructure state and reconciles automatically.
For example, if someone manually changes an RDS instance size through the AWS console, Crossplane detects the drift and restores the declared configuration. Meanwhile, all changes are auditable through Git history.
Production Best Practices
Monitor Crossplane with standard Kubernetes observability tools. Furthermore, implement resource quotas to prevent infrastructure sprawl. Therefore, use namespaced claims with RBAC policies that limit which teams can provision which resource types and sizes.
Production Crossplane deployment with monitoring and drift detection
Related Reading:
Further Resources:
In conclusion, Crossplane Kubernetes infrastructure management unifies application and infrastructure workflows under a single API. Therefore, adopt Crossplane to give developers self-service infrastructure while maintaining platform team governance.