Skip to content

KRO first: a ResourceGraphDefinition in, child resources out, with nothing in the way — one pod, 128Mi, no packages, no functions, no providers

Artifact — a working KRO ResourceGraphDefinition that a developer consumes by creating one instance of a new kind, and that emits child resources (a Deployment, a Service) — the bare shape "custom resource → controller → children" with no packages, no functions, no providers, no revisions, no OCI protocol between the CR and its children. KRO is taught first deliberately: it shows the mechanism naked, so that Crossplane's extra machinery arrives with a reason to exist rather than as unexplained ceremony.

Rests on — P4's CRD-plus-controller, which is exactly what a ResourceGraphDefinition compiles down to; and the tenancy boundary, the namespace this provisions into.

Topology — platform, continued — Group B.

Read — the module framing and the maturity note: KRO has no CNCF tier of its own (a Kubernetes SIG subproject, v0.9.x, v1alpha1, its central CRD recently renamed from ResourceGroup to ResourceGraphDefinition). It is a contrast exercise, not a production vehicle — which is exactly the role the numbers give it.

Build — install KRO, define a graph, and consume it as a developer would:

helm install kro oci://ghcr.io/kro-run/kro/kro --namespace kro --create-namespace
kubectl top pod -n kro     # 1 pod, ~128Mi — the whole install
# define a new kind whose instance emits a Deployment + Service:
kubectl apply -f webapp-rgd.yaml     # ResourceGraphDefinition: schema in, child template out
# the developer's whole action — one instance of the new kind:
kubectl apply -f - <<'YAML'
apiVersion: kro.run/v1alpha1
kind: WebApp
metadata: {name: shop, namespace: team-a}
spec: {image: shop:2.1, replicas: 2}
YAML
kubectl get deploy,svc -n team-a -l kro.run/owned    # children, emitted by KRO

Verify from outside — the "nothing in the way" claim is checkable by absence: kubectl get pods -n kro is one pod, there is no function pod, no provider pod, no package revision object anywhere. A reader looking for the machinery Crossplane needs finds none of it — that emptiness is the artifact, and it is what makes the Crossplane contrast land.

Expect — a developer creating one WebApp and getting a Deployment and Service, with a single 128Mi controller and zero supporting machinery. This is "custom resource in, children out" with the mechanism visible and nothing hiding it.

Write down — the KRO half of the KRO-vs-Crossplane contrast: what the graph did, and the count of supporting pods (zero beyond the one controller) — the baseline against which Crossplane's cost is measured next.

Footprint note — KRO is 1 pod, 128Mi, the cheapest platform API in the phase; platform barely moves.

Teardown — keep the WebApp instance and KRO for the contrast in the next exercise; delete nothing yet. The topology stays.