Kubernetes Load Balancing: 5 technische Optionen mit Beispielen

Was ist Kubernetes Load Balancing?

Kubernetes Load Balancing bezeichnet die automatisierte Verteilung des Netzwerk-Traffics auf mehrere Pods, um hohe Verfügbarkeit, Skalierbarkeit und optimale Performance sicherzustellen. Es arbeitet auf zwei Ebenen: der internen Verteilung innerhalb des Clusters und der externen Erreichbarkeit für Nutzer außerhalb.

Indem Kubernetes die Komplexität des Routings und der Anfrageverteilung abstrahiert, können Entwickler skalierbare Anwendungen bereitstellen, ohne die Traffic-Verteilung manuell verwalten zu müssen. Diese Automatisierung ist essenziell für hohe Verfügbarkeit, Fehlertoleranz und Performance in modernen, containerisierten Umgebungen.

Technische Optionen für die Umsetzung von Load Balancing in Kubernetes:

• ClusterIP (intern): Verwendet eine virtuelle IP, um Traffic zwischen Pods innerhalb des Clusters zu verteilen – die Standardoption für die interne Service-zu-Service-Kommunikation.
• NodePort: Exponiert einen Service über einen statischen Port auf jedem Cluster-Node, sodass externe Clients Anwendungen über <NodeIP>:<NodePort> erreichen können.
• LoadBalancer: Integriert Cloud- oder Infrastruktur-Load-Balancer und stellt eine externe IP-Adresse bereit, die Traffic auf Cluster-Nodes und Backend-Pods verteilt.
• Ingress: Bietet HTTP/HTTPS-Routing auf Layer 7, sodass sich mehrere Services einen externen Endpunkt teilen können – mit host- und pfadbasierten Routing-Regeln.
• Gateway API: Nutzt dedizierte Gateway- und Route-Ressourcen für ein erweitertes, richtliniengesteuertes Traffic-Management mit Unterstützung für mehrere Protokolle und getrennte Team-Zuständigkeiten.

Dieser Beitrag ist Teil einer Artikelserie über Kubernetes Scheduling.

Warum Kubernetes Load Balancing braucht

Kubernetes-Umgebungen sind dynamisch. Pods können jederzeit erstellt, beendet, neu geplant oder skaliert werden – abhängig von der Anwendungslast oder dem Zustand des Clusters. Ohne Load Balancing würde Traffic weiterhin an überlastete oder nicht verfügbare Pods fließen, was zu langsamen Antworten, fehlgeschlagenen Anfragen oder Ausfällen führt.

Load Balancing hilft Kubernetes, eine konstante Anwendungsperformance und Verfügbarkeit aufrechtzuerhalten. Es verteilt Anfragen auf gesunde Pods und leitet Traffic bei Ausfällen um. So können Anwendungen auch bei Pod-Abstürzen, Rolling Updates oder Infrastrukturänderungen weiterhin Nutzer bedienen.

Die wichtigsten Gründe, warum Kubernetes Load Balancing benötigt:

• Verhindert Traffic-Überlastung auf einzelnen Pods oder Nodes
• Unterstützt horizontale Skalierung durch Verteilung der Anfragen auf Replikate
• Sichert hohe Verfügbarkeit bei Pod- oder Node-Ausfällen
• Ermöglicht Deployments und Rolling Updates ohne Downtime
• Verbessert Antwortzeiten und Zuverlässigkeit der Anwendungen
• Vereinfacht das Traffic-Routing in dynamischen Container-Umgebungen
• Erlaubt Services, bei Traffic-Änderungen automatisch zu skalieren

Da Container kurzlebig sind und sich Workloads ständig verschieben, ist automatisiertes Load Balancing eine Grundvoraussetzung für einen stabilen Kubernetes-Betrieb.

5 Wege, Kubernetes Load Balancing umzusetzen

1. ClusterIP (intern)

ClusterIP ist der Standard-Service-Typ in Kubernetes. Er erstellt eine virtuelle IP-Adresse, die nur innerhalb des Clusters erreichbar ist, und eignet sich damit für die Kommunikation zwischen internen Services wie Frontend-, API- und Datenbank-Workloads. Externe Clients können einen ClusterIP-Service nicht direkt erreichen, was Backend-Services von öffentlichen Netzwerken isoliert.

