Die technischen Anforderungen für OpenShift-Installationen variieren erheblich je nach Einsatzszenario und gewählter Architektur. OpenShift als Enterprise-Container-Plattform benötigt substanzielle Systemressourcen, um seine umfangreichen Funktionen bereitzustellen und gleichzeitig Container-Workloads zu unterstützen.
Die Dimensionierung von OpenShift-Umgebungen erfordert eine differenzierte Betrachtung verschiedener Installationstypen. Single-Node-Konfigurationen für Entwicklung und Tests haben andere Anforderungen als produktive Multi-Node-Cluster mit Hochverfügbarkeitsanforderungen.
Single-Node-OpenShift-Installationen, insbesondere OpenShift Local, stellen den einfachsten Einstieg in die Plattform dar. Diese Konfigurationen konsolidieren alle Cluster-Komponenten auf einem einzelnen System und reduzieren dadurch die Komplexität erheblich.
Diese Minimalwerte ermöglichen das grundlegende Starten der Plattform, bieten jedoch nur begrenzte Kapazitäten für Anwendungs-Workloads.
Realistische Entwicklungsumgebungen benötigen erweiterte Ressourcen für produktives Arbeiten. 32 GB RAM ermöglichen das gleichzeitige Ausführen mehrerer Container-Anwendungen ohne Speicher-Constraints. Acht CPU-Kerne bieten ausreichende Rechenleistung für Build-Prozesse und parallele Container-Ausführung. 200 GB Speicherplatz schaffen Raum für Container-Images, Build-Artefakte und persistente Daten.
Storage-Performance: SSD-Speicher verbessert die Performance erheblich, da OpenShift intensive Festplattenzugriffe für Container-Image-Management und etcd-Operationen durchführt. Mechanische Festplatten führen zu spürbaren Verzögerungen bei Container-Starts und Cluster-Operationen.
Virtualisierte Umgebungen müssen Hardware-assisted Virtualization unterstützen, da OpenShift-Komponenten containerisiert ausgeführt werden. Nested Virtualization kann in bestimmten Szenarien erforderlich sein, insbesondere bei der Verwendung von Virtualization-Features wie KubeVirt.
Produktive OpenShift-Cluster bestehen typischerweise aus mehreren spezialisierten Node-Typen mit unterschiedlichen Hardware-Profilen. Master-Nodes übernehmen Kontrollaufgaben, Worker-Nodes führen Anwendungs-Container aus, und Infrastructure-Nodes hosten Plattform-Services.
Master-Nodes erfordern besonders hohe Verfügbarkeit und Performance für Kubernetes-API-Server, etcd-Datenbank und Cluster-Scheduler.
Minimale Konfiguration pro Master-Node: - CPU: 4 Kerne - RAM: 16 GB (für API-Server, etcd, Scheduler) - Storage: 120 GB (bevorzugt lokale SSDs für etcd) - Netzwerk: Niedrige Latenz zwischen Master-Nodes
Hochverfügbarkeits-Architektur: Drei Master-Nodes bilden die Standardkonfiguration für produktive Cluster und ermöglichen Hochverfügbarkeit durch Quorum-basierte Entscheidungen. Gerade Anzahlen von Master-Nodes können zu Split-Brain-Situationen führen und werden nicht empfohlen.
Worker-Nodes variieren stark in ihren Anforderungen abhängig von den geplanten Workloads. Basis-Worker-Nodes beginnen bei 8 GB RAM und zwei CPU-Kernen, können jedoch für rechenintensive Anwendungen deutlich größer dimensioniert werden.
Basis-Konfiguration: - CPU: 2-4 Kerne (Minimum) - RAM: 8 GB (Minimum) - Storage: 120 GB
Typische Produktions-Konfiguration: - CPU: 8-16 Kerne - RAM: 32-64 GB - Storage: 500 GB - 2 TB
Memory-intensive Anwendungen wie Datenbanken oder Analytics-Workloads können Worker-Nodes mit 64 GB oder mehr RAM erfordern.
Infrastructure-Nodes hosten OpenShift-eigene Services wie Image-Registry, Monitoring-Stack und Router getrennt von Anwendungs-Workloads. Diese Nodes benötigen typischerweise 16 GB RAM und vier CPU-Kerne, um die Plattform-Services stabil zu betreiben.
OpenShift unterstützt spezifische Betriebssystem-Distributionen, die für Container-Orchestrierung optimiert sind. Die Auswahl des Betriebssystems beeinflusst Support, Sicherheit und Update-Verfahren erheblich.
Red Hat Enterprise Linux (RHEL) 8 oder 9 stellt die primäre und vollständig unterstützte Betriebssystem-Basis dar. RHEL bietet Enterprise-Support, Sicherheits-Updates und ist für OpenShift-Workloads optimiert. Die Integration zwischen RHEL und OpenShift ermöglicht nahtlose Updates und Patch-Management.
Red Hat CoreOS fungiert als spezialisiertes Container-optimiertes Betriebssystem für OpenShift-Nodes. CoreOS-basierte Installationen nutzen automatische Updates und unveränderliche Betriebssystem-Images. Diese Architektur reduziert Wartungsaufwand und verbessert Sicherheit durch minimale Angriffsfläche.
Fedora CoreOS stellt eine Community-Version von Red Hat CoreOS dar und eignet sich für nicht-produktive Umgebungen. Die gleichen Container-Optimierungen und automatischen Update-Mechanismen sind verfügbar, jedoch ohne kommerziellen Support.
CentOS Stream kann als kostenlose Alternative zu RHEL verwendet werden, wobei Support-Einschränkungen zu beachten sind. Die Kompatibilität entspricht weitgehend RHEL, jedoch können zeitliche Verzögerungen bei Sicherheits-Updates auftreten.
Windows Server 2019 oder 2022 kann für Windows-Container-Workloads als Worker-Node verwendet werden. Master-Nodes müssen weiterhin Linux-basiert sein. Gemischte Linux-Windows-Cluster erfordern zusätzliche Netzwerk- und Sicherheitskonfigurationen.
| Betriebssystem | Verwendung | Support-Level | Besonderheiten |
|---|---|---|---|
| RHEL 8/9 | Alle Node-Typen | Vollständig | Enterprise-Support, optimiert |
| Red Hat CoreOS | Alle Node-Typen | Vollständig | Container-optimiert, automatische Updates |
| Fedora CoreOS | Dev/Test | Community | Kostenlose CoreOS-Variante |
| CentOS Stream | Alle Node-Typen | Eingeschränkt | RHEL-Alternative ohne Support |
| Windows Server | Nur Worker-Nodes | Windows-Container | Master müssen Linux bleiben |
OpenShift-Cluster benötigen verschiedene Arten von Speicher für unterschiedliche Zwecke. Die Storage-Architektur beeinflusst Performance, Verfügbarkeit und Skalierbarkeit des gesamten Clusters erheblich.
Lokaler Node-Speicher muss ausreichend Kapazität für Betriebssystem, Container-Runtime und temporäre Container-Daten bieten. 120 GB stellen das Minimum dar, während 500 GB oder mehr für produktive Worker-Nodes empfohlen werden. SSD-Speicher verbessert I/O-Performance für Container-Operationen deutlich.
Etcd-Speicher erfordert besondere Aufmerksamkeit, da die Cluster-Datenbank extrem latenz-sensitiv ist. Dedizierte SSDs mit hohen IOPS-Werten sind essentiell für etcd-Performance. Shared Storage oder Network-attached Storage kann zu Performance-Problemen und Cluster-Instabilitäten führen.
Kritische Anforderungen für etcd: - Dedizierte SSDs (keine geteilten Laufwerke) - Hohe IOPS-Werte (> 3000 IOPS) - Niedrige Latenz (< 10ms)
Container-Image-Storage wird für das Zwischenspeichern heruntergeladener Images benötigt. Jeder Node speichert Images lokal, wobei der Platzbedarf von der Anzahl und Größe genutzter Images abhängt. Image-Pruning-Mechanismen können Speicherverbrauch automatisch begrenzen.
Persistent Storage für Anwendungsdaten erfordert externe Storage-Systeme wie NFS, iSCSI oder Cloud-Provider-Storage. OpenShift unterstützt verschiedene Storage-Klassen für unterschiedliche Performance- und Verfügbarkeitsanforderungen.
Unterstützte Storage-Typen: - NFS (einfach einzurichten, moderate Performance) - iSCSI (höhere Performance, komplexere Konfiguration) - Cloud Provider Storage (AWS EBS, Azure Disk, GCP Persistent Disk) - Software-Defined Storage (OpenShift Data Foundation, Ceph, GlusterFS)
OpenShift erfordert spezifische Netzwerk-Konfigurationen für die Kommunikation zwischen Cluster-Komponenten und externe Konnektivität.
Master-Nodes (eingehend): - 6443: Kubernetes API Server - 2379-2380: etcd Server/Client API - 10250: Kubelet API - 10251: kube-scheduler (localhost) - 10252: kube-controller-manager (localhost)
Worker-Nodes (eingehend): - 10250: Kubelet API - 30000-32767: NodePort Services
Alle Nodes (Overlay-Network): - 4789: VXLAN Overlay Network - 6081: Geneve Overlay Network
OpenShift bringt eine integrierte Container-Runtime mit, die keine zusätzlichen Installationen externer Container-Engines erfordert. Die Runtime-Architektur basiert auf industry-standard Komponenten mit OpenShift-spezifischen Optimierungen.
CRI-O fungiert als primäre Container-Runtime in OpenShift-Clustern. Diese Runtime ist speziell für Kubernetes-Workloads optimiert und bietet bessere Integration als generische Container-Engines. CRI-O unterstützt OCI-kompatible Container-Images und -Runtime-Spezifikationen.
Podman wird für Container-Operationen auf Node-Ebene verwendet und ersetzt Docker-Kommandos in neueren OpenShift-Versionen. Podman ist daemonless und bietet verbesserte Sicherheit durch rootless Container-Ausführung.
Buildah ermöglicht das Erstellen von Container-Images innerhalb des Clusters ohne externe Build-Tools. Integration in OpenShift-Build-Prozesse erlaubt automatisierte Image-Erstellung aus Source-Code-Repositories.
Skopeo unterstützt Image-Transport und -Inspektion zwischen verschiedenen Container-Registries. Diese Komponente ermöglicht Image-Mirroring und -Synchronisation in Air-Gapped-Umgebungen.
Die integrierte Runtime-Stack eliminiert die Notwendigkeit manueller Container-Engine-Installationen und -Wartung. Updates und Patches werden durch OpenShift-Update-Mechanismen automatisch bereitgestellt.
OpenShift-Cluster sollten kontinuierlich überwacht werden, um Kapazitätsengpässe frühzeitig zu erkennen. Das integrierte Prometheus-Monitoring zeigt Ressourcenverbrauch auf Cluster-, Node- und Pod-Ebene und ermöglicht proaktive Kapazitätsplanung.
Wichtige Monitoring-Metriken: - CPU/Memory-Utilization pro Node (Warnschwelle: 80%) - Storage-Verbrauch und -Wachstumsraten - Netzwerk-Throughput und -Latenz zwischen Nodes - etcd-Performance-Metriken (Latenz, IOPS)
Skalierungs-Trigger: Wenn Nodes regelmäßig über 80% CPU- oder Memory-Auslastung erreichen, sollten zusätzliche Worker-Nodes hinzugefügt oder bestehende Nodes aufgerüstet werden.