Skip to main content
We have built CRDs for custom APIs and controllers, and implemented orchestration workflows — but there is still a common gap: Your application deploys nicely with GitOps, but when a developer needs infrastructure (for example, a database) they switch to a different tool and workflow. Two tools, two pipelines, two mental models. Crossplane fills this gap by extending Kubernetes so you can manage any infrastructure using the same kubectl commands, YAML manifests, and GitOps workflows your teams already use. In this lesson we will:
  • Explain why separate app and infra workflows cause friction.
  • Introduce Crossplane’s core concepts and flow.
  • Show how to define platform APIs with XRDs, map APIs to cloud and Kubernetes resources with Compositions, and expose those as developer-facing XRs.
Crossplane lets platform teams provide developer-friendly Kubernetes APIs (XRs) that create and reconcile both cloud-managed resources and Kubernetes resources from a single manifest — enabling true self-service.
Real-life problem A developer at a mid-sized SaaS company needs a PostgreSQL database for a new feature. Their day looks like this:
  • They write code and push it to Git.
  • Argo CD deploys the application after a few minutes.
  • To provision a database they switch to Terraform.
  • They write HCL they’re not comfortable with and submit a change.
  • The infra team reviews (2-day SLA) and runs a separate CI pipeline to apply the Terraform.
  • After provisioning, the developer manually creates Kubernetes Secrets with connection strings.
  • They push the secret reference to Git and wait for Argo CD to sync.
Total turnaround: two to three days for a database the developer needed minutes ago.
A workflow diagram titled "From Multi-Tool Delay to Self-Service Provisioning" showing a nine-step current process for deploying an app. It maps steps from pushing code and ArgoCD deploy through Terraform and infra review to manual DB/secret provisioning, with a total turnaround of about 2–3 days.
Contrast: if developers could simply run a single Kubernetes manifest:
the whole workflow can shrink from days to minutes — with the same GitOps controls and RBAC you already have.
A slide showing a Kubernetes-native workflow diagram with five numbered steps: Apply Manifest (Database.yaml), Kubernetes API (declarative request), Provision DB (automated), Inject Secret (auto-generated), and App Connects (ready in minutes). It illustrates self-service provisioning from manifest to a connected app.
The common symptoms of tool sprawl
  • App deployment runs in Kubernetes with Argo CD.
  • Infrastructure runs in Terraform with a separate CI pipeline.
  • The two systems are disconnected, creating manual handoffs and long SLAs.
Three platform requirements to solve this
  • Single abstraction — one YAML to declare app + database + networking + security.
  • Namespace isolation — developers operate in their namespaces with RBAC.
  • Continuous reconciliation — platform automatically detects drift and self-heals all resources, cloud and Kubernetes.
A presentation slide titled "Infrastructure and Apps Remain Separate" that lists three platform needs: 01 Single abstraction, 02 Namespace-based isolation, and 03 Continuous reconciliation. The items are shown as three numbered boxes inside a bordered area (© KodeKloud).
Why Crossplane? Crossplane’s core insight: Kubernetes is already an excellent control plane for desired state. It provides declarative YAML, reconciliation loops, RBAC, and a mature ecosystem. Instead of building a separate control plane for infrastructure, extend Kubernetes using Crossplane.
A presentation slide titled "Crossplane – Kubernetes for Everything" showing the Kubernetes logo and the caption "Best control plane for managing state." It also lists features like Declarative YAML, Reconciliation loops, RBAC, and a Massive ecosystem.
Core Crossplane concepts at a glance
A presentation slide titled "Crossplane — Kubernetes for Everything" showing four numbered components: 01 Providers, 02 Managed Resources, 03 Composite Resources (XRs), and 04 XRDs with short descriptions. Providers connect to cloud APIs, Managed Resources are individual cloud resources, Composite Resources combine multiple resources, and XRDs are composite resource definitions.
Platform-side flow (high level)
  1. Platform team defines the developer API by authoring an XRD (CompositeResourceDefinition).
  2. Platform team writes one or more Compositions that map the API fields to concrete managed and Kubernetes resources.
  3. Developers request resources by creating XRs; Crossplane matches XRs to a Composition and provisions everything.
