Netzwerkvoraussetzungen

OpenShift-Cluster erfordern eine sorgfältig geplante und konfigurierte Netzwerkinfrastruktur, die weit über grundlegende Internetkonnektivität hinausgeht. Die Netzwerkarchitektur muss verschiedene Kommunikationsebenen zwischen Cluster-Komponenten, Container-Anwendungen und externen Systemen ermöglichen, während gleichzeitig Sicherheit und Performance gewährleistet werden.

Die Komplexität der Netzwerkanforderungen steigt erheblich bei Multi-Node-Clustern, wo zusätzlich Load Balancer, erweiterte DNS-Konfigurationen und komplexe Firewall-Regeln berücksichtigt werden müssen. Single-Node-Installationen haben vereinfachte Netzwerkanforderungen, benötigen jedoch weiterhin korrekte DNS-Auflösung und Internetkonnektivität.

10.1 DNS-Konfiguration und Namensauflösung

DNS-Services bilden das Fundament jeder OpenShift-Installation, da sowohl interne Cluster-Kommunikation als auch externe Service-Zugriffe auf korrekte Namensauflösung angewiesen sind. Fehlkonfigurierte DNS-Einstellungen führen zu Cluster-Instabilitäten und Service-Ausfällen.

10.1.1 Forward- und Reverse-DNS-Auflösung

Forward-DNS-Auflösung muss für alle Cluster-Nodes und externe Services funktionieren. Jeder Node benötigt einen vollqualifizierten Domainnamen (FQDN), der von allen anderen Cluster-Nodes aufgelöst werden kann. Kurze Hostnamen sind nicht ausreichend und können zu Kommunikationsfehlern führen.

Reverse-DNS-Lookups sind ebenso kritisch und müssen für alle Node-IP-Adressen konfiguriert werden. OpenShift-Komponenten nutzen Reverse-Lookups für Authentifizierung und Autorisierung, weshalb fehlende oder inkorrekte PTR-Records zu Service-Problemen führen können.

10.1.2 Wildcard-DNS für Application Routes

Wildcard-DNS-Einträge ermöglichen die dynamische Erstellung von Application-Routes ohne manuelle DNS-Konfiguration für jede Anwendung. Ein Wildcard-Record der Form *.apps.cluster.example.com leitet alle Subdomain-Anfragen an den OpenShift-Router weiter, der die Anfragen an die entsprechenden Container-Services weiterleitet.

10.1.3 Interne DNS-Services

Interne DNS-Services innerhalb des Clusters werden automatisch von OpenShift verwaltet, erfordern jedoch korrekte Upstream-DNS-Server-Konfiguration. Die Cluster-DNS verwendet CoreDNS und muss externe Domains auflösen können, während interne Service-Namen automatisch verwaltet werden.

DNS-Caching und TTL-Werte beeinflussen die Performance und das Verhalten bei Node-Änderungen. Niedrige TTL-Werte (300-600 Sekunden) ermöglichen schnelle Updates bei Cluster-Änderungen, können jedoch die DNS-Last erhöhen.

10.2 IP-Adressplanung und Netzwerksegmentierung

OpenShift verwendet mehrere überlappende Netzwerkebenen, die sorgfältig geplant werden müssen, um IP-Adresskonflikte zu vermeiden. Die verschiedenen Netzwerkbereiche dienen unterschiedlichen Zwecken und müssen eindeutig voneinander getrennt sein.

10.2.1 Netzwerkbereiche im Überblick

Netzwerktyp	Standard-CIDR	Zweck	Erreichbarkeit
Machine Network	192.168.1.0/24	Node-IP-Adressen	Extern erreichbar
Pod Network	10.128.0.0/14	Container-IPs	Nur clusterintern
Service Network	172.30.0.0/16	Service-VIPs	Nur clusterintern
Host Network	Node-abhängig	Host-Prozesse	Extern erreichbar

10.2.2 Machine Network (Host-Netzwerk)

Host-Netzwerke umfassen die IP-Adressen der physischen oder virtuellen Nodes, auf denen OpenShift-Komponenten ausgeführt werden. Diese Adressen müssen aus dem regulären Unternehmens- oder Data-Center-Netzwerk stammen und für alle Cluster-Nodes erreichbar sein.

Machine-CIDR definiert den IP-Adressbereich für die Cluster-Nodes und muss aus dem verfügbaren Unternehmens-IP-Bereich stammen. Dieser Bereich muss ausreichend groß sein, um alle geplanten Cluster-Nodes zu umfassen und zukünftige Erweiterungen zu ermöglichen.

