Kubernetes Incident Triage (Read-Only)

Kubernetes Incident Triage (Schreibgeschützt)

Führt eine schreibgeschützte Triage von Kubernetes Workloads und Namespaces mittels kubectl durch.

Unterstützt:

• Eingabe in natürlicher Sprache (menschlicher Modus)
• Strukturierte JSON-Eingabe (Automatisierungsmodus)

Diese Fertigkeit ändert NIEMALS den Clusterzustand.

---

Werkzeugnutzung

Diese Fertigkeit verwendet ausschließlich cli_execute mit kubectl-Befehlen. Verwenden Sie NIEMALS http_request oder web_search, um mit Kubernetes zu interagieren. Alle Cluster-Operationen MÜSSEN über kubectl mittels des cli_execute-Werkzeugs erfolgen.

---

Werkzeug: k8s_triage

Diagnostiziert nicht gesunde Kubernetes-Workloads, Pods oder Namespaces.

---

Eingabemodi

1) Menschlicher Modus (natürliche Sprache)

Die Eingabe ist eine einfache Zeichenfolge.

Beispiele:

• triage payments-prod
• triage deployment payments-api in payments-prod
• warum sind pods pending in checkout-prod?
• untersuche crashloop in payments-prod
• triage pod api-7c9f6d7f86-abcde in payments-prod
• prüfe rollout von deployment payments-api in prod

Verhalten:

• Analysiere Namespace, Workload, Pod oder Selektor-Absicht.
• Wenn Namespace fehlt, verwende $DEFAULT_NAMESPACE falls gesetzt.
• Bei Mehrdeutigkeit standardmäßig Namespace-Ebene Triage.
• Zwinge den Benutzer nie, JSON-Felder zu merken.

---

2) Automatisierungsmodus (strukturiertes JSON)

Eingabe-JSON-Schema:

{ "namespace": "payments-prod", "workload_kind": "deployment", "workload_name": "payments-api", "pod_name": null, "label_selector": null, "include_logs": true, "logs_tail_lines": 200, "include_previous_logs": true, "events_limit": 50, "include_node_diagnostics": true, "include_metrics": false, "output_format": "markdown" }

Regeln:

• namespace ist erforderlich.
• Wenn pod_name angegeben → Pod-Ebene Triage.
• Wenn Workload-Felder angegeben → Workload-Ebene Triage.
• Sonst → Namespace-Scan.

---

Triage-Prozess

Schritt 0 — Voraussetzungen

Überprüfe Cluster-Zugriff:

kubectl version --client kubectl cluster-info

Wenn RBAC den Zugriff verweigert:

• Fahre mit erlaubten Operationen fort.
• Melde verweigerte Befehle explizit in der Ausgabe.

---

Schritt 1 — Schnelle Gesundheitsübersicht

Namespace-Bereich:

kubectl get pods -n -o wide kubectl get deploy,sts,ds,job,cronjob -n

Workload-Bereich:

kubectl get -n kubectl rollout status / -n --timeout=10s

Wähle Pods in Zuständen:

• CrashLoopBackOff
• ImagePullBackOff
• ErrImagePull
• Pending / Unschedulable
• Error
• NotReady
• OOMKilled
• Hohe Neustartanzahl

Begrenze tiefgehende Triage auf $TRIAGE_MAX_PODS (Standard 5).

---

Schritt 2 — Ereigniszeitdiagramm

kubectl get events -n --sort-by=.lastTimestamp | tail -n <events_limit>

Achte auf:

• FailedScheduling
• FailedMount
• Unhealthy (Sondenfehler)
• Back-off pulling image
• Evicted
• Node pressure signals

---

Schritt 3 — Pods & Workloads beschreiben

Für jeden ausgewählten Pod:

kubectl describe pod -n

Erfasse:

• Container-Zustand und -Grund
• Neustartanzahl
• Letzter Beendigungsgrund
• Sondenfehler
• Volume-Mount-Probleme
• Knotenzuweisung
• Taints / Tolerations
• Affinitätsbeschränkungen

Bei Workload-Ebene Triage:

kubectl describe -n

---

Schritt 4 — Knotendiagnose (optional)

kubectl get nodes -o wide kubectl describe node

Überprüfe auf:

• NotReady
• MemoryPressure
• DiskPressure
• PIDPressure
• Evictions

---

Schritt 5 — Logs (optional)

kubectl logs -n --all-containers --tail=

Bei Neustartschleifen und include_previous_logs=true:

kubectl logs -n --previous --all-containers --tail=

Regeln:

• Bevorzuge vorherige Logs bei CrashLoopBackOff.
• Schwärze offensichtliche vertrauliche Muster.
• Gib niemals Secret-Werte aus.

---

Schritt 6 — Optionale Metriken

Falls aktiviert:

kubectl top pods -n kubectl top node

Überspringe elegant, wenn metrics-server nicht verfügbar ist.

---

Erkennungsheuristiken

Klassifiziere erkannte Probleme in:

• CrashLoop / Anwendungsabsturz
• OOMKilled / Ressourcenlimits
• Image-Pull-Fehler
• Scheduling-Konflikt
• Sondenfehler
• PVC / Volume Fehler
• Knotendruck / Eviction
• Rollout steckt fest
• Unbekannt / Eskalation erforderlich

Für jedes Problem bereitstellen:

• Hypothese
• Unterstützende Beweise
• Konfidenzwert (0.0–1.0)
• Empfohlene nächste Befehle

---

Ausgabestruktur

1) Incident-Zusammenfassung

• Namespace
• Bereich (Pod/Workload/Namespace)
• Anzahl betroffener Ressourcen
• Zeitstempel

2) Top-Ergebnisse

Kurze Aufzählung.

3) Wahrscheinlichste Ursachen (Top 3)

Pro:

• Beschreibung
• Beweisauszug
• Konfidenz
• Empfohlene Aktionen

4) Nächste Befehle

Copy-paste kubectl-Befehle.

5) Evidence-Anhang

• Ereignisse (aktuell)
• Beschreibungsauszüge
• Logauszüge

---

Sicherheitsbeschränkungen

Diese Fertigkeit MUSS:

• Nur schreibgeschützte kubectl-Operationen durchführen.
• Niemals ausführen:
  • apply
  • patch
  • delete
  • exec
  • port-forward
  • scale
  • rollout restart
• Niemals Secret-Werte ausgeben.
• Vollständige Umgebungsvariablen vermeiden.

---

Autonome Kompatibilität

Diese Fertigkeit ist für den Aufruf durch konzipiert:

• k8s_alert_handler (alert-getriggerte Triage)
• k8s_patrol (geplante Patrouillen-Scans)
• Menschen über natürliche Sprache CLI

Sie muss:

• Idempotent sein
• Deterministische Fingerabdrücke erzeugen
• Übermäßige Clusterlast vermeiden
• Tiefe-Triage-Bereich begrenzen