Developer self-service Developers create a Composite Resource (XR) in their namespace — just like any other Kubernetes resource. Crossplane validates the XR against the XRD, selects a Composition, and provisions the composed resources automatically.
A presentation slide titled "Crossplane — Kubernetes for Everything" showing a left-to-right flowchart: "XRD defines the API schema" → "Composition maps API to resources" → "Developer creates XR in namespace" → "Crossplane creates managed resources." There’s a KodeKloud copyright notice in the bottom-left.
Providers and managed resources Providers are installed as packages and register CRDs for cloud-managed resources. For example provider-aws registers CRDs for S3, RDS, VPC, IAM, and many more. provider-gcp registers GCP resources, and provider-kubernetes enables Crossplane to manage remote Kubernetes clusters. Example Provider package manifest:
After installing a provider, its managed resources appear as Kubernetes kinds. Managed resources include a spec.forProvider section (cloud-specific config). Crossplane’s controllers handle API calls to create and reconcile them. In practice you rarely create managed resources directly. Instead, platform teams provide higher-level abstractions (XRs) and Compositions instantiate managed resources. Still, understanding managed resources is useful — they are the underlying building blocks. XRDs (CompositeResourceDefinition) XRDs declare the developer-facing API schema: fields, types, defaults, enums, required properties, and scope (Namespaced or Cluster). In Crossplane v2 you can make the XR itself namespaced (removing the older need for “claims”).
A presentation slide titled "XRDs – Define Your Platform API" showing a blue block labeled "XRD" with an arrow pointing to a larger container that contains two grey boxes labeled "Namespaced XR" and "Cluster-Scoped XR." The slide appears to illustrate how an XRD maps to namespaced and cluster-scoped XR resources.
Important: In Crossplane v2, prefer making XRs namespaced when you want per-team isolation. Older “claim” patterns used cluster-scoped XRs with namespace-scoped claims; this extra indirection is unnecessary with namespaced XRs.
Developer request example (XR) A developer creates a Database XR in their namespace. Crossplane validates it against the XRD and triggers the Composition pipeline:
Compositions — mapping APIs to concrete resources A Composition answers: when a developer requests size “medium”, what actual resources should be created and how should fields map? A Composition lists the composed resources and defines how values flow from the XR into those composed resource specs. Compositions use pipeline mode with functions. Each pipeline step runs a function to render, transform, or patch resource specs. The most common function is function-patch-and-transform: it takes values from the XR spec and patches them into composed resource specs, optionally transforming them (for example, size: medium → instanceClass: db.r5.large).
A presentation slide titled "Compositions – Map APIs to Resources" showing a row of connected blue nodes labeled "F" and a large box labeled "Common Function" containing "function-patch-and-transform." Below that are linked boxes reading "XR Spec" → "Composed Resource Specs," illustrating the mapping flow.
Composition flow summary
  • Developer creates an XR.
  • The Composition pipeline runs functions to render composed resource manifests.
  • Crossplane creates managed resources and any Kubernetes resources listed in the Composition.
  • Reconciliation keeps all resources in the desired state.
Compositions can include Kubernetes resources A Composition can create cloud-managed resources and any Kubernetes resources together. This enables a single XR to provision Deployments, Services, ConfigMaps, Ingress, Secrets, cloud RDS instances, security groups, and more — all reconciled by Crossplane.
A presentation slide titled "Compose Apps and Infrastructure Together" showing a box labeled "Composition Creates Everything" containing component tiles: Deployment, Services, ConfigMaps, Ingress Resource with RDS Instance, and Security Group.
Example: Microservice XR that provisions app + DB
A single kubectl apply of this XR can result in:
  • a Deployment and Service,
  • an Ingress,
  • an RDS instance and security group,
  • a Secret containing connection strings,
—all created and continuously reconciled by Crossplane. Key takeaways
  • XRDs define platform API schemas and scope.
  • XRs (composite resources) are the developer-facing requests and can be namespaced for multi-tenancy.
  • Compositions map XRs to managed and Kubernetes resources using pipeline mode and functions such as function-patch-and-transform.
  • With Crossplane you can expose a single manifest that provisions and connects both application and infrastructure components, enabling self-service and consistent GitOps workflows.
A presentation slide titled "Key Takeaways" with four colorful numbered points down the right side. It summarizes: XRDs define your platform API; XRs are namespaced for multi-tenancy; Compositions use Pipeline mode with functions; and you can compose any Kubernetes resource.
Further reading and references

Watch Video