OpenShift bietet eine Vielzahl von Installationsmethoden, die unterschiedliche Anwendungsszenarien, Komplexitätsgrade und infrastrukturelle Anforderungen adressieren. Die Auswahl der geeigneten Installationsmethode stellt eine fundamentale Entscheidung dar, die sowohl den Installationsprozess als auch den langfristigen Betrieb der Container-Plattform maßgeblich beeinflusst.
Die verschiedenen Installationsansätze unterscheiden sich primär in ihrem Automatisierungsgrad, der Kontrolle über die zugrunde liegende Infrastruktur und den Anforderungen an administrative Expertise. Während einige Methoden eine vollständig automatisierte Installation ermöglichen, gewähren andere maximale Flexibilität bei der Konfiguration spezifischer Umgebungsanforderungen.
| Methode | Zielgruppe | Komplexität | Infrastruktur-Kontrolle | Anwendungsbereich |
|---|---|---|---|---|
| OpenShift Local | Entwickler, Evaluierung | Niedrig | Keine | Entwicklung, Training |
| IPI | Cloud-Umgebungen | Niedrig | Gering | Produktive Cloud-Deployments |
| UPI | On-Premise | Hoch | Vollständig | Spezielle Anforderungen |
| Agent-Based | Bare Metal | Mittel | Mittel | Edge Computing, Bare Metal |
| Assisted Installer | Mixed Environments | Niedrig-Mittel | Mittel | Geführte Installation |
| Single-Node OpenShift | Edge, Remote | Niedrig | Gering | Ressourcenbeschränkte Umgebungen |
OpenShift Local, ursprünglich als Code Ready Containers (CRC) bezeichnet, stellt die zugänglichste Installationsmethode für Entwickler und IT-Fachkräfte dar, die OpenShift erstmalig evaluieren möchten. Diese Lösung implementiert eine vollständige OpenShift-Umgebung auf einem einzelnen Desktop- oder Laptop-System und eliminiert die Komplexität einer Multi-Node-Installation.
Die technische Architektur von OpenShift Local basiert auf einer virtuellen Maschine, die eine minimierte aber funktionsfähige OpenShift-Distribution enthält. Alle Master- und Worker-Komponenten werden auf diesem einzelnen virtuellen Node ausgeführt, wodurch eine realistische Cluster-Erfahrung simuliert wird. Die Virtualisierung erfolgt plattformspezifisch über Hyper-V unter Windows, HyperKit unter macOS oder KVM unter Linux.
Minimale Anforderungen: - RAM: 9 GB verfügbar - CPU: 4 Kerne - Storage: 35 GB freier Speicherplatz - Virtualisierung: Hardware-Virtualisierung aktiviert
Empfohlene Konfiguration: - RAM: 16+ GB verfügbar - CPU: 8+ Kerne - Storage: 100+ GB freier Speicherplatz (SSD empfohlen)
Die Funktionalität von OpenShift Local umfasst nahezu alle Features einer produktiven OpenShift-Installation. Entwickler können Container-Anwendungen deployen, Services konfigurieren, Routen erstellen und mit der OpenShift-Web-Konsole sowie CLI-Tools arbeiten. Einschränkungen bestehen lediglich in der Skalierbarkeit und Hochverfügbarkeit, da nur ein einzelner Node zur Verfügung steht.
Verfügbare Features: - Vollständige OpenShift Web Console - CLI-Tools (oc, kubectl) - Container-Registry - Build- und Deployment-Pipelines - Service Mesh (eingeschränkt) - Monitoring und Logging
Die Installer-Provisioned Infrastructure (IPI) Methode repräsentiert den modernsten und automatisiertesten Ansatz zur OpenShift-Installation. Hierbei übernimmt der OpenShift-Installer sowohl die Bereitstellung der notwendigen Cloud-Infrastruktur als auch die Installation und Konfiguration des OpenShift-Clusters selbst.
Der technische Ansatz von IPI basiert auf Infrastructure-as-Code Prinzipien und nutzt plattformspezifische APIs zur automatischen Erstellung von Compute-, Storage- und Netzwerkressourcen.
Vollständig unterstützte Plattformen: - Amazon Web Services (AWS): Automatische VPC-Erstellung, ELB-Konfiguration, Route53-DNS - Microsoft Azure: Resource Groups, Load Balancer, Azure DNS Integration - Google Cloud Platform (GCP): VPC, Cloud Load Balancer, Cloud DNS - VMware vSphere: Automatische VM-Bereitstellung, Netzwerkkonfiguration
Eingeschränkt unterstützte Plattformen: - IBM Cloud - OpenStack - Red Hat Virtualization
Der Installationsprozess beginnt mit einer Konfigurationsdatei
(install-config.yaml), die grundlegende Cluster-Parameter
spezifiziert:
apiVersion: v1
baseDomain: example.com
metadata:
name: production-cluster
platform:
aws:
region: us-east-1
pullSecret: '{"auths":{"registry.redhat.io":{"auth":"..."}}}'
sshKey: 'ssh-rsa AAAAB3NzaC1yc2E...'Der Installer validiert diese Konfiguration, erstellt die notwendige Infrastruktur und installiert anschließend OpenShift auf den bereitgestellten Ressourcen. Der gesamte Prozess dauert typischerweise 30-45 Minuten und erfordert minimale manuelle Intervention.
Vorteile: - Reduzierte Installationskomplexität - Konsistente Cluster-Konfigurationen - Integrierte Best Practices für Cloud-Deployments - Automatisierte Updates und Upgrades
Limitierungen: - Begrenzte Kontrolle über spezifische Infrastruktur-Details - Abhängigkeit von unterstützten Cloud-Plattformen - Eingeschränkte Anpassungsmöglichkeiten für spezielle Netzwerk-Topologien
User-Provisioned Infrastructure (UPI) stellt das Gegenmodell zu IPI dar und gewährt Administratoren maximale Kontrolle über alle Aspekte der OpenShift-Installation. Bei diesem Ansatz sind Organisationen selbst für die Bereitstellung und Konfiguration der gesamten Infrastruktur verantwortlich, während OpenShift auf diese bereits existierende Infrastruktur installiert wird.
Die UPI-Methodik erfordert die manuelle oder automatisierte Bereitstellung von Servern, Netzwerkkomponenten, Load Balancern und Storage-Systemen entsprechend den OpenShift-Spezifikationen.
Erforderliche Infrastruktur-Komponenten: - Master-Nodes: Mindestens 3 für Hochverfügbarkeit - Worker-Nodes: Variable Anzahl je nach Workload-Anforderungen - Load Balancer: Für API-Server und Ingress-Traffic - DNS-Server: Forward- und Reverse-Lookup für alle Nodes - Storage: Persistent Storage für Registry und Anwendungen
Der Installationsprozess bei UPI gliedert sich in mehrere definierte Phasen:
UPI eignet sich besonders für: - Bare-Metal-Installationen in eigenen Rechenzentren - Spezielle Compliance-Anforderungen - Integration in bestehende Netzwerk-Topologien - Air-Gapped-Umgebungen ohne Internetverbindung - Custom Hardware-Konfigurationen
Die erhöhte Komplexität stellt den primären Nachteil von UPI dar. Administratoren benötigen tiefgehende Kenntnisse der OpenShift-Architektur, Netzwerk-Konfigurationen und System-Administration.
Die Agent-Based Installation repräsentiert eine innovative Installationsmethode, die speziell für Bare-Metal-Deployments und Edge-Computing-Szenarien entwickelt wurde. Dieser Ansatz kombiniert die Automatisierung von IPI mit der Flexibilität von UPI und eignet sich besonders für Umgebungen ohne etablierte Virtualisierungsinfrastruktur.
Das technische Konzept basiert auf einem Discovery-Agent, der als bootfähiges ISO-Image bereitgestellt wird. Dieser Agent wird auf den Ziel-Servern gebootet und sammelt automatisch Hardware-Informationen wie CPU-Anzahl, Speicherkapazität, Netzwerk-Interfaces und Storage-Konfigurationen.
Automatische Hardware-Erkennung: - CPU-Spezifikationen und Kern-Anzahl - RAM-Kapazität und -Konfiguration - Storage-Geräte und Kapazitäten - Netzwerk-Interfaces und VLAN-Konfigurationen - IPMI/BMC-Informationen für Remote-Management
Die gesammelten Daten werden an einen Cluster-Installations-Service übermittelt, der die optimale Cluster-Konfiguration bestimmt und die Installation koordiniert.
Der Assisted Installer bietet eine webbasierte, geführte Installationserfahrung, die komplexe OpenShift-Installationen durch eine intuitive Benutzeroberfläche vereinfacht. Diese Methode richtet sich an IT-Administratoren, die von einer visuellen Installationsführung profitieren, ohne auf Flexibilität und Kontrolle verzichten zu müssen.
Die Web-Konsole des Assisted Installers führt Benutzer schrittweise durch den gesamten Installationsprozess. Interaktive Formulare sammeln alle notwendigen Parameter wie Cluster-Name, Netzwerk-Konfigurationen, SSH-Keys und Authentifizierungsdetails. Die Konsole validiert Eingaben in Echtzeit und bietet kontextuelle Hilfestellungen.
Pre-Flight Checks: - Hardware-Kompatibilitätsprüfung - Netzwerk-Konnektivitätstests - DNS-Auflösungsvalidierung - Resource-Verfügbarkeitsprüfung
Installation-Monitoring: - Live-Dashboard mit Node-Status - Detaillierte Installations-Logs - Progress-Tracking für alle Cluster-Komponenten - Automatische Problem-Diagnose mit Lösungsvorschlägen
Single-Node OpenShift (SNO) stellt eine spezialisierte Installationsmethode dar, die alle OpenShift-Funktionen auf einem einzelnen Server konsolidiert. Diese Architektur eliminiert die Komplexität von Multi-Node-Clustern und reduziert sowohl Ressourcenanforderungen als auch administrativen Overhead.
Die technische Implementierung von SNO konsolidiert Master- und Worker-Funktionen auf einem einzelnen Node. Control Plane Komponenten wie etcd, API-Server und Controller Manager werden gemeinsam mit Workload-Pods auf demselben System ausgeführt. Spezielle Optimierungen reduzieren den Ressourcen-Overhead und verbessern die Performance in dieser konsolidierten Architektur.
Minimale Produktions-Konfiguration: - CPU: 8 Kerne - RAM: 32 GB - Storage: 120 GB (SSD empfohlen) - Netzwerk: 1 Gbit Ethernet
Empfohlene Edge-Konfiguration: - CPU: 16+ Kerne - RAM: 64+ GB - Storage: 500+ GB SSD - Netzwerk: 10 Gbit Ethernet (falls verfügbar)
SNO eignet sich besonders für: - Retail-Filialen: Lokale Anwendungen mit geringen Ressourcen - Produktionsstätten: Industrial IoT und Monitoring-Anwendungen - Remote-Standorte: Außenstellen ohne IT-Personal vor Ort - Entwicklungsumgebungen: Vollständige OpenShift-Features für Entwicklerteams
Wichtige Limitierungen: - Keine Hochverfügbarkeit (Single Point of Failure) - Begrenzte horizontale Skalierbarkeit - Eingeschränkte Performance bei hohen Workloads
Neben den produktionsorientierten Installationsmethoden bietet das OpenShift-Ökosystem verschiedene Sandbox- und Evaluierungsoptionen, die schnellen Zugang zur Plattform ohne aufwändige Installationen ermöglichen.
Developer Sandbox for Red Hat OpenShift: - Kostenloser Zugang zu geteilter OpenShift-Umgebung - Begrenzte Ressourcen und Laufzeiten - Ideal für Anwendungsentwicklung und -tests - Keine Kreditkarte oder Installation erforderlich
Red Hat OpenShift Dedicated (Trial): - Vollverwaltete OpenShift-Umgebung in Public Clouds - Produktionsähnliche Features und Performance - Zeitlich begrenzte Evaluierung (typisch 30-60 Tage) - Keine eigene Infrastruktur erforderlich
Schrittweise Evaluierung: 1. Exploration: Developer Sandbox für erste Erfahrungen 2. Development: OpenShift Local für lokale Entwicklung 3. Testing: Assisted Installer oder IPI für Cluster-Tests 4. Production: UPI oder managed Services für produktive Deployments
Infrastruktur-Umgebung: - Cloud vs. On-Premise vs. Edge - Bestehende Virtualisierungs-Infrastruktur - Netzwerk-Topologie und -Beschränkungen - Storage-Anforderungen und -Verfügbarkeit
Betriebsanforderungen: - Hochverfügbarkeits-Anforderungen - Skalierbarkeits-Erwartungen - Compliance und Sicherheitsrichtlinien - Wartungsfenster und Update-Strategien
Expertise und Ressourcen: - Verfügbare OpenShift/Kubernetes-Kenntnisse - IT-Team-Größe und -Verfügbarkeit - Budget für Schulungen und externe Unterstützung - Langfristige Wartungs- und Support-Strategien
Die Auswahl der geeigneten Installationsmethode erfordert eine sorgfältige Abwägung von Faktoren wie technischer Expertise, Infrastruktur-Anforderungen, Kontrollebenen und langfristigen Betriebszielen. Während einfache Evaluierungen mit OpenShift Local oder Sandbox-Umgebungen beginnen können, erfordern produktive Deployments eine fundierte Analyse der verfügbaren Installationsoptionen und ihrer jeweiligen Vor- und Nachteile.