Nimendra's Notes 🪴

Kro (Kube Resource Orchestrator)

7 min read

platformengineering/kro platformengineering

Core Idea

Kro is a namespace-scoped meta-controller that glues Kubernetes resources and third-party operators into one simple custom API, backed jointly by AWS, Google, and Microsoft.

  • Core concepts: the ResourceGroupDefinition, automatic OpenAPI v3 translation, CEL expression logic, and a DAG engine for dependency resolution.
  • A practical execution and self-healing loop with drift correction.
  • Deep comparison against Crossplane with key trade-offs, plus function-kro as the convergence point.

1. Introduction to Kro

Kro (Kube Resource Orchestrator) is an open-source, namespace-scoped meta-controller and orchestrator designed to run natively within Kubernetes. Rather than functioning as a direct infrastructure-provisioning tool, Kro acts as an “all-purpose glue” that binds existing Kubernetes resources, third-party operators (such as AWS ACK, Azure ASO, GCP KCC), and native applications into simplified, custom API endpoints.

Project Milestones & Evolution

  • November 2024: Originally developed and open-sourced by AWS at KubeCon.
  • January 2025: Google and Microsoft joined the steering committee, making Kro a collaborative multi-cloud open-source project backed by the three major hyperscalers.
  • September 2025: Kro transitioned into a Kubernetes Special Interest Group (SIG) Cloud Provider subproject, positioning it as an eventual native core capability of the Kubernetes control plane.

2. Core Architectural Concepts

Kro’s internal architecture is designed around declaratively wrapping complex resource collections into highly abstracted, user-facing Custom Resource Definitions (CRDs).

A. The ResourceGroupDefinition (RGD)

The core Custom Resource (CR) in Kro is the ResourceGroupDefinition. Platform teams author an RGD to define:

  1. The Schema: A simplified representation of the API that end-users (developers) will interact with.
  2. The Resources: A list of underlying resources (deployments, services, cloud databases, etc.) that should be instantiated, configured, and bound together whenever a developer invokes the custom API.

B. Automated OpenAPI v3 Translation

Writing raw OpenAPI v3 schemas for custom Kubernetes resources is highly verbose and error-prone. Kro dramatically simplifies this by taking a user-friendly, high-level structural schema defined inside an RGD and automatically translating it into valid, compliant OpenAPI v3 schemas under the hood, registering the newly minted CRDs dynamically.

C. Logic and Expression Evaluation via CEL

Kro eschews imperative logic engines or turning YAML into an unreadable programming language. Instead, it utilizes Common Expression Language (CEL), a fast, type-safe, non-Turing-complete evaluation engine native to Kubernetes. CEL is used to:

  • Handle field validations (e.g., verifying port ranges or naming conventions).
  • Evaluate runtime conditional exclusions (e.g., executing include when checks to see if an optional resource should be provisioned).
  • Pass dynamic parameters and map output variables from one resource to the inputs of another.

D. Mathematical Dependency Resolution (DAG Engine)

Kro does not require the author to manually script the ordering of resources. It features a built-in compiler that automatically reads resource configurations, extracts CEL-based variable dependencies, and constructs a Directed Acyclic Graph (DAG) to orchestrate execution.

The dependency ordering within Kro is mathematically modeled as:

Where:

  • represents the set of vertices (the individual Kubernetes or cloud resources to be provisioned, such as a VPC, a DB instance, or an App Deployment).
  • represents the set of directed edges, where a directed edge pointing from to indicates that resource must be fully reconciled and have its output variables populated in the cluster status before resource can begin instantiation.

Through this topological sort, Kro ensures that resources are provisioned in the exact logical order required without manual step-by-step pipeline configurations.

3. Practical Execution & Self-Healing Loop

Kro runs on the standard Kubernetes reconciliation loop pattern:

  +------------------+
  |  Desired State   | <---+ (Declared in Custom Resource)
  +------------------+     |
           |               |
           v               | Continuous
    [ Reconciliation ]     | Observation
           v               | & Adjustment
  +------------------+     |
  |  Current State   | ----+ (Actual state of Cluster/Cloud)
  +------------------+
  1. Observe: The Kro controller monitors instances of the generated custom APIs.
  2. Analyze: It evaluates the state of the child resources mapped in the DAG against the declared parent specification.
  3. Act: It creates, updates, or deletes child resources as needed.

