32 NodePort und LoadBalancer

NodePort- und LoadBalancer-Services erweitern die cluster-interne Konnektivität um externe Erreichbarkeit durch dedizierte Port-Allocation und Cloud-Provider-Integration. Diese Service-Typen implementieren verschiedene Strategien für öffentlich zugängliche Anwendungen mit unterschiedlichen Abwägungen zwischen Einfachheit, Skalierbarkeit und Infrastruktur-Anforderungen.

32.1 NodePort-Services: Grundlagen und Funktionsweise

NodePort-Services allokieren statische Ports auf allen Cluster-Nodes für externe Service-Erreichbarkeit über Node-IP-Adressen und zugewiesene Ports. Diese Port-Allocation erfolgt aus konfigurierten Port-Bereichen (standardmäßig 30000-32767) und gewährleistet eindeutige Port-Zuweisungen über alle Cluster-Services hinweg.

32.1.1 Automatische Port-Zuordnung

Das Traffic-Routing für NodePort-Services implementiert automatische Weiterleitung von Node-Ports zu Service-ClusterIPs über iptables- oder IPVS-Regeln. Diese transparente Weiterleitung abstrahiert die Backend-Pod-Discovery von externen Clients und ermöglicht Standard-Load-Balancing-Mechanismen.

apiVersion: v1
kind: Service
metadata:
  name: webapp-nodeport
spec:
  type: NodePort
  selector:
    app: webapp
  ports:
  - port: 80          # Service Port
    targetPort: 8080   # Container Port
    nodePort: 30080    # Externer Port (optional, sonst automatisch)
    protocol: TCP

32.1.2 Hochverfügbarkeit durch Distributed Proxy

Node-Level Proxying gewährleistet Service-Erreichbarkeit über alle Cluster-Nodes unabhängig von der Pod-Platzierung. Diese verteilte Proxy-Architektur eliminiert Single Points of Failure und ermöglicht Hochverfügbarkeit für externen Service-Zugriff.

Funktionsweise: Ein externer Client kann jeden beliebigen Node-Port verwenden - auch wenn der Pod auf einem anderen Node läuft. Der kube-proxy auf dem angefragten Node leitet den Traffic automatisch an den korrekten Backend-Pod weiter.

32.1.3 Port-Management

Das Port-Management erfolgt automatisch durch die Kubernetes Control Plane mit Kollisionserkennung und automatischer Port-Zuweisung oder manueller Port-Spezifikation für deterministische Port-Zuweisungen:

Automatische Zuweisung:

ports:
- port: 80
  targetPort: 8080
  # nodePort wird automatisch aus dem Bereich 30000-32767 zugewiesen

Manuelle Zuweisung:

ports:
- port: 80
  targetPort: 8080
  nodePort: 30080  # Explizite Port-Angabe

[Diagramm: NodePort-LoadBalancer-Architektur mit Traffic-Flow]

32.2 LoadBalancer-Services: Cloud-Integration

LoadBalancer-Services erweitern die NodePort-Funktionalität durch Cloud-Provider Load-Balancer-Integration für verwaltete externe Zugriffspunkte. Diese Cloud-Integration abstrahiert die Infrastruktur-Komplexität und bietet Enterprise-Grade Load-Balancing-Features.

32.2.1 Automatische Load-Balancer-Bereitstellung

Cloud-Provider-Controller implementieren automatische Load-Balancer-Bereitstellung und -Konfiguration basierend auf Service-Spezifikationen:

apiVersion: v1
kind: Service
metadata:
  name: webapp-loadbalancer
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
spec:
  type: LoadBalancer
  selector:
    app: webapp
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP

Diese API-basierte Infrastruktur-Verwaltung ermöglicht deklarative Load-Balancer-Deployments ohne manuelle Infrastruktur-Konfiguration.

32.2.2 Health Check Integration

Die Health-Check-Integration zwischen Cloud Load-Balancern und Kubernetes Health-Probes gewährleistet Traffic-Routing ausschließlich zu gesunden Nodes und Services. Diese mehrstufige Health-Überprüfung verbessert die Service-Zuverlässigkeit und User Experience.

Kubernetes-seitige Health Checks:

spec:
  containers:
  - name: webapp
    image: myapp:latest
    ports:
    - containerPort: 8080
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

32.2.3 External-IP-Assignment

Die External-IP-Zuweisung durch Cloud-Provider Load-Balancer bietet stabile öffentliche IP-Adressen für Service-Zugriff unabhängig von Node-IP-Änderungen. Diese IP-Stabilität unterstützt DNS-Konfiguration und Client-Integration.

