Crossplane for CTOs: When Kubernetes Becomes Your Infrastructure Control Plane

Crossplane for CTOs: crossplane as an infrastructure control plane

Crossplane releases ship on a tight cadence. v1.19 is dated Feb 11, 2025 and v1.22 is planned for early Nov 2025, with published EOL windows you can plan around. That release discipline matters if you want Kubernetes to manage cloud resources, not just pods.

Crossplane turns infrastructure into Kubernetes APIs. That shift changes how platform teams ship, how developers self-serve, and how you govern multi-cloud.

What is crossplane and why platform teams keep picking it

Crossplane is an open source control plane that extends Kubernetes with custom APIs for infrastructure. Platform teams define higher-level resources, and Crossplane reconciles them into real cloud resources.

Crossplane fits best when Kubernetes. Teams are comfortable with YAML, GitOps, and the controller model where the system keeps reconciling until reality matches the desired state.

Here are the core building blocks that matter in practice:

• Providers: controllers that manage external systems like AWS, Azure, GCP, or SaaS APIs.
• Managed Resources: low-level CRDs that map closely to cloud primitives, like an RDS instance.
• XRDs (CompositeResourceDefinitions): your internal API types, like DatabaseService.
• Compositions: templates that turn a claim into a set of managed resources.
• Claims: developer-facing objects that request a capability, not a pile of cloud parts.

InfoQ described the dominant enterprise pattern as Crossplane backing an internal developer platform. Platform teams expose APIs like Environment, Application, or DatabaseService, and compositions handle provisioning, networking, security controls, and backups. Developers get self-service, and the org gets standard config and policy without ticket reviews (InfoQ on CNCF graduation).

Crossplane also shows up in multi-cluster and hybrid setups. Kubernetes adoption content aimed at 2025 calls out Crossplane as part of the toolset for orchestrating multi-cluster environments while keeping consistency and governance (Jeevi Academy Kubernetes trends).

Crossplane is not “Terraform in Kubernetes.” Crossplane is a control plane with an API contract.

How Crossplane compares to Terraform and Pulumi for enterprise IaC

Most CTOs I talk to don’t ask “Is Crossplane good?” The real question is “Where does it sit next to Terraform?” The answer comes down to who owns the interface and how you want teams to work day to day.

Here’s a comparison table I use in exec reviews.

Crossplane’s big win is the API boundary. A platform team can publish DatabaseService and hide VPC wiring, encryption, backups, and tagging.

Terraform’s big win is maturity and the hiring market. You can staff a Terraform team fast.

Pulumi’s big win is expressiveness. Teams can write loops and tests in the same language.

A CTO decision should start with one question.

Do you want developers to request infrastructure through Kubernetes objects?

If the answer is yes, Crossplane fits. If the answer is no, Crossplane turns into a forced abstraction and teams will fight it.

The Crossplane Fit Matrix (link-worthy)

I use a simple matrix in platform steering meetings. Score each row 0 to 2. A total of 10 or more points means Crossplane is a strong bet.

How to run crossplane in production without creating a new bottleneck

Crossplane’s promise is speed. The risk is a new kind of queue.

InfoQ called out a steep learning curve and debugging pain when compositions or providers misbehave (InfoQ on CNCF graduation). In production, that pain shows up as slow reconciles, noisy events, and teams arguing about who owns what.

Scaling limits show up at “hundreds and thousands”

Crossplane maintainers have tracked performance issues that appear when you reach hundreds and thousands of composite resources. Crossplane still works, but reconciliation takes longer (GitHub issue: test Crossplane at scale).

A CTO should treat that as a capacity planning signal. The platform team needs SLOs for reconciliation, not just “it applied.”

Measure the control plane like a product

Crossplane exposes metrics that map cleanly to user pain. The docs list Upjet metrics like time-to-readiness and external API call counts, plus controller workqueue depth and queue duration (Crossplane metrics guide).

A practical baseline dashboard for a platform team:

• Time-to-readiness (TTR) for key managed resources, track upjet_resource_ttr.
• External API call volume per provider, track upjet_resource_external_api_calls_total.
• Workqueue depth and queue duration for controllers, track workqueue_depth and workqueue_queue_duration_seconds.
• Circuit breaker drops if you hit watch pressure, track circuit_breaker_events_total.

Tie those metrics to developer experience.

If a DatabaseService claim takes 18 minutes to become ready, developers will route around the platform.

Plan upgrades like you plan Kubernetes upgrades

Crossplane publishes release dates and EOL windows in the Go module metadata. v1.19 released Feb 11, 2025 with EOL in Nov 2025, and v1.20 planned for early May 2025 with EOL in Feb 2026 (Crossplane module release table).

A simple enterprise rule:

• Run a supported Crossplane minor at all times.
• Budget one upgrade per quarter.
• Test provider upgrades separately from core upgrades.

Crossplane upgrades are not just “bump a chart.” Provider behavior changes can break compositions.

Real adoption patterns you can copy

Crossplane’s adopters list reads like a platform engineering playbook.

• NASA Science Cloud built compositions to deploy Open Science Studio, a JupyterHub based platform that connects to HPC in the cloud (Crossplane ADOPTERS.md).
• Orange uses Crossplane in production as a core enabler of its platform engineering approach, aiming for simple and consistent services for developers (Crossplane ADOPTERS.md).
• Printbox uses Crossplane for tasks from S3 buckets on AWS to CDN solutions on Google Cloud (Crossplane ADOPTERS.md).

The pattern stays the same. The platform team owns the API and the guardrails. App teams own the request.

Why CTOs care: enterprise implications of crossplane