Self-Healing & Drift Correction

Because Kro integrates directly into the control plane’s control loop, it provides native self-healing. If an external entity (or an out-of-band pipeline) modifies or deletes a child resource orchestrated by Kro (such as an AWS RDS database instance managed via an ACK operator), Kro detects the drift and automatically regenerates or corrects the resource to match the desired state declared in the parent CR.

4. Deep Architectural Comparison: Kro vs. Crossplane

While both Kro and Crossplane solve the problem of abstracting infrastructure for developers, their underlying architectures and operational scopes are fundamentally different.

Feature / DimensionKro (Kube Resource Orchestrator)Crossplane
Philosophical Focus”All-purpose glue” and meta-controller for existing cluster operators and native resources.Universal Cloud Control Plane aimed at replacing traditional Infrastructure as Code (IaC) tools.
Multitenancy & ScopeNamespace-scoped by design. Perfectly isolated to target development/ephemeral environments.Historically Cluster-scoped. Controls global organizational cloud spaces (though supports Claims).
Infrastructure BindingAgnostic. Relies completely on pre-installed operators in the cluster (ACK, ASO, KCC, etc.).Uses its own massive ecosystem of native “Providers” to connect directly to external cloud APIs.
Logic & TemplatingStrict declarative YAML paired with Common Expression Language (CEL).Highly customizable; supports code-based “Functions” (Go, Python, KCL, Cue).
Dependency ResolutionAutomatic DAG calculation via topological sorting of CEL parameters.Explicit manual schema patching, mapping transforms, or custom function code.
Resource UpgradesLightweight; abstracts OpenAPI generation cleanly for rapid iterative development.Heavyweight enterprise capabilities, including CompositionRevisions for safe API rollouts.

Key Trade-Offs

Why Choose Kro?

  • Simplicity: If you already have operators running in your cluster (like ACK for AWS or standard app controllers), Kro allows you to tie them together into simplified developer-facing APIs with clean YAML and CEL expressions.
  • Low Overhead: No complex programming language dependencies are required to run advanced abstractions.
  • Dynamic Environments: Because it is namespace-scoped, it is incredibly fast and secure to deploy in dynamic, ephemeral test namespaces (e.g., Pull Request preview environments).

Why Choose Crossplane?

  • Cloud-First Architecture: Crossplane does not require third-party Kubernetes operators; its providers map directly to cloud APIs, allowing you to orchestrate non-Kubernetes cloud structures at a massive enterprise scale.
  • Unlimited Programming Logic: By leveraging Crossplane Functions, you are not bound to declarative YAML limits. You can write your composition logic in Go or Python, handling highly complex enterprise branching and API calculations.
  • Blast-Radius Management: Enterprise control mechanisms like composition revisions allow platform teams to safely roll out changes to their infrastructure APIs without risking global control plane drift or downtime.

5. The Great Convergence: function-kro

The distinction between Kro and Crossplane is no longer a strict binary choice. With the release of function-kro, the Crossplane community integrated Kro’s parsing engine directly into Crossplane’s pipeline architecture.

+--------------------------------------------------------+
|                      CROSSPLANE                        |
|                                                        |
|   [ Enterprise Control Plane ] -> [ Composition Run ]  |
|                                           |            |
|                                           v            |
|                                  +-----------------+   |
|                                  |  function-kro   |   |
|                                  |                 |   |
|                                  |  - DAG Engine   |   |
|                                  |  - CEL Parser   |   |
|                                  +-----------------+   |
+--------------------------------------------------------+

How It Works:

Instead of choosing between Kro’s simplicity and Crossplane’s enterprise reach, platform engineers can use function-kro inside a Crossplane Composition.

  • Authors write clean, human-friendly Kro-style syntax using ResourceGraphDefinitions (RGDs) and CEL expressions.
  • Crossplane executes this design step via its high-performance runtime loop.
  • The platform gains the best of both worlds: the clean authoring, topological DAG execution, and safety of Kro, combined with the massive provider ecosystem, global scale, and revision management of Crossplane.

Graph View