Keel
Automatisiert Aktualisierungen von Container-Workloads.
Keel ist ein Kubernetes-Controller für automatische Container-Image-Aktualisierungen. Er beobachtet ausdrücklich gekennzeichnete Workloads, prüft Container-Registries per Polling oder Ereignis und aktualisiert die Image-Referenz entsprechend der am Workload hinterlegten Policy.
Die wichtigsten Steuerungselemente sind:
- Workload-Annotationen aktivieren Keel gezielt für ein Deployment oder StatefulSet.
- Policy bestimmt, welche Versionsänderung als zulässig gilt.
- Trigger legt fest, ob Polling, Registry-Webhooks oder ein anderer Mechanismus verwendet wird.
- Match Tag ermöglicht die Reaktion auf einen geänderten Imageinhalt unter demselben Tag.
- Approvals und Benachrichtigungen können Updates abhängig von der Keel-Konfiguration begleiten.
Keel in der UDSP
Keel läuft als gemeinsame Betriebskomponente im Operator-Umfeld. Die UDSP aktiviert Registry-Polling im Abstand von fünf Minuten. Nur Workloads mit passenden keel.sh-Annotationen werden beobachtet; eine Installation von Keel aktualisiert nicht automatisch jede Plattformkomponente.
Der aktuelle Plattformcode verwendet diesen Pfad für ausgewählte Workloads, darunter Masterportal, MapFish Print, Docusaurus und den Context Hoster. Dort wird mit match-tag und der Policy force auf neue Imageinhalte unter dem konfigurierten Tag reagiert. Das ist insbesondere bei beweglichen Tags relevant und muss bewusst vom versionsgebundenen Plattformupdate unterschieden werden.
Keel ersetzt weder Kompatibilitätsprüfung noch Datenbankmigration oder kontrolliertes Plattformupgrade. Komponenten mit gemeinsamem Release- oder Migrationsbedarf werden weiterhin über Plattform aktualisieren gesteuert.
Technische Abhängigkeiten
Keel arbeitet als eigenständiger Kubernetes-Controller. Für die Prüfung neuer Imageinhalte benötigt er Zugriff auf die Registries der ausdrücklich freigegebenen Workloads.
Container Registry
Liefert Tags und Image-Metadaten für die durch Keel überwachten Container-Workloads.
Konfiguration und Deployment
inv_op_stack.keel_operator.enable aktiviert Keel. Der Block legt außerdem Namespace sowie Benutzer und Passwort für die interne Approval-Funktion fest. Registry-Service, externer Ingress, Persistenz und Benachrichtigungskanäle sind im aktuellen Plattformprofil deaktiviert.
Die globalen Felder sind in der vollständigen Parameterreferenz der Plattformbasis dokumentiert. Ob Keel einen konkreten Workload beobachten darf, wird nicht im globalen Inventory, sondern durch dessen versionsgebundene Kubernetes-Annotationen bestimmt.
Rollen und Rechte
Keel besitzt keine Keycloak-Rollen. Der Zugriff gliedert sich in Controller- und Approval-Rechte:
Keel Controller
Liest gekennzeichnete Workloads und darf deren freigegebene Container-Image-Referenzen aktualisieren.
Image-Prüfung
Fragt die für beobachtete Workloads benötigten Registry-Informationen über Polling ab.
Approval-Zugang
Verwendet die in der Plattformbasis hinterlegten Basic-Auth-Zugangsdaten, sofern eine Policy eine Freigabe erfordert.
Die Update-Annotationen sind Teil der sicherheits- und releasekritischen Workload-Konfiguration. Eine zu weit gefasste Policy oder ein beweglicher Tag kann ohne erneutes Ansible-Rollout einen neuen Imageinhalt auslösen und muss entsprechend kontrolliert werden.