What is kro?

kro (Kube Resource Orchestrator) lets you turn a set of Kubernetes resources into a reusable API. You define the API schema, describe the resources behind it in YAML, and connect them with CEL expressions. kro turns that definition into a CRD, watches for instances of that API, and reconciles the underlying resources for each one.

A ResourceGraphDefinition (RGD) is the blueprint for a custom API: it describes the interface users work with and the resources each instance should produce. kro validates that definition before it ever reconciles an instance, catching schema errors, invalid expressions, and broken references before they become runtime failures.

kro

ConfigMapv1

Buckets3.services.k8s.aws/v1alpha1

Deploymentapps/v1

Servicev1

Autoscalerautoscaling/v2

Ingressnetworking.k8s.io/v1

How it works

A ResourceGraphDefinition has two parts: a schema that defines your API surface (the fields users fill in), and resource templates that reference those fields with CEL expressions. kro parses the expressions, infers the dependency graph, generates a CRD, and stands up a controller - all at runtime.

Users create

apiVersion: kro.run/v1alpha1
kind: WebApp
metadata:
  name: my-app
spec:
  image: nginx
  bucketName: my-app-assets

User sees

apiVersion: kro.run/v1alpha1
kind: WebApp
metadata:
  name: my-app
spec:
  image: nginx
  bucketName: my-app-assets
status:
  bucketArn: arn:aws:s3:::my-app-assets
  endpoint: my-app.example.com

spec:
  schema:
    kind: WebApp
    spec:
      image: string | default=nginx
      replicas: integer | default=1
      bucketName: string | required=true
    status:
      bucketArn: ${bucket.status.arn}
      endpoint: ${service.status.endpoint}

kro creates

ConfigMapv1

Buckets3.services.k8s.aws/v1alpha1

Deploymentapps/v1

Servicev1

spec:
  resources:
    - id: config
      template:
        kind: ConfigMap
        # ...
        name: ${schema.metadata.name}-config
    - id: bucket
      template:
        kind: Bucket
        # ...
        name: ${schema.spec.bucketName}
    - id: deployment
      template:
        kind: Deployment
        # ...
        image: ${schema.spec.image}
        env: ${bucket.status.arn}
    - id: service
      template:
        kind: Service
        # ...
        name: ${deployment.metadata.name}

In practice

Once the definition is installed, users work with the generated API like any other Kubernetes resource.

apiVersion: kro.run/v1alpha1
kind: WebApp
metadata:
  name: my-app
spec:
  image: nginx
  bucketName: my-app-assets

$ kubectl get webapp my-app -o yaml
status:
  bucketArn: arn:aws:s3:::my-app-assets

$ kubectl get configmap,bucket,deploy,svc
NAME                    AGE
configmap/my-app-config 45s

NAME                                       AGE
bucket.s3.services.k8s.aws/my-app-assets   45s

NAME                     READY   AGE
deployment.apps/my-app   1/1     45s

NAME             TYPE        PORT(S)
service/my-app   ClusterIP   80/TCP

Users apply one WebApp. kro creates the ConfigMap, Bucket, Deployment, and Service, and writes useful outputs like bucketArn back onto the same object.

The definition behind it

A ResourceGraphDefinition defines the API under spec.schema (see Simple Schema) and the backing resources under spec.resources. CEL expressions (${}) are what tie those two parts together (this example uses S3 via ACK, but kro works with any Kubernetes resource - native or CRD. For example, Azure Blob Storage via ASO or GCP Cloud Storage via Config Connector).

webapp-rgd.kro

apiVersion: kro.run/v1alpha1
kind: ResourceGraphDefinition
metadata:
  name: webapp
spec:
  schema:
    apiVersion: v1alpha1
    kind: WebApp
    spec:
      image: string | default=nginx
      bucketName: string
    status:
      bucketArn: ${bucket.status.arn}

  resources:
    - id: config
      template:
        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: ${schema.metadata.name}-config
        data:
          APP_NAME: ${schema.metadata.name}

    - id: bucket
      template:
        apiVersion: s3.services.k8s.aws/v1alpha1
        kind: Bucket
        metadata:
          name: ${schema.spec.bucketName}
        spec:
          name: ${schema.spec.bucketName}

    - id: deployment
      template:
        apiVersion: apps/v1
        kind: Deployment
        metadata:
          name: ${schema.metadata.name}
        spec:
          selector:
            matchLabels:
              app: ${schema.metadata.name}
          template:
            metadata:
              labels:
                app: ${schema.metadata.name}
            spec:
              containers:
                - name: app
                  image: ${schema.spec.image}
                  envFrom:
                    - configMapRef:
                        name: ${config.metadata.name}
                  env:
                    - name: BUCKET_ARN
                      value: ${bucket.status.arn}

    - id: service
      template:
        apiVersion: v1
        kind: Service
        metadata:
          name: ${deployment.metadata.name}
        spec:
          selector: ${deployment.spec.selector.matchLabels}

bucket.status.arn does not exist when you apply this definition. kro waits for it before reconciling deployment, and it knows service comes after deployment because the selector is derived from ${deployment.spec.selector.matchLabels}.

What kro handles for you

Once the graph is defined, kro takes care of the mechanics that usually end up in custom controller code.

image: string | default=nginx

replicas: integer | default=1 minimum=0

bucketName: string | required=true

monitoring: boolean | default=false

SimpleSchema

Define your API schema inline — types, defaults, constraints, and validation in a single readable line. No OpenAPI boilerplate.

Schema docs →

Bucket

status.arnarn:aws:s3:::my-bucket

Deployment

env.BUCKET_ARNarn:aws:s3:::my-bucket

Wires data that doesn't exist yet

Reference status fields from resources that haven't been created. kro waits for the data to exist, then wires it into dependent resources.

CEL expressions →

You write (any order)

Service

Bucket

Deployment

kro orders

Bucket

Deployment

Service

Infers ordering from expressions

You never declare resource order. kro reads your CEL expressions and builds the dependency graph automatically.

Dependency ordering →

Deployment

Service

enableMonitoring

ServiceMonitor

AlertRule

Conditional resources

Include or exclude entire subgraphs based on any CEL expression. When a condition is false, the resource and everything that depends on it are skipped.

Conditional resources →

Pod

forEach: ${lists.range(3)}

Pod-0

Pod-1

Pod-2

One template, many resources

forEach expands a single resource template into multiple resources from a list or range. Define once, create N.

Collections →

✓

Always terminates

No infinite loops possible

✓

No side effects

No network calls, no file I/O

✓

Type-checked at apply

Errors caught before anything runs

✓

Auditable

Prove what a definition does

Non-Turing complete by design

CEL always terminates, has no side effects, and is type-checked at apply time. You can prove what your definitions do.

Type checking →

Get started

• Install kro to run the controller in your cluster
• Deploy your first RGD to create a new API end to end
• Browse examples to see more patterns

Need help or want to contribute? Join #kro on Kubernetes Slack, browse GitHub, or read Contributing.