Kubernetes Netzwerk debuggen mit externem Pod (kubectl run)
Warum ist Netzwerk-Debugging in Kubernetes so ein Pain?
Ganz ehrlich: Wenn ein Pod läuft, aber keiner rankommt – dann ist die Laune im Keller. Kubernetes fühlt sich in solchen Momenten wie eine Black Box an. Logs helfen nicht, kubectl describe spuckt nichts Brauchbares aus – und du drehst dich im Kreis. Netzwerkfehler sind der tägliche Grind in jedem Cluster.
Kurzantwort
Mit einem externen Test-Pod kannst du von außen prüfen, ob deine Services erreichbar sind. Das geht mit kubectl run – und schon hast du ein schlankes BusyBox-Containerchen im Cluster, das du zum Pingen, Curlen und Testen nutzen kannst. Ergebnis: Du siehst sofort, wo der Haken ist.
Anwendungssituation
Stell dir vor: Dein Service rennt, das Deployment ist grün – aber von außen kommt nix an. Entwickler sagen: „Bei mir lokal läuft’s“. Du stehst zwischen Pod, Service und NetworkPolicy und suchst die Nadel im Heuhaufen. Genau hier rettet dich der Test-Pod: einmal starten, Traffic testen, Ursache finden.
Voraussetzungen
- Clusterzugriff mit Rechten zum Erstellen von Pods
- Zugriff auf hub.docker.com, z. B.
busyboxodernicolaka/netshoot - Grundkenntnisse in Pod-Namen, Namespaces, Netzwerkkonzepten (optional)
Übung: Test-Setup bereitstellen (Pod + Service zum Anfassen)
Wir bauen uns eine kleine Spielwiese, damit du alles 1:1 nachklicken kannst.
A) Namespace anlegen
kubectl create ns net-debugB) Ziel-Service deployen (Antwortet auf Port 8080)
kubectl create deployment echo -n net-debug --image=hashicorp/http-echo -- /http-echo -text=hello-from-echo -listen=:8080
kubectl rollout status deploy/echo -n net-debug
kubectl expose deployment echo -n net-debug --port=8080 --target-port=8080 --name=echo-svc
kubectl get svc -n net-debugC) “App”-Pod ohne Tools deployen (hier fehlt absichtlich curl & Co.)
kubectl create deployment app -n net-debug --image=alpine -- sleep infinity
kubectl rollout status deploy/app -n net-debug
kubectl get pods -n net-debug -o wideJetzt haben wir zwei Deployments: echo (Ziel) und app (Quelle zum Testen).
Optional (für Fehler-Demo): Alles dichtmachen und dann gezielt freischalten
1) Eingehenden Traffic auf
echoblockencat <<'EOF' | kubectl apply -n net-debug -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-echo spec: podSelector: matchLabels: app: echo policyTypes: [Ingress] ingress: [] EOFJetzt sollte der Zugriff auf
echoscheitern.2) Selektiv wieder erlauben – nur von
appauf Port 8080cat <<'EOF' | kubectl apply -n net-debug -f - apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-echo-from-app spec: podSelector: matchLabels: app: echo policyTypes: [Ingress] ingress: - from: - podSelector: matchLabels: run: podtest ports: - protocol: TCP port: 8080 EOFDanach sollte der Zugriff wieder funktionieren.
Schritt-für-Schritt-Anleitung
1. Test-Pod starten
kubectl run -it podtest -n net-debug --image=busybox --restart=Never -- shDamit hast du eine interaktive Shell in einem externen Pod, der im gleichen Namespace läuft.
2. Netzwerktools nutzen
# Vom Test-Pod aus:
# 1) DNS auflösen
nslookup echo-svc
# 2) HTTP testen
wget -qO- http://echo-svc:8080/
# 3) Low-Level-Check
telnet echo-svc 8080Wenn du die optionale deny-echo-Policy gesetzt hast, wird wget/telnet jetzt fehlschlagen.
Nach dem Anwenden von allow-echo-from-app sollte der Zugriff wieder klappen.
Aufräumen (Cleanup)
Damit deine Spielwiese wieder weg ist:
kubectl delete ns net-debugFAQ
Was ist der Unterschied zwischen kubectl exec und run?
exec läuft in deinem bestehenden Container. Da fehlen oft die Tools. run startet einen ganz eigenen Pod – perfekt zum Testen der Netzwerkverbindung.
Kann ich den Test-Pod auch in Prod nutzen? Ja, aber vorsichtig. Am besten nur im Notfall und mit klaren RBAC-Rechten.
Welche Images sind empfehlenswert?
Für Basics busybox, für Power-User nicolaka/netshoot.
Let’s Do it (Komm ins Training)
👉 Lust auf mehr Hands-on? Komm’ zu meinem Kubernetes-Networking-Training – mit Live-Cluster, Klartext und Praxis pur !