Wird eine Anfrage an die ClusterIP-Adresse gesendet, fängt kube-proxy den Traffic ab und leitet ihn an einen der gesunden Pods hinter dem Service weiter. Die Routing-Regeln werden automatisch aktualisiert, wenn Pods hinzugefügt, entfernt oder ersetzt werden. So werden Anfragen auf verfügbare Replikate verteilt, ohne dass Anwendungen die Pod-IP-Adressen kennen müssen.

Die Load-Balancing-Entscheidung erfolgt typischerweise über iptables, IPVS oder eBPF-basierte Netzwerkimplementierungen, je nach Cluster-Konfiguration. Anwendungen kommunizieren mit einem stabilen Service-Endpunkt, während Kubernetes die Änderungen an den zugrunde liegenden Pods übernimmt. Das macht ClusterIP zur Grundlage für den Großteil der internen Service-zu-Service-Kommunikation.

2. NodePort

Ein NodePort-Service exponiert eine Anwendung über einen statischen Port auf jedem Node im Kubernetes-Cluster. Clients erreichen die Anwendung, indem sie Anfragen an <NodeIP>:<NodePort> senden. So erreicht externer Traffic Workloads, ohne dass ein dedizierter Cloud-Load-Balancer erforderlich ist.

Sobald Traffic an einem Node ankommt, leitet kube-proxy die Anfrage an einen der vom Service ausgewählten Pods weiter – selbst wenn dieser Pod auf einem anderen Node läuft. Kubernetes verteilt Anfragen weiterhin auf gesunde Pods, wenn sich die Anzahl der Replikate ändert, während der NodePort konstant bleibt.

Da jeder Node auf demselben Port lauscht, können Nutzer sich mit einem beliebigen Cluster-Node verbinden und die Anwendung erreichen. NodePort wird häufig in Entwicklungsumgebungen und On-Premises-Clustern verwendet oder als Grundlage für übergeordnete Service-Typen wie LoadBalancer. In Produktionsumgebungen ist es hingegen weniger üblich, Anwendungen direkt über NodePorts zu exponieren.

3. LoadBalancer

Ein LoadBalancer-Service baut auf NodePort auf und integriert Kubernetes mit einem externen Load Balancer, der von einer Cloud-Plattform oder unterstützten Infrastruktur bereitgestellt wird. Er stellt eine öffentliche oder private IP-Adresse bereit, über die Clients die Anwendung erreichen, ohne sich direkt mit einzelnen Cluster-Nodes zu verbinden.

Der externe Load Balancer verteilt eingehende Verbindungen auf die Cluster-Nodes. Die Anfragen werden anschließend über den entsprechenden NodePort-Service weitergeleitet, wo kube-proxy einen gesunden Backend-Pod auswählt. So entsteht Load Balancing sowohl auf Infrastrukturebene (über Nodes hinweg) als auch auf Kubernetes-Ebene (über Pods hinweg).

Die meisten Managed-Kubernetes-Dienste stellen bei Erstellung dieses Service-Typs automatisch cloud-native Load Balancer von Anbietern wie AWS, Azure oder Google Cloud bereit. Health Checks stellen sicher, dass Traffic nur an gesunde Nodes gesendet wird, während Kubernetes die Backend-Endpunkte kontinuierlich aktualisiert, wenn Pods skalieren oder ersetzt werden.

4. Ingress

Ingress bietet Routing auf Layer 7 (HTTP/HTTPS) für mehrere Anwendungen über einen einzigen Einstiegspunkt. Statt jeden Service über eine eigene externe IP-Adresse zu exponieren, definiert eine Ingress-Ressource Routing-Regeln auf Basis von Hostnamen, URL-Pfaden oder anderen HTTP-Attributen. Ein Ingress-Controller, etwa Traefik, setzt diese Regeln um.

Sendet ein Client eine HTTP- oder HTTPS-Anfrage, wertet der Ingress-Controller die Routing-Regeln aus und leitet die Anfrage an den passenden Kubernetes-Service weiter. Der Service verteilt den Traffic dann auf seine Backend-Pods. Dieser Ansatz vereinfacht die Bereitstellung von Anwendungen und unterstützt zugleich Funktionen wie TLS-Terminierung, Redirects, Authentifizierung und Request Rewriting.

Da sich mehrere Services denselben externen Endpunkt teilen können, reduziert Ingress die Anzahl der benötigten öffentlichen IP-Adressen und Load Balancer. Es wird häufig eingesetzt, um Webanwendungen, APIs und Microservices zu exponieren und dabei HTTP- und HTTPS-Traffic zentral zu verwalten.

5. Gateway API

