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.
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.
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.