15 Multi-Node Installation (Konzept)

Multi-Node-Installationen von OpenShift repräsentieren die Standardarchitektur für produktive Umgebungen und bilden die Grundlage für hochverfügbare, skalierbare Container-Plattformen. Diese Installationsmethode verteilt die OpenShift-Komponenten auf mehrere physische oder virtuelle Systeme und ermöglicht dadurch Redundanz, Lastverteilung und horizontale Skalierung.

15.1 Architekturgrundlagen

Eine Multi-Node-OpenShift-Installation basiert auf der klaren Trennung zwischen Control Plane und Data Plane. Die Control Plane wird von Master-Nodes bereitgestellt, die die zentralen Verwaltungsdienste ausführen. Worker-Nodes stellen die Compute-Ressourcen für Anwendungs-Workloads bereit und führen die Container-Runtime sowie den Kubelet-Service aus.

Diese Architektur implementiert das Prinzip der Verantwortungstrennung: Master-Nodes verwalten den Cluster-Zustand und treffen Scheduling-Entscheidungen, während Worker-Nodes die tatsächliche Workload-Ausführung übernehmen. Die Kommunikation zwischen den Nodes erfolgt über sichere, verschlüsselte Verbindungen mit gegenseitiger Authentifizierung.

15.1.1 Netzwerk-Segmentierung

Die Netzwerkarchitektur umfasst mehrere logische Schichten mit unterschiedlichen IP-Adressbereichen:

15.2 Master-Node-Konfiguration

Master-Nodes bilden die kritische Infrastruktur eines OpenShift-Clusters und müssen für Hochverfügbarkeit ausgelegt werden. Die Standardkonfiguration verwendet drei Master-Nodes in ungerader Anzahl, um Split-Brain-Szenarien zu vermeiden.

15.2.1 Hochverfügbarkeits-Design

etcd-Cluster-Architektur: Der etcd-Cluster, der den Cluster-Zustand persistiert, benötigt eine Mehrheit verfügbarer Nodes für Schreiboperationen. Bei drei Nodes kann einer ausfallen, bei fünf Nodes können zwei ausfallen.

Service-Verteilung: Jeder Master-Node führt identische Services aus, jedoch übernimmt nur einer zu einem Zeitpunkt die Rolle des aktiven Controllers. Leader-Election-Mechanismen sorgen für automatisches Failover bei Ausfällen. Die API-Server auf allen Master-Nodes sind gleichzeitig aktiv und können load-balanced werden.

15.2.2 Hardware-Anforderungen für Master-Nodes

Die Ressourcenplanung für Master-Nodes berücksichtigt etcd-Performance-Anforderungen und API-Server-Operationen:

Minimale Produktions-Konfiguration: - CPU: 4 Kerne (8 empfohlen) - RAM: 16 GB (32 GB für große Cluster) - Storage: 120 GB SSD (niedrige Latenz kritisch für etcd) - Netzwerk: 1 Gbit (10 Gbit für große Cluster)

Kritische Performance-Faktoren: - etcd erfordert <10ms Latenz für Write-Operationen - Netzwerk-Latenz zwischen Master-Nodes sollte <1ms betragen - IOPS-Anforderungen: >3000 für etcd-Storage

15.3 Worker-Node-Architektur

Worker-Nodes stellen die Compute-Kapazität für Anwendungs-Workloads bereit und können in verschiedene Kategorien spezialisiert werden. Standard-Worker-Nodes führen allgemeine Anwendungs-Workloads aus, während spezialisierte Nodes für spezifische Anforderungen optimiert werden können.

15.3.1 Node-Spezialisierung

Infrastructure-Nodes sind Worker-Nodes, die OpenShift-eigene Services wie Router, Registry und Monitoring-Komponenten ausführen. Diese Spezialisierung ermöglicht eine bessere Ressourcenplanung und isoliert Plattform-Services von Anwendungs-Workloads.

15.3.2 Node-Klassifizierung und -Verwaltung

Die Node-Klassifizierung erfolgt über Labels und Taints, die das Scheduler-Verhalten beeinflussen:

# Beispiel: Infrastructure-Node labeln
oc label node worker-infra-1 node-role.kubernetes.io/infra=

# Taint hinzufügen für dedizierte Workloads
oc adm taint node worker-infra-1 node-role.kubernetes.io/infra:NoSchedule

