Eine Single-Node-Installation von OpenShift stellt eine vollständige Container-Plattform auf einem einzigen Server bereit. Diese Installationsmethode eignet sich primär für Entwicklungs-, Test- und Demonstrationszwecke sowie für kleinere Arbeitslasten in ressourcenbeschränkten Umgebungen.
Bei der Single-Node-Installation werden alle OpenShift-Komponenten auf einem einzelnen physischen oder virtuellen System konsolidiert. Die Master- und Worker-Funktionen laufen gemeinsam auf demselben Node, wodurch die übliche Trennung zwischen Control Plane und Data Plane aufgehoben wird. Diese Architektur reduziert die Komplexität erheblich, verzichtet jedoch auf die Hochverfügbarkeit, die durch verteilte Multi-Node-Setups erreicht wird.
Der Single-Node fungiert gleichzeitig als Master-Node mit allen Control-Plane-Komponenten (API-Server, etcd, Controller Manager, Scheduler) und als Worker-Node für die Ausführung von Anwendungs-Workloads. Die Container-Runtime, typischerweise CRI-O, verwaltet sowohl System-Container als auch Anwendungs-Container auf derselben Infrastruktur.
Konsolidierte Services: Alle OpenShift-Services teilen sich die Hardware-Ressourcen eines einzelnen Systems. etcd, API-Server und Anwendungs-Pods konkurrieren um CPU, Memory und Storage.
Vereinfachtes Networking: Das Overlay-Network zwischen Nodes entfällt, da alle Pods auf demselben Host laufen. Service-Discovery und Load-Balancing funktionieren weiterhin, sind aber weniger komplex.
Scheduler-Anpassungen: Der Kubernetes Scheduler muss so konfiguriert werden, dass er Workloads auf Master-Nodes platziert, was normalerweise durch Taints verhindert wird.
Single-Node-Installationen erfordern eine sorgfältige Dimensionierung der verfügbaren Ressourcen, da sowohl System-Services als auch Anwendungs-Workloads auf denselben Ressourcen laufen.
| Komponente | Minimum | Empfohlen | Produktiv |
|---|---|---|---|
| CPU | 8 Kerne | 16 Kerne | 32+ Kerne |
| RAM | 32 GB | 64 GB | 128+ GB |
| Storage | 120 GB | 500 GB | 1+ TB |
| Netzwerk | 1 Gbit | 10 Gbit | 25+ Gbit |
Der Speicherbedarf umfasst das Betriebssystem, OpenShift-Platform-Services, Container-Images, Container-Logs und persistente Volumes. Eine SSD-basierte Speicherlösung verbessert die Performance erheblich, insbesondere bei etcd-Operationen.
Storage-Aufteilung: - Betriebssystem: 50+ GB - Container-Images: 100+ GB (abhängig von Image-Anzahl) - etcd-Daten: 10-20 GB (je nach Cluster-Größe) - Container-Logs: 50+ GB (rotierend) - Persistent Volumes: Variable je nach Anwendungen
Storage-Performance: etcd ist besonders I/O-sensitiv. Latenz unter 10ms und mindestens 500 IOPS sind für stabile Cluster-Performance erforderlich.
OpenShift bietet verschiedene Ansätze für Single-Node-Installationen, die sich in Automatisierungsgrad und Konfigurationsflexibilität unterscheiden.
Der Assisted Installer bietet eine webbasierte Benutzeroberfläche zur Konfiguration und automatisierten Installation. Diese Methode ist benutzerfreundlich und reduziert die Wahrscheinlichkeit von Konfigurationsfehlern.
Installations-Workflow: 1. Webbasierte Cluster-Konfiguration über console.redhat.com 2. Download eines konfigurierten Discovery-ISO-Images 3. Boot des Zielsystems von der ISO 4. Automatische Hardware-Erkennung und -Validierung 5. Remote-gesteuerte Installation über Web-Interface
Vorteile: - Graphische Benutzeroberfläche für alle Konfigurationsschritte - Automatische Hardware-Validierung und Kompatibilitätsprüfung - Real-time Installation-Monitoring mit detaillierten Logs - Geführte Problemdiagnose bei Installationsfehlern
Die Agent-Based Installation ermöglicht eine vollständig automatisierte Installation ohne Internetverbindung während des Installationsprozesses. Alle erforderlichen Ressourcen werden vorab in einem ISO-Image gebündelt.
Vorteile für Air-Gapped-Umgebungen: - Keine Internetverbindung während Installation erforderlich - Alle Container-Images sind im ISO enthalten - Unterstützung für custom Certificate Authorities - Vorkonfiguration von Proxy-Einstellungen
Konfiguration über install-config.yaml:
apiVersion: v1
baseDomain: example.com
metadata:
name: sno-cluster
compute:
- name: worker
replicas: 0
controlPlane:
name: master
replicas: 1
platform:
none: {}
networking:
machineNetwork:
- cidr: 192.168.1.0/24Der manuelle Ansatz über das OpenShift Installer-Tool bietet maximale Kontrolle über den Installationsprozess, erfordert jedoch tiefgreifende Kenntnisse der OpenShift-Architektur.
Installations-Schritte:
# Installation-Config erstellen
openshift-install create install-config --dir=sno-cluster
# Manifests generieren
openshift-install create manifests --dir=sno-cluster
# Installation durchführen
openshift-install create cluster --dir=sno-cluster --log-level=infoDie Konfiguration einer Single-Node-Installation unterscheidet sich in mehreren kritischen Aspekten von Multi-Node-Setups.
Standardmäßig werden Master-Nodes von der Workload-Planung
ausgeschlossen durch einen NoSchedule-Taint. Bei
Single-Node-Installationen muss dies explizit geändert werden.
# Taint entfernen, um Workload-Scheduling auf Master-Node zu ermöglichen
oc adm taint nodes --all node-role.kubernetes.io/master-Resource-Quotas und Limits erfordern besondere Aufmerksamkeit, da alle Services um dieselben physischen Ressourcen konkurrieren.
Wichtige Resource-Überlegungen: - etcd benötigt garantierte CPU- und Memory-Ressourcen - API-Server sollte vor Ressourcen-Starvation geschützt werden - Anwendungs-Pods müssen realistische Limits haben - System-Pods haben Priorität über Anwendungs-Workloads
Die Speicherkonfiguration muss lokale Persistierung berücksichtigen, da verteilte Speicherlösungen nicht verfügbar sind.
Verfügbare Storage-Classes: - Local Persistent Volumes: Für Anwendungen mit lokalen Storage-Anforderungen - HostPath Volumes: Für temporäre Daten (nicht empfohlen für Produktion) - EmptyDir Volumes: Für temporäre Container-Daten
Netzwerk-Policies und Service-Mesh-Konfigurationen können vereinfacht werden, da keine Netzwerkkommunikation zwischen Nodes berücksichtigt werden muss. Ingress-Controller und Load-Balancing-Services müssen dennoch korrekt konfiguriert werden.
Single-Node-Installationen weisen systembedingte Einschränkungen auf, die bei der Planung berücksichtigt werden müssen.
Kritische Einschränkungen: - Kein Failover bei Hardware-Ausfällen - Single Point of Failure für alle Services - Wartungsfenster führen zu kompletten Service-Unterbrechungen - Keine automatische Disaster Recovery
Bestimmte OpenShift-Features funktionieren eingeschränkt oder gar nicht:
| Feature | Status | Alternativen |
|---|---|---|
| Multi-Zone Deployments | Nicht verfügbar | Lokale Redundanz |
| Distributed Storage | Eingeschränkt | Local Persistent Volumes |
| Node-Autoscaling | Nicht möglich | Manuelle Ressourcen-Anpassung |
| etcd-Clustering | Single-Instance | Regelmäßige Backups kritisch |
Die Performance-Charakteristik unterscheidet sich von Multi-Node-Setups durch Ressourcenkonflikte:
Single-Node-Installationen eignen sich für verschiedene spezifische Anwendungsbereiche, in denen die Einschränkungen akzeptabel sind.
Ideal für: - Lokale Anwendungsentwicklung mit vollständiger OpenShift-API - Testen von Deployment-Manifests und Operatoren - CI/CD-Pipeline-Entwicklung und -Tests - Schulungen und OpenShift-Learning
Entwickler-Workflow:
# Lokale Anwendung deployen
oc new-app --image=registry.redhat.io/ubi8/nodejs-16
# Route für externen Zugriff erstellen
oc expose service nodejs-16
# Logs und Status überwachen
oc logs -f deployment/nodejs-16Anwendungsfälle: - IoT-Datenverarbeitung an Remote-Standorten - Retail-Filialen mit lokalen Verarbeitungsanforderungen - Industrielle Automatisierung mit begrenzten Ressourcen - Telco-Edge-Deployments
Edge-spezifische Überlegungen: - Minimaler Wartungsaufwand (kein IT-Personal vor Ort) - Automatische Updates und Self-Healing - Offline-Betrieb und lokale Datenverarbeitung - Sichere Remote-Administration
Single-Node-Installationen bieten eine schnelle und ressourcenschonende Möglichkeit, OpenShift-Capabilities zu präsentieren und zu evaluieren.
Demo-Szenarien: - Showcase von Container-Deployment-Workflows - Demonstration von DevOps-Pipelines - Evaluation von OpenShift-Features vor größeren Investitionen - Proof-of-Concept für Container-Migration-Projekte
Der Betrieb einer Single-Node-Installation erfordert spezifische Praktiken, um die Einschränkungen zu kompensieren.
Da keine Redundanz vorhanden ist, sind regelmäßige Backups essentiell:
# etcd-Backup erstellen
sudo -E /usr/local/bin/cluster-backup.sh /root/assets/backup
# Backup-Verifikation
sudo -E /usr/local/bin/cluster-restore.sh /root/assets/backupBackup-Komponenten: - etcd-Snapshots (täglich) - Cluster-Konfigurationen und Custom Resources - Persistent Volume-Daten - Container-Registry-Images
Monitoring ist besonders wichtig, um Ressourcenengpässe frühzeitig zu erkennen:
Kritische Metriken: - CPU- und Memory-Utilization (Alarm bei >80%) - Storage-Füllstand und I/O-Performance - etcd-Latenz und -Throughput - Pod-Restart-Raten und Failed-Deployments
Resource-Limits definieren:
apiVersion: v1
kind: Pod
metadata:
name: application-pod
spec:
containers:
- name: app
resources:
requests:
memory: "256Mi"
cpu: "100m"
limits:
memory: "512Mi"
cpu: "500m"Die Migration von Single-Node- zu Multi-Node-Setups ist nicht automatisiert möglich und erfordert sorgfältige Planung: