Kubernetes Load Balancing: MetalLB vs. Nginx Ingress vs. Traefik im Vergleich

TL;DR

• Kubernetes hat kein eingebautes Load Balancing fuer Bare-Metal-Cluster. MetalLB schliesst diese Luecke auf Layer 4.
• Nginx Ingress Controller ist der De-facto-Standard fuer Layer-7-Routing: stabil, gut dokumentiert, riesige Community.
• Traefik bietet bessere native Kubernetes-Integration mit IngressRoute CRDs und automatischer Let's Encrypt Integration.
• Fuer die meisten Setups brauchst du MetalLB PLUS einen Ingress Controller. Sie ergaenzen sich, sie ersetzen sich nicht.
• In Cloud-Umgebungen (AKS, EKS, GKE) faellt MetalLB weg -- der Cloud Load Balancer uebernimmt Layer 4.

Warum Load Balancing auf Kubernetes nicht trivial ist

Wer zum ersten Mal einen Kubernetes-Service mit type: LoadBalancer auf einem Bare-Metal-Cluster anlegt, erlebt eine Ueberraschung: Der Service bleibt im Status Pending. Kubernetes selbst hat keine Implementierung fuer externe Load Balancer. In der Cloud uebernehmen AWS ELB, Azure LB oder GCP LB diese Rolle automatisch. Auf eigener Hardware brauchst du eine Loesung.

Hinzu kommt die Frage, auf welcher Schicht du den Traffic verteilst. Layer 4 (TCP/UDP) ist schnell und einfach, kann aber nicht nach HTTP-Pfaden oder Hostnamen routen. Layer 7 (HTTP/HTTPS) bietet feingranulares Routing, TLS-Terminierung und Middleware-Funktionen, kostet aber mehr CPU.

Die meisten Produktions-Setups brauchen beides: Layer 4 am Eingang und Layer 7 dahinter.

Die drei Optionen im Ueberblick

MetalLB: Layer 4 fuer Bare-Metal-Cluster

MetalLB laeuft als DaemonSet im Cluster und reagiert auf ARP-Requests (Layer 2) oder nutzt BGP, um externe IP-Adressen fuer Services vom Typ LoadBalancer zu annoncieren.

Layer-2-Modus ist einfacher einzurichten. Ein einzelner Node wird Leader fuer eine IP und beantwortet ARP-Requests. Nachteil: Single Point of Failure auf Node-Ebene und keine echte Lastverteilung, weil der gesamte Traffic ueber einen Node laeuft. Failover dauert einige Sekunden.

BGP-Modus erfordert einen BGP-faehigen Router im Netzwerk, verteilt den Traffic aber wirklich ueber mehrere Nodes und bietet schnelleren Failover. Fuer Produktionsumgebungen die bessere Wahl.

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: production-pool
  namespace: metallb-system
spec:
  addresses:
    - 10.0.100.50-10.0.100.60
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: production-l2
  namespace: metallb-system
spec:
  ipAddressPools:
    - production-pool
  interfaces:
    - eth0

Dieses Setup reserviert 11 IP-Adressen fuer LoadBalancer-Services und annonciert sie per ARP auf dem Interface eth0. Sobald du jetzt einen Service mit type: LoadBalancer anlegst, bekommt er eine IP aus diesem Pool.

Fuer BGP-Modus ersetzt du L2Advertisement durch BGPAdvertisement und konfigurierst einen BGPPeer mit der IP und ASN deines Routers. Die MetalLB-Doku hat dafuer gute Beispiele.

Nginx Ingress Controller

Der Nginx Ingress Controller ist der meistgenutzte Ingress Controller im Kubernetes-Oekosystem. Er basiert auf Nginx und wird per Annotations auf Ingress-Ressourcen konfiguriert.

Installation per Helm:

# Namespace anlegen
kubectl create namespace ingress-nginx

# Helm Repository hinzufuegen
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

