Block Rollout¶
Das Block-Rollout-System orchestriert Block-Actions (install, uninstall, …) über viele Workspaces und Cluster hinweg — wellenbasiert, mit Concurrency-Limits, Wartungsfenster-Respekt und Failure-Schwellen.
Es ist die Grundlage für Operator-Updates, Loadbalancer-Deployments und K8sControlplane-Installationen.
Zwei Schichten¶
| Schicht | Aufgabe |
|---|---|
Trigger (BlockRolloutConfig) | Erkennt Bedarf und legt Queue-Einträge an |
| Scheduler | Verarbeitet die Queue in Wellen und startet ActionRuns |
Kernobjekte¶
| Objekt | Bedeutung |
|---|---|
BlockRolloutConfig (BRC) | Regeln: Ziel-Block, Trigger-Art, Concurrency, Wartungsfenster, Config-Template |
BlockRollout | Eine Wave / Gruppe zusammengehöriger Items |
BlockRolloutItem (BRI) | Einzelner Queue-Eintrag: Block + Action + Status |
BRC-Arten¶
kind | Rolle |
|---|---|
trigger | Löst Rollouts aus (Reconciliation oder Cron) |
config | Globale Default-Konfiguration (u. a. Concurrency) |
Wichtige Felder einer Trigger-BRC:
block_name,trigger_type(reconciliation/schedule), optionalcron_expressiontarget_organizations/target_workspaces— Scopeblock_config_template— Jinja2+YAML für Block-Config (Globals u. a.credential_get_or_create,backup_schedule_cron)- Bypass des Wartungsfensters konfigurierbar; manuelle Triggers umgehen das Fenster immer
Item-Status¶
Idempotenz: existiert bereits ein aktives Item für denselben Block, wird kein Duplikat erzeugt. CLI-verwaltete Blöcke können bei Konflikt als skipped markiert werden; ein Block Takeover migriert CLI-Blöcke auf API-/BRC-Management.
Priorität & Wellen¶
- Dispatch priorisiert nach Workspace-Criticality (
highvormediumvorlow). - Waves werden getrennt, wenn Blocks einem Owner gehören (
managed_by) — z. B. Loadbalancer und Controlplane blockieren sich nicht gegenseitig.
Operator & UI¶
- Seeded System-BRC installiert/aktualisiert den Polycrate Operator fleet-weit — siehe Operator-Deployment.
- Dashboard zeigt Zähler: Total = Done + In Progress + Pending + Failed + Skipped.