Skip to content
NeuralSkills
Bereitstellung

Kubernetes-Problemloeser

Kubernetes-Pods, Services und Netzwerkprobleme debuggen — von CrashLoopBackOff bis zu mysterioesen Verbindungs-Timeouts.

Experte Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Kubernetes ist maechtig, aber undurchsichtig. Wenn ein Pod in CrashLoopBackOff feststeckt, ein Service 502er zurueckgibt oder die Inter-Pod-Kommunikation lautlos versagt, ist die Debugging-Oberflaeche enorm. Sie muessen Pod-Logs, Events, Ressourcen-Limits, Readiness-Probes, Netzwerk-Policies, Service-Selektoren, Ingress-Regeln und DNS-Aufloesung pruefen — oft alles gleichzeitig. Die meisten Entwickler verschwenden Stunden mit planlosen kubectl-Befehlen ohne systematischen Ansatz.

Der Prompt

Du bist ein Kubernetes-Debugging-Spezialist. Hilf mir dieses K8s-Problem zu diagnostizieren und zu beheben.

SYMPTOME:
[Beschreibe was passiert — z.B. "Pod startet alle 30 Sekunden neu", "Service gibt 502 zurueck", "Keine Verbindung zwischen Services moeglich"]

CLUSTER-INFO:
- K8s-Version: [z.B. 1.29]
- Plattform: [z.B. EKS, GKE, AKS, Minikube, k3s]
- Namespace: [z.B. production, default]

RELEVANTE AUSGABE (alles Verfuegbare einfuegen):
- kubectl describe pod [name]: [Ausgabe einfuegen]
- kubectl logs [name]: [Ausgabe einfuegen]
- kubectl get events: [Ausgabe einfuegen]

Fuehre eine systematische Diagnose durch:
1. **Symptom-Klassifizierung**: Kategorisiere das Problem (Scheduling, Runtime, Netzwerk, Ressourcen, Konfiguration).
2. **Diagnose-Befehle**: Liste die exakten kubectl-Befehle auf, die ich ausfuehren soll, nach Prioritaet geordnet.
3. **Ursachenanalyse**: Identifiziere basierend auf den Symptomen die 3 wahrscheinlichsten Grundursachen.
4. **Loesung pro Ursache**: Liefere den exakten YAML-Patch oder kubectl-Befehl zur Behebung jeder potentiellen Ursache.
5. **Verifikation**: Wie bestaetigt wird, dass die Loesung funktioniert.
6. **Praevention**: Was zu Manifests hinzugefuegt werden sollte, um diese Problemklasse zu verhindern.

Beispielausgabe

Symptom: CrashLoopBackOff — klassifiziert als RUNTIME-Problem
Diagnose: kubectl logs pod/api-7d8f --previous (letzte Crash-Ausgabe pruefen)
Ursache #1 (70%): OOMKilled — Container-Memory-Limit 256Mi zu niedrig fuer Node.js-Heap
  Loesung: kubectl patch deploy api -p '{"spec":{"template":{"spec":{"containers":[{"name":"api","resources":{"limits":{"memory":"512Mi"}}}]}}}}'
Ursache #2 (20%): Fehlende Umgebungsvariable verursacht Startup-Crash
  Loesung: kubectl set env deploy/api DATABASE_URL=postgresql://...
Verifikation: kubectl rollout status deploy/api && kubectl get pods -w

Wann einsetzen

Verwenden Sie diesen Skill wenn eine Kubernetes-Ressource sich nicht wie erwartet verhaelt — Pods starten nicht, Services routen nicht, Persistent Volumes mounten nicht oder Autoscaling greift nicht. Unverzichtbar bei Produktions-Incidents, wenn Sie einen strukturierten Ansatz statt zufaelliger kubectl-Befehle benoetigen.

Profi-Tipps

  • Pruefen Sie immer zuerst Events — kubectl get events --sort-by=.lastTimestamp -n <namespace> zeigt die Zeitleiste dessen, was Kubernetes versucht hat und wo es gescheitert ist.
  • Nutzen Sie --previous fuer abgestuerzte Pods — kubectl logs <pod> --previous zeigt die Logs der letzten Container-Instanz vor dem Crash, wo der tatsaechliche Fehler steckt.
  • Netzwerk-Debugging mit ephemeren Containern — kubectl debug -it <pod> --image=nicolaka/netshoot haengt einen Debug-Container mit curl, dig, nslookup und tcpdump an, ohne die Pod-Spec zu aendern.
  • Describe ist nuetzlicher als get — kubectl describe pod zeigt Events, Conditions und Ressourcen-Details, die kubectl get pod -o yaml im Rauschen vergaebt.