Kubernetes Operator Pattern as Platform Strategy (2026)

Q: What is the difference between a Kubernetes operator and a Helm chart, and when does the difference matter?

A Helm chart renders manifests from a template and values; whatever reconciliation happens afterwards is done by the core Kubernetes controllers or a GitOps controller re-applying the rendered output. An operator is a running controller that watches a custom resource and continuously converges the actual state of an application toward the declared state, including behaviours no template can express: promoting a database replica on failure, running an upgrade with health checks and rollback, rotating certificates before expiry, coordinating with a system outside the cluster. The difference matters exactly when those behaviours exist. For a stateless service with a fixed set of resources, a chart applied through GitOps reconciles adequately and an operator adds a process to monitor and a CRD to version for no gain. For a database, a broker or anything with a lifecycle state machine, the operator is the only thing that removes the human from the loop.

Q: Should a platform team write custom operators or use kro and Crossplane?

Use kro or Crossplane for the team-facing API layer, and write custom controllers only for operational knowledge that no upstream project encodes. Both kro and Crossplane v2 let you define a higher-level custom resource that expands into a graph of existing resources, including other operators' custom resources, without writing a controller. The underlying operators, for example CloudNativePG for PostgreSQL, keep doing the application-specific reconciliation. A custom controller written with kubebuilder and controller-runtime is the only option when the knowledge is proprietary: a tenant migration procedure, failover of an in-house system, a compliance workflow. It is also the most expensive row in the comparison, because the code, its tests, its RBAC and its compatibility with each Kubernetes minor and each controller-runtime release are yours indefinitely. Choose it deliberately and keep the list short.

Q: What changed in Crossplane v2 and why does it matter for the operator pattern?

Crossplane v2, documented on the project's "What's New in v2" page, made four changes: composite resources are namespaced by default, managed resources are namespaced, a composition can compose any Kubernetes resource rather than only Crossplane resources, and Operations were added for operational workflows. The third change is the one that matters most for platform strategy. Before v2, Crossplane was primarily a way to give cloud infrastructure a Kubernetes-shaped API. After v2 a composition can wrap a database operator's custom resource, a Deployment, network policies and cloud resources into one team-facing resource, which makes it a general-purpose composition layer in the same space as kro. Namespacing also lets you scope RBAC per team instead of granting cluster-wide permissions. Crossplane graduated in the CNCF on 28 October 2025 and v2.4.2 shipped on 22 September 2026, so it is a stable choice; kro, by contrast, states that its API is v1alpha1 and may still change.

Q: What is kro and how does a ResourceGraphDefinition compare to a custom operator?

kro, the Kube Resource Orchestrator, is a kubernetes-sigs project whose single custom resource, the ResourceGraphDefinition, defines a collection of Kubernetes resources, the dependencies between them and the values that flow from one to another using CEL expressions. Applying a ResourceGraphDefinition causes kro to register a new CRD, and instances of that CRD are expanded into the underlying resources and kept in place. Compared to a custom operator, kro gives you the custom API and the recreate-and-propagate reconciliation for free, in YAML, with no Go and no controller to build or release. What it does not give you is application knowledge: kro does not know how to fail over a database or upgrade a broker, so it is a composition layer over controllers that do. Its honest limit as of v0.9.4, released on 4 September 2026, is that the API is v1alpha1 and the maintainers state that breaking changes may still be introduced, so pin versions and plan for migration work.

Q: Why do status conditions matter so much in an operator?

Because conditions are the API's return value. A product team that applies a custom resource has no other contract for finding out whether the platform did what was asked, whether it is healthy, whether an upgrade is in progress or whether a human is needed. A controller that does work and reports nothing trains teams to poll the underlying resources, which exposes the abstraction the operator was meant to hide, and eventually to open tickets, which returns the organisation to the world before the platform existed. Well-designed conditions follow the Kubernetes conventions, reflect the actual state machine including degraded, upgrading, rolling back and failed states, carry reasons and messages a human can act on, and are aggregated upward by composition layers such as kro and Crossplane so the team-facing resource shows one honest status. The Kubebuilder Book devotes a chapter to status because a controller without it has no contract.

Q: What are the most dangerous operator anti-patterns in production?

