Concepts
Concepts are the building blocks that make Orkestra expressive without being verbose. Each concept is a named abstraction — you declare intent, and Orkestra expands it into the concrete configuration before the runtime starts.
Orkestra Patterns
Every file you write in Orkestra — katalog.yaml, simulate.yaml, komposer.yaml — is an Orkestra Pattern: a versioned, distributable artifact with a specific kind and a specific job. The name reflects something real: these files don’t just describe resources, they encode solutions to recurring problems in the operator world.
Lifecycle
The Lifecycle of an Orkestra pattern is not managed by a separate system — it is a built-in property of the artifact. From creation to deprecation, each stage follows the same production model: write YAML, validate offline, gate with simulate and e2e, push with proof attached. OLM exists because operators were binaries. Orkestra patterns are data.
Profiles
Profiles are named presets that expand into fully-formed configuration at Katalog load time. They cover resources, autoscaling, probes, and security. A profile is a decision made once by someone who thought it through, shared with everyone who shouldn’t have to.
Operator Autoscaler
The Operator Autoscaler is a built-in subsystem that dynamically adjusts an operator’s worker count, queue depth, and resync interval based on runtime metrics, time windows, and cron expressions. Fully declarative. No external controllers.
OperatorBox
CRDs in. Operators out.
The OperatorBox is the fundamental execution unit in the Orkestra runtime. Each CRD declaration in a Katalog becomes one operatorBox — an isolated operator with its own informer, queue, worker pool, and health state. Think containers, but for CRDs.
Dependency Model
The Dependency Model is how Orkestra starts your operators in the right order — automatically. Declare dependsOn in your Katalog. Orkestra builds the graph, waits for missing CRDs, and shuts down in reverse. No code required.
Status Management
Status Management explains how Orkestra writes CR status automatically — and how to extend it. Three layers: automatic Ready conditions, declarative status fields templated from the CR spec, and live child resource state propagated back into status.
Reconciler Model
The Reconciler Model is how a CR becomes a running resource. Orkestra follows 15 ordered steps — from cache read to status patch — every time a CR is created, updated, or deleted.
Ordered Deletion
Ordered Deletion controls the sequence in which child resources are torn down when a CR is deleted. Two models: hard ordered (finalizer held, sequential groups) and condition-based (non-blocking, when:/anyOf: conditions).
Operator of Operators
The Operator of Operators pattern lets one Orkestra operator create Custom Resources that are managed by other operators in the same Katalog — declarative sub-operator composition.
Schema Evolution
Schema Evolution is how Orkestra handles CRD field changes over time — without breaking stored objects, without manual caBundle management, and without a separate conversion webhook deployment. Two approaches: normalize: for single-version input tolerance, conversion.paths: for multi-version APIs.
Typed Operators
Typed Operators are the escape hatch for cases that genuinely need Go code: hooks that run alongside declarative templates, constructors that replace the reconciler entirely, and operator-as-library for full control.
Health Subsystem
The Health Subsystem is Orkestra’s liveness, readiness, and metrics surface. Four Kubernetes-native probe endpoints, per-CRD health tracking, and the /katalog API that powers the Control Center.
Conditionals
Conditionals are the logic layer — when: and anyOf: blocks that control when a resource is created, when a status field is written, and how multi-phase async workflows sequence themselves. Works in Katalogs and Motifs.
ONCOP
ONCOP (Orkestra Native Cross-Operator Protocol) is the cross-binary observation layer. One operator reads another’s typed state — health, metrics, or full CR — without hard-coded URLs, with built-in caching, and with the same template surface as same-binary cross: reads.
Declarative Unit Testing
Declarative Unit Testing is how Orkestra verifies reconciler behavior without a cluster — one simulate.yaml, no Kubernetes, no Docker, sub-second. Declare which resources should appear in which cycle. The same reconciler that runs in production runs here.
→ Read: Declarative Unit Testing
Declarative End-to-End Testing
Declarative E2E is how Orkestra verifies an operator against a real cluster — one YAML file, no test framework, no Go. Every learning example ships with a runnable e2e.yaml. The imports: field composes focused per-Katalog tests into suites that a single ork e2e command runs end to end.