06 Operators und Operator Lifecycle Manager
Operators kapseln Betriebswissen als Software. OLM installiert und aktualisiert optionale Add-on-Operators; Cluster Operators halten zentrale OpenShift-Funktionen am Laufen.
Fachliche Erklärung
Ein Operator ist wie ein automatisierter Fachadministrator für eine bestimmte Software: Datenbank, Messaging, Monitoring, Service Mesh oder GitOps.
Er beobachtet Custom Resources und führt Aktionen aus, bis die reale Welt dem gewünschten Zustand entspricht.
OLM Begriffe
CatalogSource: Quelle für verfügbare Operators.
Subscription: gewünschter Operator-Kanal und Installationswunsch.
InstallPlan: konkret geplante Installation oder Aktualisierung.
CSV: ClusterServiceVersion mit Metadaten, Permissions und Status.
OperatorGroup: definiert, in welchen Namespaces ein Operator wirken darf.
Risiko und Governance
Operators können weitreichende Rechte besitzen. Deshalb brauchen sie denselben Review wie Infrastruktur-Code.
InstallPlanApproval Manual ist in regulierten Umgebungen oft sinnvoll, weil Updates bewusst freigegeben werden.
Ausführliches Enterprise-Beispiel
Das Beispiel folgt einer fiktiven Shop-Landschaft mit order-api, billing-api, payment-api, portal-ui, Batch-Export und Messaging. Der Fokus liegt auf sauberem Verständnis statt auf blindem Kopieren.
Fachlicher Ablauf
- Kunde bestellt über Portal.
- order-api validiert Auftrag.
- billing-api erzeugt Rechnung.
- payment-api prüft Zahlung.
- Events informieren Lager und Reporting.
Technischer Ablauf
- Route nimmt HTTPS an.
- Service verteilt auf Pods.
- Pods lesen ConfigMaps und Secrets.
- Readiness schützt Rollout.
- Monitoring misst Fehlerquote und Latenz.
Konfigurations- und Codebeispiele
YAML
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: shop-operators
namespace: shop-operators
spec:
targetNamespaces:
- shop
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: postgresql-operator
namespace: shop-operators
spec:
channel: stable
name: postgresql-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
installPlanApproval: Manual
BASH
oc get catalogsources -n openshift-marketplace
oc get subscriptions -A
oc get installplans -A
oc get csv -A
Typische Fehlerbilder und Diagnose
Pending Pods
Prüfe Ressourcen, Node-Selector, Taints, PVC und Quotas. Nicht sofort am Java-Code suchen.
CrashLoopBackOff
Prüfe Logs des vorherigen Containers, Config/Secrets, Port, JVM Memory und Health Endpoints.
Route erreichbar, App nicht
Prüfe Service-Selector, Endpoints, Readiness, TLS-Termination und NetworkPolicy.
Praxisaufgabe
Bewerte einen Datenbank-Operator: Welche CRDs bringt er, welche Rechte verlangt er, wie laufen Backup, Restore und Version-Upgrade?
Merksätze
- Deklarativer Zustand ist wichtiger als manuelle Serveränderung.
- Security und Betrieb gehören von Anfang an zum Deployment.
- Jede YAML-Datei ist Architekturentscheidung und sollte reviewbar sein.
- Produktionsreife entsteht durch Messbarkeit, Rollback und klare Ownership.