Machine Config Pools ermöglichen die gruppenweise Konfiguration von Nodes mit ähnlichen Eigenschaften. Diese Gruppierung ist essentiell für unterschiedliche Hardware-Konfigurationen oder Betriebssystem-Varianten.

15.4 Netzwerkdesign

Multi-Node-Installationen erfordern komplexe Netzwerkdesigns, die verschiedene Kommunikationsebenen berücksichtigen. Das Cluster-Netzwerk verbindet alle Nodes miteinander und muss ausreichende Bandbreite für Container-zu-Container-Kommunikation bereitstellen.

15.4.1 Container Network Interface (CNI)

OpenShift unterstützt verschiedene Netzwerk-Plugins, die erweiterte Netzwerk-Features ermöglichen:

OVN-Kubernetes (Standard): - Erweiterte Network Policies - Multi-Tenancy Support - Hybrid Networking - IPv4/IPv6 Dual-Stack

OpenShift SDN (Legacy): - Einfachere Konfiguration - Geringerer Resource-Overhead - Limitierte Policy-Features

15.4.2 Externe Konnektivität

Externe Konnektivität wird über Ingress-Controller und Load Balancer realisiert. Diese Komponenten leiten externen Traffic an interne Services weiter und können auf dedizierten Infrastructure-Nodes platziert werden.

Load Balancer-Typen: - API Load Balancer: Verteilt API-Server-Traffic auf alle Master-Nodes - Ingress Load Balancer: Verteilt Application-Traffic auf Router-Pods - Service Load Balancer: Cloud-Provider-Integration für LoadBalancer-Services

15.4.3 DNS-Integration

DNS-Integration ermöglicht die Auflösung von Service-Namen sowohl innerhalb als auch außerhalb des Clusters:

# Interne DNS-Namen (automatisch)
service-name.namespace.svc.cluster.local

# Externe DNS-Namen (konfiguriert)
*.apps.cluster.example.com

15.5 Storage-Architektur

Multi-Node-Umgebungen erfordern shared Storage-Lösungen für persistente Daten, die von verschiedenen Nodes zugänglich sein müssen. Network File System (NFS), iSCSI oder cloud-native Storage-Lösungen ermöglichen persistente Volumes, die unabhängig von der Node-Platzierung verfügbar sind.

15.5.1 Storage-Klassen und Dynamic Provisioning

Storage Classes definieren unterschiedliche Speichertypen mit spezifischen Performance- und Verfügbarkeitscharakteristika:

Dynamic Provisioning automatisiert die Erstellung von persistenten Volumes basierend auf Application-Anforderungen:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-storage
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd

15.5.2 Container Storage Interface (CSI)

CSI-Drivers erweitern die Storage-Integration und ermöglichen die Anbindung verschiedener Storage-Backends:

Unterstützte CSI-Drivers: - AWS EBS, Azure Disk, GCP Persistent Disk - NetApp Trident, Pure Storage - OpenShift Data Foundation (Ceph) - NFS, iSCSI, FC (Fibre Channel)

15.6 Installationsmethodiken

Multi-Node-Installationen können über verschiedene Methodiken realisiert werden, die sich in Automatisierungsgrad und Infrastruktur-Kontrolle unterscheiden.

15.6.1 Installer-Provisioned Infrastructure (IPI)

Der IPI-Ansatz automatisiert die Bereitstellung der zugrunde liegenden Infrastruktur auf unterstützten Cloud-Plattformen:

Unterstützte Plattformen: - AWS: Vollständig automatisiert mit VPC, ELB, Route53 - Azure: Resource Groups, Load Balancer, DNS - GCP: VPC, Cloud Load Balancer, Cloud DNS - VMware vSphere: VM-Provisioning, vCenter-Integration

15.6.2 User-Provisioned Infrastructure (UPI)

UPI erfordert manuelle Bereitstellung der Infrastruktur, bietet jedoch maximale Kontrolle:

UPI-Vorteile: - Vollständige Hardware-Kontrolle - Custom Netzwerk-Topologien - Spezielle Compliance-Anforderungen - Integration in bestehende Infrastruktur

UPI-Phasen: 1. Infrastructure Provisioning: Hardware, Netzwerk, Load Balancer 2. Bootstrap Phase: Temporärer Bootstrap-Node 3. Master Configuration: Control Plane Setup 4. Worker Integration: Worker-Nodes dem Cluster hinzufügen

