OpenShift organisiert seine Funktionalität in verschiedene Kernkomponenten, die zusammen eine vollständige Container-Orchestrierungsplattform bilden. Diese Komponenten implementieren die grundlegenden Kubernetes-Konstrukte und erweitern sie um OpenShift-spezifische Enterprise-Features.
Master Nodes beherbergen die Control Plane-Services, die für die Verwaltung des gesamten Clusters verantwortlich sind. Diese Komponenten arbeiten zusammen, um den gewünschten Cluster-Zustand aufrechtzuerhalten und auf Änderungen zu reagieren.
Der Kubernetes API-Server fungiert als zentraler Kommunikationshub
für alle Cluster-Operationen. Er authentifiziert und autorisiert alle
eingehenden Anfragen und implementiert die RESTful API, über die sowohl
interne Komponenten als auch externe Clients mit dem Cluster
interagieren. Alle oc und kubectl Befehle
werden über den API Server verarbeitet.
etcd stellt eine verteilte Key-Value-Datenbank zur Verfügung, die den aktuellen Zustand aller Cluster-Ressourcen speichert. Diese Komponente gewährleistet Datenkonsistenz auch bei simultanen Änderungen und Ausfällen einzelner Master-Nodes. Der Cluster kann nur korrekt funktionieren, wenn etcd verfügbar und konsistent ist.
Der Controller Manager implementiert verschiedene Control Loops, die kontinuierlich den gewünschten gegen den aktuellen Zustand überwachen. Der Node Controller überwacht die Verfügbarkeit der Worker-Nodes, während der Replication Controller die korrekte Anzahl von Pod-Replikas gewährleistet. Diese reaktiven Komponenten sorgen für selbstheilende Eigenschaften des Clusters.
Der Scheduler analysiert Ressourcenanforderungen neuer Pods und wählt geeignete Worker-Nodes basierend auf verfügbaren Ressourcen, Scheduling-Constraints und Quality-of-Service-Anforderungen aus. Dieser Prozess berücksichtigt Node-Affinity, Anti-Affinity und Taints/Tolerations für optimale Workload-Verteilung.
Worker-Nodes führen die eigentlichen Anwendungs-Workloads aus und implementieren die Container-Runtime-Umgebung. Jeder Worker Node läuft verschiedene System-Services, die für die Pod-Ausführung notwendig sind.
Das Kubelet fungiert als primärer Node-Agent und kommuniziert mit dem API-Server zur Synchronisation des gewünschten Pod-Zustands. Es startet, stoppt und überwacht Container basierend auf Pod-Spezifikationen und berichtet den Node-Status zurück an die Control Plane.
Der Kube-Proxy implementiert Service-Abstraktion durch Load Balancing und Network Address Translation. Er sorgt dafür, dass Service-Anfragen an verfügbare Pod-Endpunkte weitergeleitet werden und gewährleistet dabei die Einhaltung definierter Service-Policies.
Die Container-Runtime (CRI-O in OpenShift) führt Container aus und verwaltet deren Lebenszyklen. Sie implementiert den Container Runtime Interface (CRI) Standard und abstrahiert die Details der Container-Ausführung von den höheren Orchestrierungs-Ebenen.
Das OpenShift Node Service überwacht Node-spezifische Konfigurationen und gewährleistet Compliance mit Cluster-weiten Policies. Es verwaltet Node-Labels und -Annotations für Scheduling-Entscheidungen.
Pods repräsentieren die kleinste deploybare Einheit in OpenShift und kapseln einen oder mehrere Container, die gemeinsame Ressourcen teilen. Container innerhalb eines Pods teilen Netzwerk-Namespace, Storage-Volumes und Lifecycle.
Jeder Pod erhält eine eindeutige IP-Adresse im Cluster-Netzwerk und kann über diese Adresse von anderen Pods erreicht werden. Diese Netzwerk-Isolation gewährleistet, dass Pods unabhängige Netzwerk-Stacks besitzen, während gleichzeitig Service Discovery über DNS funktioniert.
Pod-Spezifikationen definieren Container-Images, Ressourcenanforderungen, Umgebungsvariablen und Volume-Mounts. Diese deklarative Konfiguration ermöglicht reproduzierbare Deployments und vereinfacht Versionskontrolle der Anwendungskonfiguration.
Pods sind ephemere Ressourcen, die von höheren Controllern wie Deployments oder StatefulSets verwaltet werden. Diese Controller gewährleisten gewünschte Pod-Anzahl und implementieren Update-Strategien für Anwendungsversionen.
Services abstrahieren die Kommunikation mit Pod-Kollektionen und bieten stabile Netzwerk-Endpunkte unabhängig von Pod-Lifecycles. Sie lösen das Problem der dynamischen Pod-IP-Adressen durch eine dauerhafte Service-Abstraktion.
ClusterIP Services ermöglichen interne Cluster-Kommunikation über eine virtuelle IP-Adresse, die automatisch auf verfügbare Pod-Endpunkte load-balanced wird. Diese Service-Art ist standardmäßig nur innerhalb des Clusters erreichbar.
NodePort Services erweitern ClusterIP um einen statischen Port auf allen Worker-Nodes, der externen Zugriff auf den Service ermöglicht. Diese Konfiguration eignet sich für Entwicklungs- und Testzwecke, erfordert jedoch externe Load Balancer für produktive Umgebungen.
LoadBalancer Services integrieren mit Cloud-Provider-APIs zur automatischen Bereitstellung externer Load Balancer. Diese Integration ermöglicht native Cloud-Integration ohne manuelle Infrastructure-Konfiguration.
Service Discovery funktioniert über DNS-Namen, die automatisch für
alle Services erstellt werden. Diese DNS-Einträge folgen der Konvention
servicename.namespace.svc.cluster.local und ermöglichen
service-basierte Anwendungsarchitekturen.
Routes sind ein OpenShift-spezifisches Konstrukt, das HTTP/HTTPS-basierten externen Zugriff auf Services ermöglicht. Im Gegensatz zu Kubernetes Ingress bieten Routes erweiterte Funktionalitäten wie automatische TLS-Terminierung und Traffic-Splitting.
Der OpenShift Router implementiert einen HAProxy-basierten Ingress Controller, der eingehende HTTP-Requests basierend auf Host-Namen und Pfaden an entsprechende Services weiterleitet. Diese zentrale Routing-Komponente läuft auf Infrastructure-Nodes und bietet High Availability durch mehrere Instanzen.
Route-Konfigurationen definieren Hostname, Pfad, TLS-Einstellungen und Traffic-Splitting für A/B-Testing. Edge-Terminierung beendet TLS-Verbindungen am Router, während Passthrough-Terminierung verschlüsselte Verbindungen direkt an Backend-Services weiterleitet.
Wildcard-Routes ermöglichen dynamische Subdomain-Erstellung für Multi-Tenant-Anwendungen. Blue-Green-Deployments können über Route-Konfigurationen gesteuert werden, ohne Änderungen an der Anwendung selbst.
Die Hauptkomponenten interagieren über definierte APIs und Protokolle. Master-Komponenten kommunizieren primär über den API-Server, der als einziger Zugriffspunkt auf etcd fungiert. Worker-Nodes verbinden sich ausschließlich zum API-Server und implementieren keine direkte Inter-Node-Kommunikation für Control Plane-Operationen.
Pod-zu-Pod-Kommunikation erfolgt über das Software Defined Network, das Container-zu-Container-Verbindungen über Node-Grenzen hinweg ermöglicht. Services abstrahieren diese Kommunikation und implementieren Load Balancing sowie Service Discovery.
Routes integrieren mit Services zur Bereitstellung externer Konnektivität und nutzen dabei Service-Selektoren zur Identifikation der Backend-Pods. Diese Integration ermöglicht nahtlose Skalierung ohne manuelle Routing-Konfiguration.
Die Komponentenarchitektur gewährleistet Separation of Concerns und ermöglicht unabhängige Skalierung verschiedener Funktionsbereiche. Diese Modularität vereinfacht Wartung, Updates und Troubleshooting der gesamten Plattform.