Gateway API ist ein neuerer Kubernetes-Netzwerkstandard, der einen flexibleren und erweiterbaren Ansatz für die Verwaltung des Anwendungs-Traffics bietet. Er trennt die Infrastrukturkonfiguration vom Anwendungs-Routing: Plattform-Teams verwalten die Gateways, während Anwendungsteams definieren, wie ihre Services Traffic empfangen.

Der Traffic erreicht zunächst ein Gateway, das den Netzwerk-Einstiegspunkt darstellt. Routing-Ressourcen wie HTTPRoute legen fest, wie Anfragen zugeordnet und an Kubernetes-Services weitergeleitet werden. Sobald eine Anfrage den ausgewählten Service erreicht, verteilt Kubernetes sie mit seinen Standard-Load-Balancing-Mechanismen auf die verfügbaren Pods.

Im Vergleich zu Ingress bietet Gateway API eine granularere Kontrolle über Routing-Richtlinien, Traffic Splitting und mandantenfähige Umgebungen. Zudem unterstützt es neben HTTP weitere Protokolle wie TCP und gRPC – und eignet sich damit besser für komplexe Netzwerkanforderungen und groß angelegte Kubernetes-Deployments.

Kubernetes LoadBalancer vs. Ingress vs. API Gateway

Die folgende Tabelle fasst die Unterschiede zwischen diesen Optionen zusammen:

Anwendungsfälle für Kubernetes Load Balancing

Internes Service-zu-Service Load Balancing

Internes Service-zu-Service Load Balancing verteilt Traffic zwischen Anwendungen, die im selben Kubernetes-Cluster laufen. Services kommunizieren über stabile Endpunkte, während Kubernetes Anfragen automatisch an verfügbare Pods weiterleitet. Dieser Ansatz hilft, Performance und Verfügbarkeit aufrechtzuerhalten, wenn Workloads skalieren oder Pods ersetzt werden.

Relevante Technologien: Kubernetes Service (ClusterIP), kube-proxy, eBPF-basiertes Networking, Service Mesh, DNS-basierte Service Discovery.

Externes Load Balancing

Externes Load Balancing verwaltet den Traffic, der von Nutzern, Anwendungen oder externen Systemen in das Cluster gelangt. Es stellt einen öffentlichen Einstiegspunkt bereit und verteilt eingehende Anfragen auf gesunde Backend-Services. So können Anwendungen höhere Traffic-Volumen verarbeiten und bleiben auch bei Ausfällen, Wartungsarbeiten oder Skalierungsvorgängen verfügbar.

Relevante Technologien: LoadBalancer-Service, Layer-4-Load-Balancer, Ingress, Gateway API, TLS-Terminierung.

North-South-Traffic-Management

North-South-Traffic-Management steuert den Traffic zwischen externen Clients und Workloads innerhalb des Clusters. Es wird häufig für öffentlich zugängliche Anwendungen, APIs und Partner-Integrationen eingesetzt. Über das reine Load Balancing hinaus umfasst es oft Routing, Sicherheitsrichtlinien, Traffic-Filterung und Verschlüsselung, um zu kontrollieren, wie externe Anfragen auf interne Services zugreifen.

Relevante Technologien: Ingress, Gateway API, Layer-7-Routing, TLS-Terminierung, Authentifizierungs- und Autorisierungsrichtlinien, Web-Application-Firewall-Integration.

East-West-Traffic-Management

East-West-Traffic-Management konzentriert sich auf die Kommunikation zwischen Services innerhalb des Clusters oder über verbundene Kubernetes-Umgebungen hinweg. In Microservices-Architekturen tauschen Anwendungen intern häufig Anfragen aus, sodass eine effiziente Traffic-Verteilung entscheidend für Performance und Zuverlässigkeit ist. Diese Art des Load Balancing unterstützt außerdem Observability, Sicherheitsrichtlinien und die Traffic-Steuerung zwischen Services.

Relevante Technologien: Kubernetes Service, kube-proxy, Service Mesh, eBPF-basiertes Networking, mTLS, Traffic-Richtlinien, Service Discovery.

Multi-Cluster und globales Load Balancing

Multi-Cluster- und globales Load Balancing verteilen Traffic auf mehrere Kubernetes-Cluster in unterschiedlichen Regionen, Availability Zones, Cloud-Anbietern oder Rechenzentren. Das erhöht die Resilienz, da kein einzelnes Cluster zum Single Point of Failure wird, und kann die Latenz reduzieren, indem Nutzer zum jeweils am besten geeigneten Standort geleitet werden. Häufige Einsatzszenarien sind Disaster Recovery, globale Anwendungen und groß angelegte Deployments.

