6 Architekturüberblick

Die einfache Antwort: OpenShift ist wie eine gut organisierte Stadt gebaut. Es gibt ein Rathaus (Control Plane), das alles steuert, Wohnviertel (Worker Nodes), wo die Anwendungen leben, und eine Infrastruktur (Netzwerk, Storage), die alles miteinander verbindet.

6.1 Das große Bild verstehen

OpenShift folgt einem bewährten Architekturprinzip: Trennung von Steuerung und Ausführung. Die Steuerungslogik läuft getrennt von den eigentlichen Anwendungen. Das macht das System robust - wenn eine Anwendung abstürzt, funktioniert die Steuerung weiter, und umgekehrt.

6.1.1 Die drei Hauptebenen

Control Plane (das Gehirn) Hier laufen alle Steuerungskomponenten. Sie entscheiden, wo neue Anwendungen gestartet werden, überwachen den Systemzustand und reagieren auf Probleme. Denken Sie an das Gehirn eines Organismus - es koordiniert alles, führt aber keine “Arbeit” aus.

Compute Nodes (die Arbeiter)
Das sind die Server, auf denen Ihre Anwendungen tatsächlich laufen. Sie führen Container aus, stellen Ressourcen bereit und melden ihren Status an die Control Plane. Wie die Arbeiter in einer Fabrik - sie erledigen die eigentliche Arbeit.

Infrastructure Nodes (die Servicekräfte) Optional gibt es noch spezielle Nodes für Plattform-Services wie Monitoring oder Logging. Diese laufen getrennt von Ihren Anwendungen, damit sie sich nicht gegenseitig beeinflussen.

6.2 Das Control Plane im Detail

Das Control Plane ist wie das Rathaus einer Stadt - verschiedene Abteilungen arbeiten zusammen, um alles am Laufen zu halten.

6.2.1 Die wichtigsten Komponenten

API Server (der Empfang) Alle Anfragen laufen hier zusammen. Ob Sie eine neue Anwendung starten oder den Status abfragen - alles geht über den API Server. Er prüft, ob Sie die Berechtigung haben und leitet Ihre Anfrage weiter.

etcd (das Archiv) Hier wird der komplette Zustand des Clusters gespeichert. Welche Anwendungen sollen laufen? Welche User haben welche Berechtigungen? etcd ist wie das Stadtarchiv - alles Wichtige wird hier dokumentiert und ist auch bei Stromausfall sicher.

Controller Manager (der Hausmeister) Er überwacht ständig: “Soll ich 3 Kopien dieser App haben? Laufen wirklich 3?” Falls nicht, startet er automatisch neue oder stoppt überzählige. Wie ein Hausmeister, der regelmäßig kontrolliert und repariert.

Scheduler (der Personalchef) Wenn eine neue Anwendung gestartet werden soll, entscheidet der Scheduler, auf welchem Worker Node sie läuft. Er berücksichtigt dabei verfügbare Ressourcen, spezielle Anforderungen und versucht, die Last gleichmäßig zu verteilen.

6.2.2 OpenShift-Erweiterungen

OpenShift fügt zusätzliche Controller für Build-Prozesse, Image-Verwaltung und Deployments hinzu. Diese erweitern Kubernetes um Enterprise-Features, ohne die Grundarchitektur zu verändern.

6.3 Netzwerk: Wie alles miteinander spricht

OpenShift baut ein virtuelles Netzwerk auf, das alle Container miteinander verbindet - auch wenn sie auf verschiedenen Servern laufen. Das ist wie ein unsichtbares Kabelnetzwerk, das jede Wohnung in der Stadt erreicht.

6.3.1 Die Netzwerk-Ebenen

Pod-Netzwerk Jeder Container bekommt eine eigene IP-Adresse und kann mit jedem anderen Container sprechen. Das funktioniert automatisch, auch über Server-Grenzen hinweg.

Service-Netzwerk
Services sind wie Telefonzentralen - sie leiten Anfragen an die richtige Anwendung weiter, auch wenn diese auf verschiedene Server verteilt ist. Anwendungen müssen sich keine konkreten IP-Adressen merken.

Ingress-Netzwerk Hier kommen Anfragen von außen rein. Routes in OpenShift sind wie Wegweiser, die externe Besucher zur richtigen Anwendung führen.

6.3.2 Network Policies: Die Sicherheitskontrolle

Network Policies sind wie Sicherheitskräfte an den Eingängen - sie kontrollieren, wer mit wem sprechen darf. Standardmäßig kann jede Anwendung mit jeder anderen sprechen, aber Sie können das einschränken.

