ClusterIP

In YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-backend
spec:
  selector:
    app: backend-app  # Ziel-Pods
  ports:
    - port: 80        # Port der ClusterIP
      targetPort: 8080 # Port im Container
  type: ClusterIP     # Default (muss nicht angegeben werden)

Ergebnis: kubectl get svc zeigt 10.96.x.x. Andere Pods im Cluster können nun http://my-backend (DNS) aufrufen. Kubernetes löst das zu der stabilen IP auf.

1. iptables / IPVS (Wie die Magie funktioniert)

Die ClusterIP existiert nicht auf einer Netzwerkkarte. Du kannst sie nicht pingen (oft). Sie ist eine virtuelle IP. Der kube-proxy (läuft auf jedem Node) schreibt Tausende von iptables Regeln (oder nutzt IPVS): "Wenn Paket an 10.96.0.1:80 geht -> Ändere Ziel-IP zufällig auf eine der Pod-IPs (10.244.1.5, 10.244.2.8)." Das ist Client-Side Load Balancing auf Kernel-Ebene (DNAT).

2. Headless Services

Manchmal willst du kein Load Balancing. Du willst genau Pod Nr. 3 ansprechen (z. B. bei Datenbank-Clustern mit Primary/Replica). Du setzt clusterIP: None. Dann gibt der DNS-Server nicht eine virtuelle IP zurück, sondern eine Liste der echten IPs aller Pods (A-Records). Deine App muss dann selbst entscheiden, wen sie anspricht (Client-Side Logic).

3. Service Discovery & DNS

Kubernetes hat einen eingebauten DNS-Server (CoreDNS). Er überwacht alle Services. Sobald du einen Service db erstellst, können alle Pods db.default.svc.cluster.local auflösen. Die ClusterIP ist der Anker für diesen DNS-Namen.

Endpoints und EndpointSlices

Was viele ignorieren: Der Service (die ClusterIP) routet niemals direkt zu Pods. Kubernetes schaltet ein Zwischenobjekt namens Endpoints (bzw. in neuen Versionen EndpointSlices) dazwischen. Der K8s Controller-Manager überwacht Pods, die den Label-Selector des Services matchen. Wenn ein Pod Ready ist, schreibt er dessen IP in das Endpoint-Objekt. Der kube-proxy auf jedem Node beobachtet wiederum nur die Endpoint-Objekte und baut daraus die Routing-Tabellen. Vorteil: Du kannst Services ohne Selector erstellen und die Endpoints manuell pflegen (z. B. um eine ClusterIP auf eine externe Legacy-Datenbank-IP außerhalb des Clusters zu leiten).

iptables vs. IPVS Mode

Aus historischen Gründen nutzt kube-proxy standardmäßig iptables. Bei 10 Services ist das großartig. Bei 10.000 Services (Enterprise K8s) explodiert die iptables-Regelkette. Jedes neue Paket an eine ClusterIP muss sequenziell durch tausende PREROUTING-Regeln iterieren, bis es einen Match findet ($O(N)$ Aufwand). Moderne Cluster wechseln den kube-proxy in den IPVS (IP Virtual Server) Mode. IPVS baut im Linux-Kernel direkt auf Netfilter auf, nutzt aber Hash-Tabellen für das Routing ($O(1)$). Zudem bietet es fortschrittlichere Loadbalancing-Algorithmen (Least Connections, Weighted Round Robin) statt des reinen iptables-Zufallsprinzips.

Kube-Proxy Bottlenecks und eBPF (Cilium)

Die "ClusterIP" ist eigentlich ein massiver Flaschenhals, weil jedes Paket tief in den Linux-Host-Netzwerk-Stack (Netfilter) muss, modifiziert wird (DNAT), und dann weiter geroutet wird. High-Performance Cluster (wie Cilium CNI) schalten kube-proxy komplett ab ("Kube-Proxy replacement"). Sie nutzen eBPF (Extended Berkeley Packet Filter). Die Routing-Logik der ClusterIP wird direkt dynamisch in den Kern des Linux-Kernels kompiliert und früh im Socket-Layer (SockOps) abgefangen. Ein Service-zu-Service-Aufruf passiert dadurch rasend schnell unter Umgehung des traditionellen TCP/IP Stacks.