Not all of it. Kubernetes control planes can give teams a declarative API for requesting infrastructure and can continuously reconcile resources toward their desired state. That makes them useful for specific jobs—especially platform self-service and Kubernetes cluster lifecycle—but it does not make Terraform obsolete. Choose the tool by the resources you need to manage and the operating model your team can support.
What does “control plane” mean here?
The phrase has several meanings. Kubernetes has its own control-plane components; a managed Kubernetes service may operate a cluster control plane for you; and a platform team can build a separate control plane on Kubernetes to manage other software or infrastructure. This article is about that third meaning unless it says otherwise.
As an Amazon Associate I earn from qualifying purchases.
A control plane accepts a description of desired state, observes the current state of a target, and takes action to move the target toward the desired state. In a Kubernetes-based platform, users can submit that intent through the Kubernetes API, while controllers do the ongoing work. This can make infrastructure feel like a platform service rather than a collection of provisioning scripts—but it also means the controllers and their ownership rules become part of your operations.
How does Kubernetes become an infrastructure API?
Custom resources extend the Kubernetes API
A CustomResourceDefinition (CRD) lets a team add a new API group, kind, and schema. The Kubernetes API server can serve and store those custom resources without the team building a separate API server. API aggregation is a different extension mechanism, used when a specialized API server is needed.
#1 Best Overall
This distinction matters for platform design: a team can offer consumers a focused resource such as a database request or environment configuration without exposing every implementation detail. The CRD defines the shape of the request; a controller or control-plane framework supplies the behavior behind it. Kubernetes’ API-extension documentation, updated March 27, 2026, describes these extension mechanisms.
Controllers reconcile declared intent
Crossplane describes a control plane as “software that controls other software.” Its model combines custom APIs, Compositions, and managed resources. A Composition defines how a higher-level API is implemented; managed resources represent external systems such as cloud services. Crossplane’s v2.4 documentation says that if software drifts from desired state, the control plane automatically corrects it.
Rank #2
Google Cloud’s guidance describes Crossplane as a Kubernetes controller that watches external resource state and enforces the declared configuration. If an outside change modifies or deletes a managed resource, the documented behavior is to reverse the change or recreate the resource. That is a different feedback loop from an operator reviewing a proposed change with a plan before applying it.
Continuous reconciliation is not automatically safer. Before enabling it, decide which system owns each resource and what should happen after a console edit, emergency change, or deletion. Otherwise, an operator may make a change that a controller promptly undoes—or two systems may repeatedly compete over the same settings.
Which tool fits which infrastructure job?
| Approach | Primary scope | How it handles desired state | Good fit |
|---|---|---|---|
| Terraform | Infrastructure defined and managed with reusable configuration; its Kubernetes provider can also manage Kubernetes resources. | A plan can show proposed changes and differences for review as part of an operator-directed lifecycle workflow. | Teams that want to keep an established configuration and plan-based workflow, including for Google Cloud infrastructure. Google Cloud’s guidance recommends Terraform generally for code-based management while also describing Kubernetes-based options. |
| Crossplane | Custom Kubernetes APIs and control planes for cloud-native software and external resources. | Controllers observe managed resources and reconcile them toward the state declared through the Kubernetes API. | Platform teams that want Kubernetes API-based self-service and ongoing reconciliation, and are prepared to operate the controllers and define clear ownership. |
| Cluster API | Kubernetes cluster lifecycle: declarative cluster creation, scaling, upgrades, and deletion across supported providers. | Kubernetes-style APIs and controllers manage the lifecycle of clusters and related components within the provider’s contract. | Teams whose specific problem is managing Kubernetes clusters. Cluster API is not a general-purpose manager for unrelated cloud infrastructure. |
| Config Controller / Config Connector | Google Cloud resource management through Kubernetes tooling and APIs. | Uses Kubernetes-oriented APIs and controllers for Google Cloud resources. | Organizations already working in Google Cloud that want to assess its Kubernetes-based management options alongside Terraform. |
These approaches overlap, but they do not have the same job description. Cluster API’s provider contract says its ControlPlane resource exists to instantiate a Kubernetes control plane; that does not mean it is a platform for managing every cloud resource. Crossplane is broader in its aim of building APIs that control software and external infrastructure. Terraform remains a documented option for provisioning and managing infrastructure, and its Kubernetes provider gives teams a way to manage Kubernetes objects without turning every workflow into a controller-based platform.
How should you choose a migration boundary?
Compare the options against the work you actually need to do, rather than asking which tool is universally best.
- Scope: Is the target a Kubernetes cluster, a cloud resource, a Kubernetes object, or a consumer-facing platform API?
- Desired-state interface: Do operators and developers need a configuration workflow, or would a Kubernetes custom resource be a more natural request interface?
- Drift response: Should a difference be surfaced for a person to review, or should a controller continually try to correct it?
- Lifecycle coverage: Does the chosen provider support the create, update, delete, scale, or upgrade operations your resource requires?
- Provider and API maturity: Check the specific provider and API contract for your environment. Do not infer universal coverage from support for one resource or provider.
- Operational dependencies: Account for the management cluster, controller upgrades, credentials and secrets, state handling, and recovery procedures the design requires. The cited documentation does not establish comparative cost or performance.
- Existing ownership: Identify which system currently controls each resource and its fields before adding another writer.
For example, an organization may keep Terraform for foundational cloud infrastructure, use Cluster API for Kubernetes cluster lifecycle, and expose a small set of Crossplane-backed APIs for developer self-service. That is a possible division of responsibilities, not a requirement to combine the tools. Any overlap needs an explicit ownership model.
Free tools Windows power users keep installed
One-click scans. No signup required.
How can you modernize IaC without moving everything?
- Inventory ownership. For each resource in scope, record whether its current authority is Terraform state, a Kubernetes API and controller, a cloud console or API, or a managed cloud service. Note who is allowed to change it and how changes are reviewed.
- Pick one bounded use case. Separate cluster lifecycle from cloud-resource self-service and application deployment. Consider Cluster API for the first, Crossplane for an API-driven infrastructure or platform use case, and Terraform where its existing workflow remains appropriate.
- Design around the consumer. If using Crossplane, expose a focused platform API with only the choices consumers need. Keep implementation details behind the Composition rather than asking every user to assemble low-level managed resources.
- Define drift and out-of-band-change behavior. Decide whether an external edit should be overwritten, restored, or handled through a documented ownership transfer. Test the result in a non-production scope so operators understand the control loop before it governs critical resources.
- Expand in stages. Move only the selected resource class or lifecycle responsibility, then review the provider support, operational burden, and team handoffs before widening the boundary. Cluster API explicitly describes staged adoption of portions of its APIs for existing lifecycle products; the same incremental principle helps limit disruption elsewhere.
What should you verify before adopting a Kubernetes-based control plane?
- Resource ownership is unambiguous. Two reconcilers should not both be authoritative for the same fields unless their responsibilities are deliberately separated.
- Failure and recovery are understood. Determine how the platform behaves if the management cluster or a controller is unavailable, credentials expire, or an upgrade changes behavior.
- Provider capabilities match the lifecycle. Confirm that the provider supports the target resource and the operations you need, including deletion and recovery—not only initial creation.
- Consumers need the API being built. A custom resource is useful when it creates a better, safer interface. It is not a benefit by itself if it merely wraps a configuration workflow without improving access, guardrails, or operations.
- Feature maturity is acceptable. Crossplane Operations are marked alpha in the v2 documentation; do not treat that feature as production-mature based solely on its presence in the docs.
The documentation versions and dates matter when evaluating details: the Crossplane pages cited here are for v2.4, and the reviewed Cluster API provider contract is labeled v1beta2. Verify the current provider contract and release documentation for your intended deployment before implementation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