10.2.3 Pod- und Service-Netzwerke

Pod-Netzwerke verwenden interne IP-Adressbereiche für die Container-zu-Container-Kommunikation innerhalb des Clusters. Standardkonfigurationen nutzen 10.128.0.0/14, wodurch etwa 262.000 Pod-IP-Adressen verfügbar werden. Diese Bereiche müssen sich nicht mit externen Netzwerken überschneiden, da sie nur clusterintern genutzt werden.

Service-Netzwerke stellen virtuelle IP-Adressen für Kubernetes-Services bereit und verwenden typischerweise 172.30.0.0/16. Service-IPs sind cluster-intern und werden nie extern geroutet, müssen jedoch eindeutig sein, um Konflikte mit anderen internen Netzwerkbereichen zu vermeiden.

10.2.4 Load Balancer VIPs

Ingress-VIP und API-VIP sind spezielle IP-Adressen für Load Balancer-Funktionen in Multi-Node-Clustern. Diese Adressen müssen aus dem Machine-CIDR-Bereich stammen, dürfen jedoch nicht durch DHCP vergeben werden, da sie statisch konfiguriert werden müssen.

10.3 Firewall-Konfigurationen und Port-Freigaben

OpenShift-Cluster benötigen umfangreiche Firewall-Konfigurationen für die Kommunikation zwischen verschiedenen Cluster-Komponenten. Die Vielzahl erforderlicher Ports und Protokolle erfordert systematische Firewall-Planung und -Implementierung.

10.3.1 Control Plane Ports

Port	Protokoll	Zweck	Zugriff von
6443	TCP	Kubernetes API Server	Alle Nodes, Clients
2379-2380	TCP	etcd Server/Client API	Nur Master-Nodes
10250	TCP	Kubelet API	Master-Nodes
10251	TCP	kube-scheduler	Localhost
10252	TCP	kube-controller-manager	Localhost

10.3.2 Worker Node Ports

Port	Protokoll	Zweck	Zugriff von
10250	TCP	Kubelet API	Master-Nodes
10256	TCP	kube-proxy Health Check	Localhost
30000-32767	TCP/UDP	NodePort Services	Extern (optional)

10.3.3 Container Network Ports

Container-Netzwerk-Ports variieren je nach gewählter Container Network Interface (CNI):

OVN-Kubernetes: - 6081/UDP: Geneve-Tunnels - 6641/TCP: OVN Southbound DB - 6642/TCP: OVN Northbound DB

10.3.4 Application Traffic

10.4 Load Balancer-Anforderungen

Multi-Node-OpenShift-Cluster erfordern Load Balancer für die Verteilung von API-Traffic und Application-Traffic auf mehrere Nodes. Load Balancer-Konfigurationen beeinflussen sowohl Verfügbarkeit als auch Performance des gesamten Clusters.

10.4.1 API Load Balancer

Der API-Load Balancer verteilt Kubernetes-API-Traffic auf alle verfügbaren Master-Nodes und stellt einen einzigen Endpunkt für Cluster-Management bereit.

Konfigurationsanforderungen: - Port: 6443/TCP - Protokoll: TCP (keine SSL-Terminierung) - Backend-Pool: Alle Master-Nodes - Health Check: GET /healthz auf Port 6443

10.4.2 Application Load Balancer

Application-Load Balancer verteilen eingehenden Application-Traffic auf OpenShift-Router-Pods, die auf Infrastructure- oder Worker-Nodes ausgeführt werden.

Konfigurationsanforderungen: - Ports: 80/TCP, 443/TCP - Backend-Pool: Router-Nodes - SSL-Terminierung: Optional (kann in Router-Pods erfolgen) - Health Check: GET /stats auf Router-Stats-Port

10.4.3 Load Balancer-Implementierungen

Hardware-Load Balancer: - F5 BIG-IP: Enterprise-Features, SSL-Offloading - Citrix ADC: Application-aware Load Balancing - A10 Thunder: High-Performance Load Balancing

Software-Load Balancer: - HAProxy: Open Source, weit verbreitet - NGINX Plus: Commercial mit erweiterten Features - Keepalived + HAProxy: High-Availability-Setup

10.5 Internetkonnektivität und Air-Gapped-Umgebungen