Three cause the most damage. First, owner-reference deletion surprises: garbage collection through owner references is elegant until a composite resource is deleted and its managed database goes with it; anything holding data needs a deletion policy that defaults to orphan or retain and a finalizer that checks before releasing. Second, requeue storms: a reconciler that retries a failing external call aggressively across hundreds of resources exhausts a cloud API's rate limit and takes provisioning down for every team; use rate-limited workqueues, exponential backoff and per-resource error budgets. Third, reconciling long-lived secrets into the controller: an operator that fetches credentials and writes them into Secrets it owns becomes the fastest path to exfiltrate every credential on the cluster; use short-lived, dynamically issued credentials bound to workload identity and let the operator request rather than store. The common thread is treating the operator as a delivery artefact rather than a running product with a state machine and a security surface.

Q: How should operators themselves be installed and upgraded?

Through a lifecycle manager, not by hand. Operator Lifecycle Manager v1, redesigned after what its documentation calls five years of real-world use of OLM v0 and at v1.12.0 as of 24 September 2026, installs operators from catalogues and manages their upgrades on the cluster, so the software that upgrades everything else has an upgrade path of its own. A GitOps-managed Helm release of the operator is the common alternative and works well if the release process includes upgrade tests across the Kubernetes minor versions you run. What does not work is the pattern where an operator is installed once by a platform engineer, never revisited, and discovered three minor versions later to be using deprecated APIs. Kubernetes ships three minors a year, v1.37.0 on 26 August 2026 being the latest, and controller-runtime tracks them; an operator that is not rebuilt against both falls behind within roughly eighteen months.

Q: How does the operator pattern relate to platform engineering and golden paths?

The operator pattern is one mechanism for delivering a golden path, and it is the mechanism that determines whether the path stays paved. A golden path promises product teams that if they use the platform's abstraction, the platform will keep the thing running. Every element of that promise, failover, backup, upgrade, rotation, drift correction, is a reconciliation behaviour that either an upstream operator, a composition layer or a custom controller has to perform. If the platform ships a template and a CRD without the behaviours, the path is paved for the first mile and gravel afterwards, and adoption stalls when teams hit the first day-two event. This is why the unit of platform delivery should be "operational tasks that no longer need a human" rather than "operators shipped", and why the review question for a new controller is what it does on every path through its state machine, not what fields its CRD exposes.

Q: What is a realistic maturity path for a platform built on operators?

Five stages. Consume: install mature community operators for databases, brokers and caches through OLM v1 or GitOps and learn what good status and upgrade behaviour look like. Compose: define the team-facing API with kro or Crossplane compositions over those operators and core resources, with no custom Go, and measure adoption by how many services are created through the composed API. Encode what only you know: identify the procedures that still need a human and are specific to your business, and write a custom controller for those alone, with a documented state machine, conditions and a deletion policy. Operate the operators: upgrade tests across Kubernetes minors in CI, dependency tracking, per-controller SLOs on reconcile latency and error rate, RBAC review per release, an on-call rotation. Retire: every time an upstream project or composition tool grows a capability you wrote yourself, delete your controller. A healthy platform is measured partly by how much custom reconciliation code it no longer needs.

Satyam Kumar

ブログに戻る

multi-cloud-infrastructure

The Operator Pattern as Platform Strategy: Reconciliation Is the Product, Not the Custom Resource (2026)

By Satyam KumarSeptember 29, 202615 min read

kubernetes operator pattern kubernetes operators platform engineering crossplane v2 crossplane vs kro kro kube resource orchestrator resourcegraphdefinition kubebuilder controller-runtime olm v1 operator lifecycle manager custom resource definitions design reconciliation loop kubernetes when to write a kubernetes operator internal developer platform api platform engineering abstractions cloudnativepg operator kubernetes control plane patterns operator anti-patterns

The Operator Pattern as Platform Strategy: Reconciliation Is the Product, Not the Custom Resource (2026)

Frequently Asked Questions

この記事を共有する

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI＆クラウドアーキテクト。数百万人にスケールするシステム構築を支援。

LinkedIn GitHub

The Operator Pattern as Platform Strategy: Reconciliation Is the Product, Not the Custom Resource (2026)

Frequently Asked Questions

この記事を共有する

Comments

Leave a comment