Relevante Technologien: Gateway API, globales Load Balancing, DNS-basiertes Traffic-Routing, Multi-Cluster-Networking, Service Mesh, Traffic-Failover, Geo-Routing.

Beispiele für Kubernetes Load Balancing

Die Beispiele in diesem Abschnitt basieren auf der Kubernetes-Dokumentation.

Beispiel: Kubernetes Service

Das folgende Deployment erstellt drei Replikate einer NGINX-Anwendung. Jeder Pod trägt das Label app: nginx, sodass ein Kubernetes Service die Pods auswählen und Traffic an sie senden kann.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 10

Dieses Deployment hält drei NGINX-Pods am Laufen. Wird ein Pod gelöscht oder fällt aus, erstellt das ReplicaSet des Deployments einen Ersatz-Pod. Die Readiness Probe hilft Kubernetes zu erkennen, wann jeder Pod bereit ist, Traffic über einen Service zu empfangen.

Beispiel: ClusterIP-Service

Der folgende ClusterIP-Service exponiert das NGINX-Deployment innerhalb des Clusters. Der Service wählt Pods mit dem Label app: nginx aus und leitet Traffic von Port 80 des Services an Port 80 der ausgewählten Pods weiter.

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Dieser Service ist von innerhalb des Clusters erreichbar. Andere Pods können sich über den Service-Namen nginx-clusterip mit ihm verbinden, sofern Cluster-DNS verfügbar ist.

Beispiel: LoadBalancer-Service

Der folgende Service exponiert dieselben NGINX-Pods nach außen – über einen Cloud-Anbieter oder eine andere Umgebung, die externe Load Balancer unterstützt.

apiVersion: v1
kind: Service
metadata:
  name: nginx-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

Wird dieser Service in einer unterstützten Umgebung erstellt, stellt Kubernetes einen externen Load Balancer bereit bzw. konfiguriert ihn und hinterlegt die externe Adresse im Service-Status. Traffic an die externe Adresse wird an den Service und anschließend an die passenden Backend-Pods weitergeleitet.

Beispiel: Ingress

Der folgende Ingress leitet HTTP-Traffic für example.com an den internen Service nginx-clusterip weiter.

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

Dieser Ingress definiert HTTP-Routing-Regeln, funktioniert aber nur, wenn ein Ingress-Controller im Cluster läuft. Der Ingress-Controller setzt das Routing-Verhalten um und leitet passende Anfragen an den Backend-Service weiter.

Beispiel: API Gateway

Das folgende Beispiel nutzt die Kubernetes Gateway API, um HTTP-Traffic über ein Gateway an den internen Service nginx-clusterip zu leiten. Gateway API ist eine Kubernetes-Netzwerk-API-Familie für die dynamische Bereitstellung von Infrastruktur und erweitertes Traffic-Routing. HTTPRoute-Ressourcen können HTTP-Anfragen zuordnen und an Kubernetes-Services weiterleiten.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: nginx-gateway
spec:
  gatewayClassName: nginx
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      hostname: api.example.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: nginx-api-route
spec:
  parentRefs:
    - name: nginx-gateway
  hostnames:
    - api.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: nginx-clusterip
          port: 80

In diesem Beispiel repräsentiert das Gateway den Einstiegspunkt des API Gateways, während die HTTPRoute definiert, wie HTTP-Anfragen geroutet werden. Anfragen an api.example.com/api werden vom Gateway-Listener angenommen, von der Route zugeordnet und an den Service nginx-clusterip weitergeleitet. Der Service verteilt den Traffic dann auf die passenden NGINX-Pods.

Hinweis: Dieses Beispiel verwendet NGINX Gateway Fabric als Gateway-Class-Implementierung – nicht zu verwechseln mit dem Community-gepflegten Ingress-NGINX-Controller.

Dieser Ansatz ähnelt Ingress, doch Gateway API bietet ein ausdrucksstärkeres, rollenorientiertes Modell. Infrastrukturteams können Gateway-Ressourcen verwalten, während Anwendungsteams Route-Ressourcen wie HTTPRoute pflegen. Das macht es besonders nützlich für API-Gateway-Muster, bei denen Teams hostbasiertes Routing, pfadbasiertes Routing, Traffic-Richtlinien und eine saubere Trennung zwischen Plattformkonfiguration und Anwendungs-Routing benötigen.