Begriff

LoadBalancer (K8s Service)

Kubernetes Networking S2

2 Quellen 0 Lernpfade 0 Backlinks enriched

Warum wichtig?

Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.

Du hast deine App im Cluster. Du willst, dass echte Menschen aus dem Internet sie erreichen. ClusterIP geht nur intern. NodePort ist hässlich (Port 30000+). Der LoadBalancer Service ist der Luxus-Weg. Du sagst Kubernetes: "Ich brauche eine echte, öffentliche IP-Adresse." Kubernetes ruft (wenn es in der Cloud läuft) bei AWS/Google/Azure an: "Hey, gib mir einen Cloud Load Balancer!" AWS erstellt einen echten Load Balancer, gibt dir eine echte IPv4 (35.1.2.3) und leitet Traffik von dort in deinen Cluster weiter. Es ist der einfachste Weg nach draußen ("Expose").

Merksatz: Ein Kubernetes-Service-Typ, der einen externen Load Balancer des Cloud-Providers provisioniert, um Traffic aus dem Internet auf die Knoten und Pods des Clusters zu verteilen.

YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 8080
  type: LoadBalancer

Nach kubectl apply steht bei EXTERNAL-IP erst <pending>. Nach 1-2 Minuten steht dort die öffentliche IP. Jeder auf der Welt kann nun http://<IP> aufrufen.

1. ExternalTrafficPolicy: Local

Standardmäßig (Cluster) kommt das Paket am Load Balancer an, geht zu irgendeinem Node, und von dort per kube-proxy (SNAT) zu irgendeinem Pod (auch auf einem anderen Node). Nachteil: Die echte User-IP geht verloren (du siehst nur die interne Node-IP im Log). Lösung: externalTrafficPolicy: Local. Der Load Balancer schickt Pakete nur an Nodes, die auch wirklich einen Pod haben. Kein Hopping, kein SNAT. Vorteil: Echte Client-IP erhalten. Nachteil: Schlechtes Balancing (wenn Node A 1 Pod hat und Node B 9 Pods haben, kriegt Node A 50% Traffic und ist überlastet, weil LB nur Nodes zählt).

2. MetalLB (Bare Metal)

Auf deinem eigenen Server im Keller (On-Premise) gibt es keinen "AWS Cloud API". Wenn du type: LoadBalancer setzt, bleibt der Status für immer auf <pending>. Lösung: MetalLB. Das ist ein Software-LB im Cluster. Er nutzt ARP (Layer 2) oder BGP (Layer 3), um deinem Router zu sagen: "Hey, die IP 192.168.1.50 gehört jetzt mir (diesem Node)!" Damit kriegst du LoadBalancer-Feeling auch ohne Cloud.

3. Kosten & L4 vs L7

Jeder Service LoadBalancer kostet Geld (ca. 20€/Monat in AWS). Wenn du 50 Microservices hast, wirst du arm (1000€). Ein LoadBalancer (Service) arbeitet auf Layer 4 (TCP). Er versteht keine URLs (/shop). Deshalb nutzt man meistens:

Einen LoadBalancer für den Ingress Controller.
Der Ingress (Layer 7) verteilt dann per Hostanme (shop.de) an die 50 Services (die nur ClusterIP haben). Kosten: 20€ für alles.

Der Cloud Controller Manager (CCM)

Woher weiß Kubernetes überhaupt, wie es mit der AWS-API redet? Kubernetes selbst baut keine LoadBalancer-Klassen für 300 verschiedene Hoster. Dies ist Aufgabe des Cloud Controller Manager (früher harcodiert im Kube-Controller-Manager, heute "Out-of-Tree"). Es ist ein dezidierter Pod (z. B. aws-cloud-controller-manager), der die Cloud-spezifischen Berechtigungen (IAM) besitzt. Wenn du type: LoadBalancer erstellst, triggert der Kube-APIServer ein Event. Der CCM horcht darauf, führt die asynchronen AWS API-Calls (CreateLoadBalancer) aus, wartet auf die AWS-DNS-Propagierung und patcht abschließend das K8s-Service-Objekt mit dem Feld status.loadBalancer.ingress.hostname.

Hairpinning / Loopback Routing

Ein oft bizarres Netzwerk-Phänomen: Ein Pod im Cluster möchte über die öffentliche LoadBalancer-IP auf einen anderen Service zugreifen, der im selben Cluster läuft (z.B. Frontend pingt ans Backend, ruft aber blind die AWS DNS des Backends auf). Das Paket verlässt den Cluster-Node in Richtung AWS LoadBalancer, der dreht es um 180 Grad und schickt es zurück ("Hairpin") – oftmals auf denselben Node. Bösartige Setups verwerfen diese Pakete (MAC-Spoofing Protection oder asymmetrisches Routing im Cloud-Provider). Kubernetes und CNI-Plugins (wie Calico) sind gezwungen, tief im iptables/eBPF-Stack eine Hairpin-NAT (SNAT zurück zur NodeIP) zu betreiben, damit interne Pods die externen LoadBalancer-IPs ihrer eigenen Kollegen fehlerfrei ansprechen können, ohne das Paket wirklich ins physikalische AWS-Internet routen zu müssen.

On-Premise: MetalLB und BGP (Border Gateway Protocol)

Wer MetalLB in echten Rechenzentren einsetzt und über ARP hinaus ist, nutzt BGP. Der Knoten ruft beim Cisco/Juniper Core-Router des RZs an und macht Router-"Peering" auf Layer 3. Er propagiert: "Hier ist die Route für IP 10.40.40.40 (LoadBalancer IP). Alle Bits, die für sie bestimmt sind, sendet bitte physikalisch an Node 1". Fällt Node 1 aus (Hardware crasht), entzieht MetalLB die Route in Nanosekunden beim Core-Router (BGP Session Drop) und Node 2 übernimmt das Announcement ("IP 10.40.40.40 ist jetzt bei mir"). Die Ausfallsicherheit ist dadurch exakt so robust wie bei Internet-Service-Providern (Internet Backbone Routing).

Quick-Check

Was ist der Unterschied zu NodePort?
LoadBalancer baut auf NodePort auf. AWS routet Traffic an NodeIP:NodePort. Aber für den User ist es unsichtbar, er sieht nur die schöne LB-IP auf Port 80.
Kann ich UDP balancen?
Ja, die meisten Clouds unterstützen das (z. B. für Game Server oder DNS). Ingress (HTTP) kann das meist nicht.
Finalizers?
Wenn du den Service löschst, muss auch der AWS Load Balancer gelöscht werden (sonst zahlst du weiter!). Kubernetes nutzt "Finalizers", um sicherzustellen, dass erst die Cloud-Resource weg ist, bevor das K8s-Objekt verschwindet. Wenn LBs "hängen" bleiben, check die Finalizer!