15.6.3 Assisted Installer

Assisted Installer kombiniert webbasierte Konfiguration mit automatisierter Deployment-Orchestrierung. Diese Methode reduziert die Komplexität von Multi-Node-Installationen erheblich und unterstützt sowohl Bare-Metal- als auch virtualisierte Umgebungen.

Workflow: 1. Web-basierte Cluster-Konfiguration 2. Hardware-Discovery via Boot-ISO 3. Automatische Node-Klassifizierung 4. Geführte Installation mit Real-time Monitoring

15.7 Skalierung und Kapazitätsplanung

Multi-Node-Architekturen ermöglichen horizontale Skalierung durch Hinzufügung zusätzlicher Worker-Nodes. Die Skalierung kann manuell oder automatisiert basierend auf Resource-Utilization erfolgen.

15.7.1 Automatisierte Skalierung

Cluster Autoscaler können Worker-Nodes dynamisch hinzufügen oder entfernen basierend auf Ressourcenanforderungen:

apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
  name: "worker-autoscaler"
spec:
  minReplicas: 3
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: machine.openshift.io/v1beta1
    kind: MachineSet
    name: worker-machineset

15.7.2 Machine Sets und Machine Pools

Machine Sets abstrahieren die Node-Provisionierung und ermöglichen deklarative Skalierungsoperationen:

# MachineSet skalieren
oc scale machineset worker-machileset --replicas=5

# Neue MachineSet für spezialisierte Nodes erstellen  
oc create -f infrastructure-machineset.yaml

15.7.3 Kapazitäts-Metriken

Ressourcenplanung berücksichtigt verschiedene Faktoren:

Key Performance Indicators: - CPU-Utilization per Node (Ziel: <80%) - Memory-Utilization per Node (Ziel: <85%) - Pod-Density per Node (Standard: ~110 Pods/Node) - Network-Bandwidth-Utilization - Storage-IOPS und Latenz

15.8 Wartung und Lifecycle-Management

Multi-Node-Umgebungen erfordern koordinierte Wartungsoperationen, die die Verfügbarkeit des Clusters erhalten. Rolling Updates ermöglichen die Aktualisierung von Nodes ohne Service-Unterbrechung.

15.8.1 Rolling Updates und Node-Wartung

Node-Drain-Operations verlagern Workloads von Wartungs-Nodes auf andere verfügbare Nodes:

# Node für Wartung vorbereiten
oc adm drain worker-node-1 --ignore-daemonsets --delete-emptydir-data

# Node nach Wartung wieder verfügbar machen
oc adm uncordon worker-node-1

15.8.2 Machine Config Operator

Machine Config Operator automatisiert OS-Level-Konfigurationen und -Updates auf allen Nodes einer Gruppe:

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: custom-kernel-params
spec:
  kernelArguments:
    - 'systemd.unified_cgroup_hierarchy=1'

15.8.3 Monitoring und Observability

Monitoring und Alerting müssen die verteilte Natur von Multi-Node-Clustern berücksichtigen:

Cluster-Level-Metriken: - Node-Verfügbarkeit und -Health - etcd-Performance und Cluster-Konsistenz - API-Server Response-Zeiten - Resource-Utilization-Trends

Node-spezifische Metriken: - Hardware-Health (CPU, Memory, Disk) - Container-Runtime-Performance - Netzwerk-Connectivity und -Throughput - Storage-I/O-Performance

Service-Health-Checks: - Kubernetes API-Server-Erreichbarkeit - Container-Registry-Verfügbarkeit - DNS-Resolution-Performance - Ingress-Controller-Response-Zeiten

15.8.4 Backup und Disaster Recovery

Backup-Strategien für Multi-Node-Cluster müssen sowohl Cluster-Konfiguration als auch Anwendungsdaten berücksichtigen:

etcd-Backup-Automatisierung:

# Automated etcd backup auf allen Master-Nodes
/usr/local/bin/cluster-backup.sh /var/lib/etcd-backup

Application Data Backup: - Persistent Volume Snapshots - Database-spezifische Backup-Tools - GitOps-Repository-Backup für Konfigurationen

Multi-Node-Installationen bieten die Robustheit und Skalierbarkeit, die für produktive OpenShift-Umgebungen erforderlich sind. Die komplexere Architektur erfordert jedoch sorgfältige Planung von Netzwerk, Storage und Wartungsoperationen.