Katalog — Orkestra

Katalog is not a Kubernetes CRD

kubectl apply will not work. Orkestra kinds are consumed by the ork CLI and runtime — not by the Kubernetes API server. Your CRD is enough.

A Katalog declares one or more CRDs and defines how Orkestra manages them. It is the unit of operator definition — everything the runtime needs to run an operator from a single YAML file.

Motif     — named inputs + resource blocks. One concern.
    ↓
Katalog   — operator declaration. Imports Motifs. Defines CRDs.
    ↓
Komposer  — platform declaration. Composes Katalogs.
    ↓
E2E       — declarative end-to-end test for a Katalog.

Wire format

apiVersion: orkestra.orkspace.io/v1
kind: Katalog

metadata:
  name: my-operator
  description: string          # optional

spec:
  finalizers:                  # optional — applied to every CRD
    - platform.example.io/cleanup

  crds:                        # required — map of CRD entries by name
    <name>:
      apiTypes:                # GVK declaration
        ...
      operatorBox:             # resource templates and reconcile logic
        ...
      imports:                 # Motif imports
        ...

profiles:                      # optional — user-defined named profiles
  networkPolicies:
    - name: allow-monitoring
      ...
  resourceQuotas:
    - name: team-medium
      ...

security:                      # optional
  ...

notification:                  # optional
  ...

providers:                     # optional
  - ...

Try it

ork init --pack beginner
cd beginner/01-hello-website
ork run

This scaffolds the simplest Katalog — a single CRD that creates a Deployment and Service from a CR apply. The full reference for every field is in the pages below.

Where to go

Page	Covers
01-top-level	Top-level Katalog structure — `metadata`, `spec.finalizers`, `spec.crds`
02-crd-entry	Fields inside `spec.crds.<name>` — enabled, workers, resync, imports
03-apitypes	`apiTypes` — group, kind, version, plural, typed mode
04-operatorbox	`operatorBox` — resource templates, reconciliation strategy
05-status	`status` — fields written to CR status after reconcile
06-when-conditions	`when` / `anyOf` — conditional resource creation
07-validation	`validation` — admission rules
08-mutation	`mutation` — admission defaults and overrides
09-conversion	`conversion` — multi-version CRD support
10-katalog-security	`security` block
11-katalog-notification	`notification` block
12-katalog-providers	`providers` block
16-resource-types	Supported Kubernetes resource types
Profiles concept	`profiles:` — user-defined named profiles
15-enrich	`enrich` — post-reconcile enrichment
16-resource-types	Supported resource types and placeholder fields