Crossplane changes your operating model. The tech is the easy part.

1. Internal developer platform scope creep

Crossplane makes it easy to publish new APIs. Platform teams can ship CacheService, QueueService, and DataLakeBucket in a month. Support load is the catch. Every new claim type becomes a product with docs, on-call, and lifecycle work.

If you want a structure for that work, pair Crossplane with our internal guide to platform team charters and boundaries (The Art of CTO) so the team can say no with a clear reason.

2. Multi-cloud control plane becomes real, and political

InfoQ noted enterprises using Crossplane to manage AWS, Azure, and GCP resources from a single Kubernetes cluster (InfoQ on CNCF graduation). That sounds like freedom. Finance and security teams will have questions fast.

A multi-cloud control plane needs:

• A tagging and cost model that works across clouds.
• A shared identity model for provider credentials.
• A clear owner for outages caused by cloud APIs.

Use our Cloud Cost Estimator tool (/tools/cloud-cost-estimator) as part of the platform intake. Require a cost estimate for every new claim type.

3. GitOps for infrastructure becomes auditable, and slower to bypass

AWS published a GitOps model where a central management cluster provisions other EKS clusters and deploys workloads using Argo CD and Crossplane (AWS Containers blog). The audit trail is clean.

The same model forces teams to learn Git workflows for infra changes. Regulated orgs usually like that. Teams used to console clicks won’t.

If you want to cut down bypass behavior, pair the rollout with our guide to engineering metrics and DORA tracking using the Engineering Metrics Dashboard (/tools/engineering-metrics-dashboard). Track lead time and change failure rate before and after.

4. A new failure mode hits incident response

Crossplane failures look like “resource stuck reconciling” and “provider API throttling.” App logs won’t show those failures.

Treat Crossplane like production software. Run incident drills. Use our Incident Postmortem template (/tools/incident-postmortem) for platform incidents, not just app outages.

CTO recommendations: how to adopt crossplane with less pain

Most platform rollouts fail on ownership and pacing, not YAML.

Immediate actions (next 30 days)

1. Pick one claim: ship a single developer-facing API like DatabaseService.

Choose a service with clear guardrails. Postgres works well.

2. Set a readiness SLO: define “claim to ready” targets.

Start with 10 minutes for dev, 20 minutes for prod. Tighten later.

3. Instrument reconciliation: build a dashboard from Crossplane metrics.

Use upjet_resource_ttr and controller workqueue metrics from the Crossplane docs (Crossplane metrics guide).

4. Write a runbook: cover the top five failure cases.

Include provider auth failures, quota errors, and stuck deletions.

Policy framework (what you standardize)

1. API ownership: platform team owns XRDs and compositions.

App teams can request features, but they don’t merge changes without review.

2. Versioning rules: treat claim schemas like product APIs.

Deprecate fields with dates. Publish migration steps.

3. Credential handling: ban raw cloud keys in Git.

AWS’s reference model used Sealed Secrets and stored sealing keys in AWS Secrets Manager (AWS Containers blog). Copy that pattern or use your existing secret system.

4. Support model: define who gets paged.

Crossplane controllers need on-call coverage if developers depend on them.

If you want a place to track that operational load, use Command Center (/command-center) to record incidents, SLOs, and platform capacity.

Architecture principles (how you keep it sane)

1. Thin claims, thick compositions: keep developer APIs small.

Expose intent like size and region. Hide VPC and IAM details.

2. Composition testing: test compositions like code.

Codecentric described building configuration packages and testing compositions with tools like kuttl or Kyverno Chainsaw before shipping (codecentric on ArgoCD and Crossplane).

3. Separate management and workload clusters: keep the control plane stable.

AWS’s model uses a central management cluster to provision other clusters (AWS Containers blog). That separation reduces blast radius.

4. Design for scale early: avoid “one XR per tiny thing.”

Crossplane performance issues show up as you reach hundreds and thousands of XRs (GitHub issue: test Crossplane at scale). Bundle related resources into one composite when it matches your product boundary.

If you want to document those boundaries, model the platform in ArchiMate Modeler (/tools/archimate). A simple capability map helps execs understand what the platform owns.

Bigger picture: crossplane is a people change disguised as YAML

Platform engineering trends point toward internal developer platforms with service catalogs and golden paths. Kubernetes trend reporting calls out Crossplane alongside Backstage and other IDP components, and it ties Crossplane to multi-cluster governance needs in hybrid and edge setups (Jeevi Academy Kubernetes trends).

Crossplane also changes hiring and career paths. A strong platform team starts to look like a product team. The team needs product thinking, docs, and support habits. The team also needs deep Kubernetes controller debugging skills, which are harder to hire for than Terraform.

Crossplane graduation in CNCF signals maturity, but maturity doesn’t remove the learning curve. InfoQ reported debugging friction for early adopters, and that matches what I’ve seen in real rollouts (InfoQ on CNCF graduation).

The question is simple. Will your platform team ship a small set of boring, reliable APIs, or will the team ship a catalog nobody trusts?

Sources

1. Kubernetes Adoption Statistics and Trends for 2025. - Jeevi Academy
2. crossplane module - github.com/crossplane/crossplane - Go Packages
3. Crossplane Reaches Production Maturity by Graduating CNCF - InfoQ
4. crossplane/ADOPTERS.md - GitHub
5. GitOps model for provisioning and bootstrapping Amazon EKS clusters using Crossplane and Argo CD - AWS
6. From Classic CI/CD to GitOps with ArgoCD & Crossplane - codecentric
7. Test Crossplane at scale · Issue #2568 - GitHub
8. Metrics · Crossplane docs