OpenShift-Installationen benötigen typischerweise Internetkonnektivität für verschiedene Zwecke, von Container-Image-Downloads bis hin zu Operator-Updates. Hochsicherheitsumgebungen können jedoch vollständig offline installiert und betrieben werden.

10.5.1 Container-Image-Repositories

Container-Image-Repositories sind die häufigste Quelle für Internettraffic in OpenShift-Clustern:

Offizielle Repositories: - registry.redhat.io: Red Hat-zertifizierte Images - quay.io: Red Hat Quay Container Registry - registry.access.redhat.com: Legacy Red Hat Registry

Community-Repositories: - docker.io: Docker Hub (Standard Docker Registry) - gcr.io: Google Container Registry - ghcr.io: GitHub Container Registry

10.5.2 Operator Hub und Marketplace

Operator-Hub-Zugriffe ermöglichen die Installation zusätzlicher Cluster-Operatoren aus dem Red Hat Operator Hub. Diese Funktionalität erfordert Internetkonnektivität zu Red Hat-Services:

10.5.3 Telemetrie und Monitoring

Red Hat Telemetry sammelt anonymisierte Cluster-Metriken für Support- und Entwicklungszwecke:

10.5.4 Air-Gapped-Installationen

Air-Gapped-Installationen erfordern umfangreiche Vorbereitung durch das Erstellen lokaler Mirrors aller benötigten Container-Images und Update-Repositories.

Erforderliche Komponenten: - Mirror Registry: Lokale Container-Registry mit allen benötigten Images - Update Service: Lokaler Mirror der OpenShift-Update-Services - Operator Catalog: Lokale Kopien der Operator-Catalogs - Certificate Authority: Interne CA für Registry-Zertifikate

Vorbereitung: 1. Mirror alle benötigten Container-Images in lokale Registry 2. Konfiguriere Cluster für Nutzung der Mirror-Registry 3. Synchronisiere regelmäßig Updates von Upstream-Repositories 4. Teste Image-Pull-Vorgänge vor Production-Deployment

10.5.5 Proxy-Konfigurationen

Proxy-Konfigurationen ermöglichen Internetkonnektivität in Umgebungen mit eingeschränktem direkten Internetzugang. OpenShift unterstützt HTTP- und HTTPS-Proxies für ausgehenden Traffic.

Unterstützte Proxy-Typen: - HTTP Proxy: Für unverschlüsselten Traffic - HTTPS Proxy: Für verschlüsselten Traffic - SOCKS Proxy: Für TCP-basierte Verbindungen

# Cluster-weite Proxy-Konfiguration
oc edit proxy/cluster

# Pod-spezifische Proxy-Einstellungen
HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080  
NO_PROXY=localhost,127.0.0.1,.local,.svc

10.6 Netzwerk-Performance und -Optimierung

OpenShift-Netzwerk-Performance hängt von verschiedenen Faktoren ab, die bei der Infrastruktur-Planung berücksichtigt werden müssen.

10.6.1 Bandbreiten-Anforderungen

Inter-Node-Kommunikation: - Minimum: 1 Gbit zwischen allen Nodes - Empfohlen: 10 Gbit für größere Cluster (>50 Nodes) - Storage-Traffic: Zusätzliche Bandbreite für NFS/iSCSI

Latenz-Anforderungen: - etcd-Kommunikation: < 10ms zwischen Master-Nodes - Pod-zu-Pod: < 5ms innerhalb des gleichen Racks - External Load Balancer: < 2ms zu Frontend-Services

10.6.2 Quality of Service (QoS)

Prioritäts-Klassen: 1. Höchste Priorität: etcd-Kommunikation, API-Server-Traffic 2. Hohe Priorität: System-Pods, Monitoring-Services 3. Standard-Priorität: Application-Pods 4. Niedrige Priorität: Batch-Jobs, Backup-Traffic

10.7 Monitoring und Troubleshooting

OpenShift bietet integrierte Netzwerk-Monitoring-Funktionen, die bei der Diagnose von Netzwerkproblemen helfen.

Wichtige Metriken: - Netzwerk-Latenz zwischen Nodes - Paketloss-Raten im Overlay-Network - DNS-Auflösungszeiten und -Fehlerrate - Load Balancer-Response-Zeiten

Troubleshooting-Tools: - oc debug node/<node-name>: Node-Netzwerk-Debugging - oc get network.operator: CNI-Status überprüfen - oc get dns.operator: DNS-Operator-Status - Network Policy-Analyzer für Connectivity-Tests

10 Netzwerkvoraussetzungen