32.3 Service-Typen im Vergleich

Service-Typ Externe IP Port-Bereich Cloud-Integration Anwendungsfall
ClusterIP Nein Alle Ports Nicht erforderlich Interne Services
NodePort Node-IPs 30000-32767 Optional Entwicklung, einfache Setups
LoadBalancer Ja (automatisch) Alle Ports Erforderlich Produktionsumgebungen
ExternalName DNS-Alias N/A Nicht erforderlich Externe Service-Integration

32.4 Traffic-Flow und Load-Balancing-Strategien

32.4.1 External Traffic Policy

External Traffic Policy-Konfigurationen steuern das Load-Balancing-Verhalten zwischen Cloud Load-Balancer und Cluster-Nodes mit “Local” oder “Cluster” Routing-Strategien:

Cluster Policy (Standard):

spec:
  type: LoadBalancer
  externalTrafficPolicy: Cluster
  # Traffic wird gleichmäßig auf alle Nodes verteilt
  # Source-IP geht verloren durch Node-zu-Node-Weiterleitung

Local Policy:

spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  # Traffic geht nur an Nodes mit lokalen Pods
  # Source-IP bleibt erhalten

32.4.2 Source-IP-Erhaltung

Source-IP-Preservation unterstützt Client-IP-basierte Zugriffskontrolle und Audit-Anforderungen durch konfigurierbare Traffic-Policy-Einstellungen. Diese IP-Sichtbarkeit ermöglicht Application-Level Client-Identifikation und geografische Traffic-Analyse.

Vorteile der Local Policy: - Erhaltung der Client-IP-Adresse - Reduzierte Latenz durch direktes Routing - Bessere Performance bei IP-basierten Sicherheitsregeln

Nachteile der Local Policy: - Ungleichmäßige Load-Verteilung - Potentielle Hotspots bei ungleicher Pod-Verteilung

32.4.3 Session Affinity

Session-Affinity kann auf mehreren Ebenen implementiert werden:

Kubernetes Service-Level:

spec:
  type: LoadBalancer
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 3600

Cloud-Provider-Level: Sticky Sessions über Cloud-Provider-spezifische Annotations

32.5 Cloud-Provider-spezifische Implementierungen

32.5.1 Amazon Web Services (AWS)

AWS Application Load Balancer (ALB) Integration ermöglicht Layer-7 Load-Balancing mit erweiterten Routing-Regeln:

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"

AWS-spezifische Features: - Network Load Balancer (NLB) für Layer-4 - Application Load Balancer (ALB) für Layer-7 - Cross-Zone Load Balancing - SSL/TLS-Terminierung

32.5.2 Google Cloud Platform (GCP)

Google Cloud Load Balancer-Integration implementiert globales Load-Balancing mit Anycast-IP-Adressen:

metadata:
  annotations:
    cloud.google.com/load-balancer-type: "External"
    cloud.google.com/backend-config: '{"default": "webapp-backendconfig"}'

GCP-spezifische Features: - Global Load Balancing - Anycast-IP-Adressen - Automatisches Failover - CDN-Integration

32.5.3 Microsoft Azure

Azure Load Balancer-Services bieten sowohl Basic als auch Standard SKU-Optionen:

metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "false"
    service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "default"

32.5.4 Private Cloud und On-Premises

Private Cloud LoadBalancer-Implementierungen nutzen softwarebasierte Load-Balancer für On-Premises-Umgebungen:

MetalLB für Bare-Metal-Cluster:

apiVersion: v1
kind: ConfigMap
metadata:
  name: metallb-config
  namespace: metallb-system
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 192.168.1.100-192.168.1.110

32.6 Sicherheitsüberlegungen

32.6.1 Firewall-Regeln für NodePort

Das Firewall-Rule-Management für NodePort-Services erfordert automatische oder manuelle Port-Öffnung in Netzwerk-Sicherheitsgruppen:

AWS Security Groups:

Type: Custom TCP
Port Range: 30000-32767
Source: 0.0.0.0/0 (oder spezifische IP-Bereiche)

Kubernetes Network Policies für zusätzliche Sicherheit:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-netpol
spec:
  podSelector:
    matchLabels:
      app: webapp
  policyTypes:
  - Ingress
  ingress:
  - from:
    - ipBlock:
        cidr: 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 8080

32.6.2 TLS-Terminierung

TLS-Terminierungsstrategien können auf LoadBalancer-Level oder Service-Level implementiert werden:

LoadBalancer-Level TLS:

metadata:
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:region:account:certificate/cert-id"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "http"

Pod-Level TLS: TLS-Terminierung im Container selbst für End-to-End-Verschlüsselung

