K8s Addons¶
Cluster-Addons sind Katalog-Einträge, die der API erlauben, gewünschte Blocks an einem Kubernetes-Cluster zu abonnieren und über den normalen Block-Rollout zu installieren. Eingeführt mit API 0.32.0.
Schichten¶
| Schicht | Modell | Rolle |
|---|---|---|
| Catalogue | CatalogueApp | Mapping zur Registry-URL des Template-Blocks |
| Catalog | K8sAddon | Defaults, Jinja-Config-Template, Scope, is_default, Reihenfolge, Enforcement |
| Desired State | K8sClusterAddonSubscription | Abonnement am Cluster; Soft-Delete; zugehöriger Instance-Block |
Kein eigener Trigger-BRC pro Addon: Cluster-Reconcile legt/aktualisiert den Block und ein BlockRolloutItem (managed_by=subscription).
Bedienung¶
Im Cluster-Detail gibt es den Tab Addons:
- Available / Subscribe — Addon abonnieren (Version leer = Latest)
- Subscribed / Remove — Abonnement entfernen (Soft-Delete → Uninstall → Cleanup)
- Version-Pin als Textfeld; Status aus
block.installed/installation_status
enforcement=required (Default-Addons): Opt-out wird beim Default-Reconcile wieder entfernt; Löschen nur Superuser.
Config¶
- Addon-
default_block_config_templateund Subscription-block_config_templatejeweils als Jinja rendern (Kontext u. a.k8scluster,addon,subscription) - YAML parsen, deep-merge (Listen werden ersetzt)
- Ergebnis →
Block.config
Adoption¶
Existierende Instance-Blöcke im Cluster-Workspace, die zu einem Addon passen (block.name + Registry-URL, version-agnostisch), werden beim Workspace-Reconcile als Subscription übernommen. API-/Operator-Blöcke werden beim CLI-Import nicht überschrieben.
Conditions (INFO)¶
| Condition | Bedeutung |
|---|---|
K8S_ADDON_VERSION_BEHIND | Pin liegt hinter der Platform-Latest |
K8S_ADDON_RECOMMENDED_MISSING | empfohlenes Addon fehlt |
Sie fließen nicht in WARNING/CRITICAL Object-State ein.
Veraltet¶
Das frühere JSON-Feld K8sCluster.addons / der Sync-Hot-Path sind tot. Neue Deployments laufen über Subscriptions.
Verwandte Themen¶
- Block Rollout
- Vulnerability Management (Catalogue / Products)
- API 0.32.0