# Installation mit sinnvollen Defaults
helm install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx \
  --set controller.replicaCount=2 \
  --set controller.resources.requests.cpu=100m \
  --set controller.resources.requests.memory=128Mi \
  --set controller.metrics.enabled=true \
  --set controller.metrics.serviceMonitor.enabled=true \
  --set controller.config.use-forwarded-headers="true" \
  --set controller.config.proxy-body-size="50m"

Eine typische Ingress-Ressource mit TLS und Rate Limiting:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  namespace: production
  annotations:
    nginx.ingress.kubernetes.io/rate-limit: "100"
    nginx.ingress.kubernetes.io/rate-limit-window: "1m"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "30"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - api.example.com
      secretName: api-tls-cert
  rules:
    - host: api.example.com
      http:
        paths:
          - path: /v1
            pathType: Prefix
            backend:
              service:
                name: api-v1
                port:
                  number: 80
          - path: /v2
            pathType: Prefix
            backend:
              service:
                name: api-v2
                port:
                  number: 80

Die Staerke von Nginx Ingress liegt in der Breite der Annotations. Du kannst CORS, Basic Auth, Custom Headers, Rewrite Rules und Canary Deployments rein ueber Annotations konfigurieren, ohne die zentrale Nginx-Config anfassen zu muessen. Fuer Canary-Strategien im Detail siehe /blog/kubernetes-canary-deployment-deutschland.

Traefik als Alternative

Traefik verfolgt einen anderen Ansatz. Statt Annotations auf Standard-Ingress-Ressourcen nutzt es Custom Resource Definitions (IngressRoute, Middleware), die ausdruecklicher und lesbarer sind.

Die Killer-Features von Traefik sind:

Automatische TLS-Zertifikate: Traefik kann Let's Encrypt Zertifikate automatisch beantragen und erneuern, ohne dass du cert-manager brauchst. Das reduziert eine Abhaengigkeit.

Middleware als eigene Ressource: Rate Limiting, IP Whitelisting, Header Manipulation -- alles wird als separate Kubernetes-Ressource definiert und kann zwischen Routen wiederverwendet werden.

Eingebautes Dashboard: Traefik bringt ein Web-Dashboard mit, das alle Routen, Services und Middleware visualisiert. Fuer Debugging extrem praktisch.

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: rate-limit
  namespace: production
spec:
  rateLimit:
    average: 100
    burst: 50
    period: 1m
---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
  name: app-route
  namespace: production
spec:
  entryPoints:
    - websecure
  routes:
    - match: Host(`api.example.com`) && PathPrefix(`/v1`)
      kind: Rule
      middlewares:
        - name: rate-limit
      services:
        - name: api-v1
          port: 80
    - match: Host(`api.example.com`) && PathPrefix(`/v2`)
      kind: Rule
      middlewares:
        - name: rate-limit
      services:
        - name: api-v2
          port: 80
  tls:
    certResolver: letsencrypt

Der Nachteil von Traefik: Weniger Drittanbieter-Dokumentation und Tutorials als Nginx Ingress. Wenn du ein Problem googelst, findest du fuer Nginx Ingress zehnmal mehr Stack-Overflow-Antworten.

Wann welche Loesung?

Die Entscheidung haengt von drei Faktoren ab: Infrastrukturtyp, Team-Erfahrung und Anforderungen.

Bare Metal, einfaches Setup: MetalLB (L2) + Nginx Ingress. Schnell eingerichtet, gut dokumentiert, funktioniert zuverlaessig.

Bare Metal, Produktion mit hohen Anforderungen: MetalLB (BGP) + Nginx Ingress oder Traefik. BGP gibt dir echte Lastverteilung auf Layer 4, der Ingress Controller kuemmert sich um Layer 7.

Cloud (AKS, EKS, GKE): Kein MetalLB noetig. Der Cloud-native LoadBalancer uebernimmt Layer 4. Nginx Ingress oder Traefik fuer Layer 7. Manche Teams nutzen auch den Cloud-spezifischen Ingress (z.B. AWS ALB Ingress Controller), aber das bindet dich staerker an einen Anbieter.