32.6.3 DDoS-Schutz

DDoS-Protection-Integration über Cloud-Provider-Security-Services schützt LoadBalancer-Services gegen volumen- und anwendungsbasierte Angriffe. Diese verwalteten Security-Services reduzieren den operativen Sicherheitsaufwand.

32.7 Performance und Skalierung

32.7.1 LoadBalancer-Performance-Charakteristika

LoadBalancer-Performance-Eigenschaften variieren zwischen Cloud-Providern mit unterschiedlichen Durchsatz-Limits und Latenz-Profilen:

Cloud-Provider Max. Throughput Latenz Concurrent Connections
AWS NLB 55 Gbps < 100ms Millionen
GCP Load Balancer Auto-scaling < 50ms Millionen
Azure Load Balancer 25 Gbps < 4ms 1 Million

32.7.2 Auto-Scaling Integration

Auto-Scaling-Integration ermöglicht dynamische Load-Balancer-Kapazitätsanpassung basierend auf Traffic-Patterns:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: webapp-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: webapp
  minReplicas: 3
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

32.7.3 Connection-Pooling und Keep-Alive

Connection-Pooling und Keep-Alive-Optimierung auf LoadBalancer-Level reduzieren Connection-Establishment-Overhead:

HTTP Keep-Alive Konfiguration: - Idle Timeout: 60 Sekunden - Max Requests pro Connection: 1000 - Connection Timeout: 5 Sekunden

32.8 Monitoring und Observability

32.8.1 LoadBalancer-Metriken

Wichtige LoadBalancer-Metriken für umfassende Überwachung:

Traffic-Metriken: - Request Rate (Requests/Sekunde) - Response Time (95th Percentile) - Throughput (Bytes/Sekunde) - Error Rate (4xx/5xx Responses)

Backend-Health: - Healthy Target Count - Unhealthy Target Count - Health Check Latency

Resource-Metriken: - Active Connections - New Connections/Sekunde - Connection Errors

32.8.2 Health-Check-Monitoring

Health-Check-Monitoring überwacht LoadBalancer-zu-Backend Health-Check-Erfolgsraten:

spec:
  containers:
  - name: webapp
    image: myapp:latest
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 30
      periodSeconds: 10
      timeoutSeconds: 5
      failureThreshold: 3

32.8.3 Traffic-Pattern-Analyse

Traffic-Pattern-Analyse über LoadBalancer-Logs bietet Einblicke in Nutzerverhalten und geografische Traffic-Verteilung. Diese Traffic-Analytics unterstützen Kapazitätsplanung und Performance-Optimierung.

32.9 Entwicklungs- und Test-Szenarien

32.9.1 NodePort in Single-Node-Umgebungen

NodePort-Services in Single-Node-Umgebungen vereinfachen External-Access-Testing ohne komplexe Load-Balancer-Infrastruktur:

# Service über NodePort testen
curl http://$(minishift ip):30080

# Port-Weiterleitung als Alternative
kubectl port-forward service/webapp 8080:80

32.9.2 LoadBalancer-Simulation

LoadBalancer-Simulation in Entwicklungsumgebungen kann über Software-LoadBalancer implementiert werden:

HAProxy-Konfiguration für lokale Tests:

frontend webapp_frontend
    bind *:80
    default_backend webapp_backend

backend webapp_backend
    balance roundrobin
    server node1 192.168.1.10:30080 check
    server node2 192.168.1.11:30080 check

32.10 Cost-Optimization

32.10.1 LoadBalancer-Konsolidierung

LoadBalancer-Konsolidierung durch Ingress-Controller kann mehrere Services über einzelne LoadBalancer-Instanzen exponieren:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
spec:
  rules:
  - host: app1.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
  - host: app2.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80

32.10.2 Right-Sizing und Reserved Instances

Right-Sizing LoadBalancer-Instanzen basierend auf Traffic-Patterns verhindert Over-Provisioning:

Monitoring-basierte Optimierung: - Traffic-Volume-Analyse über 30-90 Tage - Peak-Load-Identifikation - Cost-per-Request-Kalkulationen - Reserved Instance-Möglichkeiten evaluieren

32.10.3 Automatisiertes Lifecycle-Management

Automatisiertes LoadBalancer-Lifecycle-Management für Entwicklungsumgebungen:

apiVersion: v1
kind: Service
metadata:
  name: dev-webapp
  labels:
    environment: development
  annotations:
    "lifecycle.kubernetes.io/auto-delete": "24h"
spec:
  type: LoadBalancer
  # Service wird automatisch nach 24h gelöscht