00 Überblick und Lernlandkarte
OpenShift ist eine Enterprise-Kubernetes-Plattform: Kubernetes bildet den Orchestrierungs-Kern, OpenShift ergänzt Installer, Cluster-Operatoren, Registry, Routes, Build-Mechanismen, Security-Vorgaben, Web-Konsole und integrierte Betriebsfunktionen.
Fachliches Zielbild
Ein Enterprise-Team will nicht nur Container starten. Es braucht eine wiederholbare Plattform, auf der Entwicklung, Betrieb, Security und Architektur dieselbe Sprache sprechen.
Der wichtigste Denkwechsel: Nicht mehr Server konfigurieren, sondern gewünschten Zustand deklarieren. OpenShift versucht diesen Zustand kontinuierlich herzustellen.
OpenShift in einem Satz
OpenShift ist Kubernetes plus Enterprise-Betriebsmodell: Installation, Updates, Operators, Security, Routing, Registry, Monitoring und Developer Experience werden als Plattformprodukt integriert.
Für Java-Enterprise-Modernisierung ist OpenShift besonders interessant, weil alte EAR/WAR/EJB/SOAP/JMS-Systeme schrittweise in containerisierte Services, Batchjobs und Event-Worker überführt werden können.
Was in diesem Paket getrennt wird
Cluster-Schicht: Control Plane, Worker, Operators, MachineConfig, Updates.
App-Schicht: Deployment, Service, Route, ConfigMap, Secret, PVC, ImageStream.
Delivery-Schicht: BuildConfig/S2I, Tekton Pipelines, GitOps mit Argo CD, Helm/Kustomize.
Betriebs-Schicht: Monitoring, Logging, Service Mesh, Security, Quotas, Runbooks.
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
oc version
oc whoami
oc new-project shop
oc get projects
oc get clusterversion
oc get clusteroperators
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
Lege zuerst ein gedankliches Modell an: Welche Teams dürfen Cluster-Objekte ändern, welche nur Namespaces, und welche Artefakte werden ausschließlich über GitOps ausgeliefert?
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.