# Kubernetes Services: Vernetzung & Load Balancing im Cluster

TL;DR / Management Summary In Kubernetes sind Pods (Artikel 812) vergänglich und erhalten bei jedem Neustart eine neue IP. Services bieten eine stabile Abstraktionsebene: Ein Service hat eine feste IP (ClusterIP) und einen Namen, über den eine Gruppe von Pods dauerhaft erreichbar bleibt. Ein Senior Admin nutzt Services, um internen Traffic zu balancieren und bindet via LoadBalancer oder Ingress externe Clients (z.B. über die OPNsense Firewall) sicher an die Applikation an.

# 1. Die drei Service-Typen

Interne vs. externe Erreichbarkeit.

ClusterIP (Standard): Der Dienst erhält eine IP, die nur innerhalb des Clusters erreichbar ist. (Ideal für Datenbanken).
NodePort: Öffnet einen Port (30000-32767) auf jedem einzelnen physischen Proxmox-Knoten. (Nur für Tests empfohlen).
LoadBalancer: Kommuniziert mit Ihrer Cloud-Plattform oder OPNsense (via Metallb), um eine echte, externe IP für den Dienst zu reservieren.

# 2. Wie Services ihre Pods finden

Das Label-Selector Prinzip.

Ein Service “klebt” nicht an einer VM, sondern sucht dynamisch nach Labels.

Selector: app: web.
Aktion: Jedes Paket, das an den Service geschickt wird, wird vom kube-proxy automatisch an einen der Pods verteilt, der das Label app: web trägt.
Vorteil: Wenn ein Pod abstürzt und neu startet, wird er automatisch wieder in den Service-Pool aufgenommen.

# 3. Deep Dive: Ingress Controller

Der intelligente Türsteher.

LoadBalancer-IPs sind teuer und unflexibel.

Lösung: Ingress.
Funktion: Ein einziger Einstiegspunkt (Port 80/443), der den Traffic basierend auf dem Hostnamen (api.firma.de) oder dem Pfad (/v1) an verschiedene Services im Cluster leitet.
Empfehlung: Nutzen Sie den Nginx Ingress Controller oder Traefik.

# 4. Day-2 Operations: Service Mesh (Linkerd/Istio)

Sichtbarkeit im Ost-West-Traffic.

Wenn Ihr Cluster aus hunderten Services besteht, brauchen Sie mehr als nur Loadbalancing.

Service Mesh: Fügt jedem Pod einen winzigen Proxy (Sidecar) hinzu.
Vorteil: Automatische mTLS-Verschlüsselung zwischen allen Services und detailliertes Tracing (Wer spricht wie lange mit wem?).

# 5. Troubleshooting & “War Stories”

Wenn der Service stumm bleibt.

# Top 3 Fehlerbilder

Symptom: “Connection Refused” beim Aufruf des Service-Namens.
- Ursache: Der targetPort im Service stimmt nicht mit dem containerPort im Deployment überein.
- Lösung: YAML-Dateien abgleichen.
Symptom: Service ist da, aber keine “Endpoints” gelistet.
- Ursache: Der Selector findet keine Pods (Tippfehler im Label).
- Check: kubectl get endpoints <service_name>.
Symptom: Unbalanced Traffic. Ein Pod bekommt 90% der Anfragen.
- Fix: Prüfen Sie das Session-Affinity Setting (ClientIP vs None).

# “War Story”: Der “ARP-Storm” durch MetalLB

Ein Admin konfigurierte MetalLB im Layer-2 Modus auf einem Proxmox-Cluster (Artikel 678). Das Ereignis: Plötzlich war der gesamte Core-Switch blockiert. Die Ursache: Da MetalLB die IP-Übernahme via ARP-Spoofing (Gratuitous ARP) simuliert, lösten 50 neue Services gleichzeitig tausende ARP-Pakete aus. Der Switch sah dies als Angriff und schaltete die Ports ab. Lehre: Nutzen Sie für produktive Cluster im LAN den BGP-Modus von MetalLB (Artikel 572). Es ist deutlich stabiler und wird von Enterprise-Hardware nativ unterstützt.

# 6. Monitoring & Reporting

Traffic-Statistiken.

# Service Metrics

Überwachen Sie via Prometheus (Artikel 646):

kubernetes_service_created_timestamp.
service_mesh_request_count. (Erfordert Istio/Linkerd).

# 7. Fazit & Empfehlung

Services sind die logische IP-Infrastruktur von Kubernetes.

Empfehlung: Nutzen Sie ClusterIP für alles Interne und Ingress für alles Externe.
Wichtig: Verwenden Sie aussagekräftige Namen. In K8s ist der DNS-Name (my-svc.my-namespace.svc.cluster.local) wichtiger als die IP-Adresse.

# Anhang: Cheatsheet (kubectl service)

Aufgabe	Befehl
Alle Services	`kubectl get svc -A`
Endpoints prüfen	`kubectl get ep <service>`
Service erstellen (CLI)	`kubectl expose deploy <name> --port=80`
Details ansehen	`kubectl describe svc <name>`