OpenShift Core / Kubernetes · Stand 2026-07-07

01 Architektur: Control Plane, Worker, Operators

Die Control Plane steuert den Clusterzustand; Worker Nodes führen Pods aus. Cluster Operators und der Cluster Version Operator halten OpenShift-Komponenten installiert, aktuell und überwacht.

Diagramm zu 01 Architektur: Control Plane, Worker, Operators
Kompakte fachliche und technische Darstellung.

Fachliche Erklärung

Stelle dir OpenShift wie eine Fabrikhalle vor: Die Control Plane ist die Produktionssteuerung, Worker Nodes sind Maschinen, und Operators sind spezialisierte Wartungsroboter.

Ein Entwickler beschreibt nur: drei Instanzen order-api, Service, Route, Secret. Die Plattform sorgt für Scheduling, Rollout, Neustart, Health Checks und Netzwerk.

Technische Bausteine

API Server: zentrale Schnittstelle für oc, Console, Controller und Operators.

etcd: konsistenter Zustandsspeicher der Cluster-Konfiguration.

Scheduler: ordnet Pods passenden Nodes zu.

Kubelet/CRI-O: startet Container auf Nodes.

Cluster Operators: verwalten OpenShift-Komponenten wie Ingress, Monitoring, DNS, Authentication oder Image Registry.

Enterprise-Konsequenz

Nicht jeder Ausfall ist ein App-Problem. Wenn Cluster Operators degradieren, kann die Plattform selbst betroffen sein.

Für Betriebsteams ist oc get co oft wichtiger als ein einzelnes Pod-Log, weil es den Zustand zentraler Plattformdienste sichtbar macht.

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

  1. Kunde bestellt über Portal.
  2. order-api validiert Auftrag.
  3. billing-api erzeugt Rechnung.
  4. payment-api prüft Zahlung.
  5. Events informieren Lager und Reporting.

Technischer Ablauf

  1. Route nimmt HTTPS an.
  2. Service verteilt auf Pods.
  3. Pods lesen ConfigMaps und Secrets.
  4. Readiness schützt Rollout.
  5. Monitoring misst Fehlerquote und Latenz.

Konfigurations- und Codebeispiele

BASH

oc get clusterversion
oc get clusteroperators
oc get nodes -o wide
oc adm top nodes
oc describe clusterversion version

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

Simuliere eine Betriebsübergabe: Welche Metriken, Logs und Statuskommandos brauchst du, um zwischen App-Fehler, Node-Fehler und Cluster-Operator-Problem zu unterscheiden?

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.