Pods kommen und gehen — ein Service gibt deiner App eine stabile Adresse.
Pods bekommen bei jedem Neustart eine neue IP. Du kannst dich also nie auf eine Pod-IP verlassen. Die Lösung: ein Service — eine feste Adresse mit eingebautem Load-Balancer vor deinen Pods.
Genau wie das Deployment nutzt der Service einen Selector: „schick Verkehr an alle Pods
mit app=web“. Pods dürfen sterben und neu entstehen — solange das Label stimmt, leitet der Service weiter.
apiVersion: v1
kind: Service
metadata:
name: web
namespace: lernen
spec:
selector:
app: web # trifft die Pods aus Lektion 4
ports:
- port: 80 # Port DES SERVICE (so rufst du ihn)
targetPort: 80 # Port IM CONTAINER (dorthin leitet er)port = Klingelschild (woran man klopft). targetPort = die Tür dahinter (wo der Container lauscht). Verwechslung der beiden ist der Service-Klassiker.
| Typ | Erreichbar von | Wofür |
|---|---|---|
| ClusterIP | nur clusterintern | Default; App-zu-App im Cluster |
| NodePort | Port jedes Nodes (außen) | einfacher externer Zugang / Homelab |
| LoadBalancer | externe IP | Produktion (Cloud / MetalLB im Homelab) |
port-forward
Du musst einen Service nicht nach außen öffnen, um ihn zu testen. port-forward legt
einen lokalen Port sicher auf den Service/Pod — nur für dich, nur solange der Befehl läuft.
# Service anlegen (Manifest aus Schritt 1 als svc.yaml)
kubectl apply -f svc.yaml
# Lokalen Port 8080 auf den Service legen (läuft im Vordergrund)
kubectl port-forward -n lernen svc/web 8080:80
# In einem zweiten Terminal:
curl http://localhost:8080Es öffnet nichts dauerhaft und ändert nichts am Cluster. Schließt du den Befehl (Ctrl-C), ist der Zugang wieder zu. Ideal, um „läuft die App überhaupt?“ zu prüfen, bevor du Netzwerk-Themen debuggst.
kubectl get svc -n lernen
kubectl describe svc web -n lernen # Endpoints: zeigt die getroffenen Pods
kubectl get endpoints web -n lernen # leer? → Selector passt nicht zu den Pod-Labels!Merke fürs Debuggen: leere Endpoints = Selector trifft keine Pods. Häufigster Service-Fehler.
kubectl port-forward?