Kubernetes Netzwerk debuggen mit externem Pod (kubectl run)

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. busybox oder nicolaka/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-debug

B) 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-debug

C) “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 wide

Jetzt 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 echo blocken

cat <<'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: []
EOF

Jetzt sollte der Zugriff auf echo scheitern.

2) Selektiv wieder erlauben – nur von app auf Port 8080

cat <<'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
EOF

Danach 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 -- sh

Damit 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 8080

Wenn 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-debug

FAQ

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 !