Loadbalancer: HAProxy Kubernetes Ingress Controller im Test

Inhaltsverzeichnis

Pods respektive Container bilden in einem Kubernetes-Cluster ein eigenes Universum, das mit privaten IP-Adressen von der Außenwelt abgeschirmt ist. Da man neben den Kubernetes-Infrastrukturdiensten auch Workloads betreibt, die von außerhalb des Clusters erreichbar sein sollen, muss dafür eine Lösung her. Der Weg führt zunächst über Services, die in Kubernetes eine stabile Abstraktion für die flüchtigen Pods bieten: Auch wenn ein Pod einen anderen ersetzt und sich damit etwa die IP-Adresse ändert, bleibt die Konfiguration des Service erhalten, sodass die in den Pods laufenden Dienste von außen unter derselben Adresse erreichbar sind – zumindest innerhalb des Clusters.

Kubernetes-Services kennen vier Arten, ihre Dienste anzubieten: ClusterIP, NodePort, LoadBalancer und ExternalName. ClusterIP ist der Default und darauf beschränkt, innerhalb des Clusters verwendet zu werden. ExternalName ordnet DNS-Namen zu, richtet aber keine Proxyfunktion für die Dienste ein.

Bleiben noch die beiden Ressourcen NodePort und LoadBalancer. Setzen Admins den Servicetyp auf NodePort, ist der entsprechende Dienst über einen statischen Port auf allen Nodes des Kubernetes-Clusters erreichbar. Hinter den Kulissen wird dies mit Layer-4-Routing und iptables (alternativ IPVS) realisiert. Clients müssen dann aber die zugehörigen Node-Adressen und Ports kennen, was die Sache etwas unhandlich macht. Der Servicetyp LoadBalancer wiederum erfordert einen externen Loadbalancer-Dienst. Läuft Kubernetes bei einem Cloud-Provider wie AWS oder Google, lässt sich hier der passende Dienst des Anbieters verwenden.

Das war die Leseprobe unseres heise-Plus-Artikels "Loadbalancer: HAProxy Kubernetes Ingress Controller im Test". Mit einem heise-Plus-Abo können sie den ganzen Artikel lesen und anhören.