Platform engineering has long relied on custom controllers that wire a Deployment, Service, ConfigMap, and similar objects together. Each controller repeats the same pattern: create resources in order, copy a field from one status into another, and expose a tiny API for application teams. The new change is the adoption of the Kube Resource Orchestrator (kro), which moves that wiring logic into declarative data called a ResourceGraphDefinition and runs it with a single shared controller.
Why the Repeated Controllers Problem Exists
Kubernetes already supplies the primitives needed for building higher‑level abstractions: Custom Resource Definitions (CRDs), controllers, server‑side apply, CEL expression evaluation, and OpenAPI schemas. What it does not provide is a built‑in recipe that describes how several resources belong together, how values flow between them, or when one resource is ready for the next. Because of that gap, every tool—Helm, Argo CD, Crossplane, hand‑coded operators—adds its own mechanism for ordering, readiness checks, or per‑field ownership. The result is a proliferation of similar controllers, each with its own codebase, upgrade path, and on‑call responsibility.
How kro Replaces Them
kro splits the traditional controller into two parts. The composition describes a template of resources and the CEL expressions that reference fields across those resources. From those references, kro automatically derives a dependency graph, so ordering is inferred rather than declared. The API is a standard CRD generated from a schema that application teams use with kubectl, RBAC, and GitOps pipelines. A ResourceGraphDefinition bundles both halves, and a single kro controller interprets any number of definitions. Ten separate glue controllers become ten definitions handled by one controller.
Because the dependency graph is built from actual field references, there is only one source of truth. Renaming a field or moving a resource automatically updates the inferred order; there is no risk of drift between a declared order and the manifest relationships.
Operational and Security Implications
Moving the wiring logic into declarative data shifts effort from writing code to owning an API. Platform teams must now manage the lifecycle of ResourceGraphDefinition schemas, but they gain safety checks: kro rejects schema changes that would break existing instances unless the author explicitly permits them. This reduces accidental breakage during upgrades.
From an operational standpoint, the number of running controllers drops dramatically, simplifying monitoring, logging, and version management. A single controller also means a single point for applying security hardening, audit logging, and RBAC policies.
Security considerations include the fact that the composition half does not create a new CRD; it merely watches existing resources and creates owned resources as needed. This limits the attack surface to the single kro controller and the standard RBAC mechanisms already in place for the generated CRDs. However, because the controller can read any field referenced in CEL expressions, platform teams should audit those expressions to ensure they do not unintentionally expose sensitive data.
Related CloudNinjas coverage: hands-on guides.
What This Means For Practitioners
Practitioners should evaluate whether their organization maintains multiple custom controllers that only differ in wiring logic. If so, adopting kro can consolidate those controllers, reduce code maintenance, and provide a single, version‑controlled source of truth for resource dependencies. The immediate steps are:
- Identify recurring controller patterns that create a Deployment, Service, and ConfigMap (or similar bundles).
- Model the resource relationships as CEL references and define a
ResourceGraphDefinitionfor each pattern. - Deploy the kro controller from the SIG Cloud Provider repository and retire the hand‑written controllers.
- Review the generated CRDs and ensure RBAC policies reflect the intended access boundaries.
- Monitor the controller’s logs for any schema‑change rejections that indicate unintended breaking changes.
Beyond consolidation, the new Graph primitive—composition without a CRD—offers a lightweight way to react to existing resources, such as automatically generating an Ingress for Services labeled expose=true. Teams can experiment with this pattern for one‑off automation without introducing a new API.
In short, kro provides the missing “recipe” layer for Kubernetes resource orchestration, turning repetitive controller code into reusable, declarative definitions. Engineers should assess the trade‑off between the simplicity of a single controller and the responsibility of managing the declarative definitions it consumes.