11 Enterprise Betrieb, Runbooks und Checklisten
Enterprise-Betrieb bedeutet: Limits, Quotas, Updates, Backups, Monitoring, Security, Incident-Prozess, Kostenkontrolle und reproduzierbare Änderungen. OpenShift ist Plattformbetrieb, nicht nur Deployment-Ziel.
Betriebsmodell
Ein stabiler Cluster braucht klare Verantwortlichkeiten: Plattformteam, Security, Netzwerk, Storage, App-Teams und Incident Management.
Jede Anwendung braucht Mindestartefakte: README, Runbook, Ownership, SLO, Health Checks, Ressourcenlimits, Rollback-Anleitung und Datenklassifikation.
Checkliste vor Produktion
Readiness/Liveness korrekt.
Requests/Limits gesetzt.
SCC/RBAC minimal.
Config/Secrets getrennt.
Route TLS sauber.
Monitoring und Alerting vorhanden.
Backup/Restore getestet.
Rollback getestet.
GitOps-Diff nachvollziehbar.
Kosten und Kapazität
CPU-Limits sind nicht immer sinnvoll für jede Java-App, aber Requests sind Pflicht für planbares Scheduling.
Memory-Limits müssen mit JVM-Einstellungen zusammenpassen.
Horizontal Pod Autoscaling braucht sinnvolle Metriken.
Stateful Workloads brauchen gesonderte Planung für IOPS, Backup und Restore.
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
BASH
# Schnelle Diagnose
oc get clusterversion
oc get co
oc get nodes
oc adm top nodes
oc get events -A --sort-by=.lastTimestamp | tail -80
# Anwendung prüfen
oc -n shop get deploy,rs,pod,svc,route
oc -n shop describe pod -l app=order-api
oc -n shop logs deploy/order-api --since=30m
oc -n shop rollout status deploy/order-api
# Rollback
oc -n shop rollout undo deploy/order-api
oc -n shop rollout status deploy/order-api
YAML
apiVersion: v1
kind: ResourceQuota
metadata:
name: shop-quota
spec:
hard:
requests.cpu: "8"
requests.memory: 16Gi
limits.memory: 32Gi
pods: "80"
---
apiVersion: v1
kind: LimitRange
metadata:
name: default-container-limits
spec:
limits:
- type: Container
defaultRequest:
cpu: 100m
memory: 256Mi
default:
memory: 512Mi
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
Erstelle ein Produktionsfreigabe-Runbook für order-api mit SLO, Alarmen, Rollback, bekannten Fehlerbildern und Ansprechpartnern.
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.