6.4 Storage: Wo die Daten leben

Container sind standardmäßig vergänglich - wenn sie neu starten, sind alle Daten weg. Für dauerhafte Daten braucht man Storage.

6.4.1 Persistent Volumes

Das sind wie Lagerräume, die unabhängig von den Anwendungen existieren. Auch wenn die Anwendung neu startet oder auf einen anderen Server wechselt, bleiben die Daten erhalten.

6.4.2 Storage Classes

Verschiedene Arten von Storage für verschiedene Bedürfnisse - wie verschiedene Lagerraum-Typen. Schneller SSD-Storage für Datenbanken, günstiger Archiv-Storage für Backups.

6.4.3 Dynamische Bereitstellung

OpenShift kann automatisch Storage erstellen, wenn eine Anwendung ihn braucht. Wie ein Hotel, das automatisch zusätzliche Zimmer bereitstellt, wenn Gäste kommen.

6.5 Sicherheit: Schutz auf allen Ebenen

OpenShift implementiert ein Defense in Depth-Prinzip - mehrere Sicherheitsebenen schützen das System.

6.5.1 Security Context Constraints (SCCs)

Das sind die Hausregeln für Container. Sie definieren, was Container dürfen und was nicht - zum Beispiel ob sie als privilegierter User laufen dürfen oder auf Host-Ressourcen zugreifen können.

6.5.2 Role-Based Access Control (RBAC)

Wie ein Berechtigungssystem in einem Unternehmen. Jeder User und jede Anwendung bekommt nur die Rechte, die sie wirklich braucht. Ein Entwickler kann seine eigenen Anwendungen verwalten, aber nicht die Cluster-Konfiguration ändern.

6.5.3 Isolation durch Namespaces

Projekte in OpenShift sind wie separate Abteilungen in einem Gebäude. Sie teilen sich die Infrastruktur, sind aber voneinander getrennt. Eine Anwendung in Projekt A kann normalerweise nicht auf Ressourcen in Projekt B zugreifen.

6.6 Hochverfügbarkeit: Wenn etwas ausfällt

OpenShift ist darauf ausgelegt, dass Komponenten ausfallen können, ohne dass das gesamte System stillsteht.

6.6.1 Redundanz in der Control Plane

Die Control Plane-Komponenten laufen auf mehreren Servern. Wenn einer ausfällt, übernehmen die anderen. Das ist wie ein Rathaus mit mehreren Standorten - wenn einer nicht erreichbar ist, funktioniert der andere weiter.

6.6.2 Automatische Wiederherstellung

Wenn eine Anwendung abstürzt, startet OpenShift automatisch eine neue Instanz. Wenn ein ganzer Server ausfällt, werden die Anwendungen auf anderen Servern neu gestartet.

6.6.3 Load Balancing

Traffic wird automatisch auf verfügbare Instanzen verteilt. Wenn eine Instanz überlastet ist oder ausfällt, bekommen die anderen mehr Anfragen.

6.7 Monitoring und Logging: Den Überblick behalten

OpenShift bringt ein komplettes Monitoring-System mit, das Ihnen zeigt, was in Ihrem Cluster passiert.

6.7.1 Metriken mit Prometheus

Prometheus sammelt ständig Zahlen - wie viel CPU verwenden die Anwendungen? Wie viele Requests kommen rein? Wie viel Speicher ist noch frei? Diese Daten werden in Grafana-Dashboards visualisiert.

6.7.2 Zentrales Logging

Alle Log-Nachrichten von allen Anwendungen werden gesammelt und an einem zentralen Ort gespeichert. Das macht die Fehlersuche viel einfacher - Sie müssen nicht auf einzelne Server schauen, sondern können alles an einer Stelle durchsuchen.

6.7.3 Alerting

Das System kann Sie automatisch benachrichtigen, wenn etwas schiefläuft. Wie ein Rauchmelder - er schlägt Alarm, bevor das Haus abbrennt.

6.8 Skalierung: Wachsen mit den Anforderungen

OpenShift kann sowohl horizontal (mehr Instanzen) als auch vertikal (größere Instanzen) skalieren.

6.8.1 Horizontal Pod Autoscaler

Wenn mehr Traffic kommt, startet OpenShift automatisch zusätzliche Instanzen Ihrer Anwendung. Wenn der Traffic abnimmt, werden überflüssige Instanzen wieder gestoppt.

6.8.2 Cluster-Skalierung

Auch die Worker Nodes können dynamisch hinzugefügt oder entfernt werden. In Cloud-Umgebungen kann das sogar vollautomatisch passieren.