Viele Services, viele Teams: Traefik mit IngressRoute CRDs, weil die Konfiguration expliziter ist und Middleware wiederverwendet werden kann. Bei Nginx Ingress werden die Annotations bei komplexen Setups schnell unuebersichtlich.

Fuer einen tieferen Vergleich von Netzwerk-Optionen in Kubernetes siehe /blog/kubernetes-network-policies-advanced.

Performance-Ueberlegungen

Ingress Controller werden schnell zum Bottleneck, wenn du nicht aufpasst. Hier ein paar Zahlen und Tipps:

Nginx Ingress schafft auf einem einzelnen Pod mit 1 CPU ca. 10.000-15.000 Requests/Sekunde fuer einfache Proxy-Forwards. Mit TLS-Terminierung sinkt das auf ca. 5.000-8.000 Requests/Sekunde. Traefik liegt in aehnlichen Bereichen.

Skalierungstipps:

• Setze controller.replicaCount auf mindestens 2 fuer Hochverfuegbarkeit.
• Nutze topologySpreadConstraints, damit die Replicas auf verschiedenen Nodes laufen.
• Aktiviere Keepalive-Connections zum Backend (nginx.ingress.kubernetes.io/upstream-keepalive-connections: "32").
• Fuer sehr hohe Last: Nimm den Ingress Controller aus dem Cluster-Netzwerk raus und nutze hostNetwork: true -- das spart einen Netzwerk-Hop, erfordert aber dedizierte Nodes.

Mehr zu Performance-Optimierung findest du unter /blog/kubernetes-performance-optimization-deutschland.

Monitoring

Sowohl Nginx Ingress als auch Traefik exportieren Prometheus-Metriken. Die wichtigsten Metriken, die du ueberwachen solltest:

Fuer Traefik heissen die Metriken anders (traefik_entrypoint_requests_total, traefik_service_request_duration_seconds_bucket), aber das Prinzip ist identisch.

Ein vollstaendiges Monitoring-Setup mit Prometheus und Grafana beschreiben wir in /blog/kubernetes-observability-stack-deutschland.

Haeufige Fehler

Kein Health Check am Backend: Wenn Nginx Ingress den Traffic an einen Pod schickt, der gerade startet, bekommt der User einen 502. Konfiguriere Readiness Probes an deinen Pods und setze nginx.ingress.kubernetes.io/proxy-next-upstream: "error timeout http_502".

TLS-Zertifikat laeuft ab: Cert-manager oder Traefik's Let's Encrypt Resolver koennen fehlschlagen, ohne dass es jemand merkt. Ueberwache certmanager_certificate_expiration_timestamp_seconds und alerte 14 Tage vor Ablauf.

MetalLB L2 und multiple Ingress Replicas: Im L2-Modus geht der gesamte Traffic ueber einen Node. Wenn dein Ingress Controller 3 Replicas hat, aber alle auf verschiedenen Nodes laufen, muessen 2 von 3 Replicas ihren Traffic ueber das Cluster-Netzwerk empfangen. In diesem Fall ist externalTrafficPolicy: Local kontraproduktiv. Nutze BGP oder setze die Ingress Replicas auf den Leader-Node.

Fazit

Es gibt keine One-Size-Fits-All-Loesung fuer Kubernetes Load Balancing. MetalLB, Nginx Ingress und Traefik decken unterschiedliche Schichten ab und ergaenzen sich. Starte mit dem einfachsten Setup, das deine Anforderungen erfuellt, und erweitere schrittweise.

Fuer die meisten Teams ist die Kombination MetalLB (L2 oder BGP) plus Nginx Ingress Controller ein solider Startpunkt. Wenn du mehr Flexibilitaet bei der Konfiguration brauchst oder Let's Encrypt ohne cert-manager willst, schau dir Traefik an.

Falls du Unterstuetzung bei der Netzwerk-Architektur deines Clusters brauchst, nimm Kontakt mit uns auf unter /kontakt.