initializ/k8s-incident-triage

Triage d'Incident Kubernetes

Effectue un triage en lecture seule des workloads et des espaces de noms Kubernetes à l'aide de kubectl.

Prend en charge :

• Saisie en langage naturel (mode humain)
• Saisie JSON structurée (mode automatisation)

Cette compétence NE mute JAMAIS l'état du cluster.

---

Utilisation de l'outil

Cette compétence utilise exclusivement cli_execute avec des commandes kubectl. N'utilisez JAMAIS http_request ou web_search pour interagir avec Kubernetes. Toutes les opérations sur le cluster DOIVENT passer par kubectl via l'outil cli_execute.

---

Outil : k8s_triage

Diagnostique les workloads, pods ou espaces de noms Kubernetes défaillants.

---

Modes de Saisie

1) Mode Humain (Langage Naturel)

L'entrée est une simple chaîne de caractères.

Exemples :

• triage payments-prod
• triage deployment payments-api in payments-prod
• why are pods pending in checkout-prod?
• investigate crashloop in payments-prod
• triage pod api-7c9f6d7f86-abcde in payments-prod
• check rollout of deployment payments-api in prod

Comportement :

• Analyser l'intention concernant l'espace de noms, le workload, le pod ou le sélecteur.
• Si l'espace de noms est omis, utiliser $DEFAULT_NAMESPACE s'il est défini.
• En cas d'ambiguïté, par défaut effectuer un triage au niveau de l'espace de noms.
• Ne jamais obliger l'utilisateur à mémoriser les champs JSON.

---

2) Mode Automatisation (JSON Structuré)

Schéma JSON d'entrée :

{ "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" }

Règles :

• namespace est requis.
• Si pod_name est fourni → triage au niveau du pod.
• Si les champs du workload sont fournis → triage au niveau du workload.
• Sinon → scan de l'espace de noms.

---

Processus de Triage

Étape 0 — Prérequis

Vérifier l'accès au cluster :

kubectl version --client kubectl cluster-info

Si RBAC refuse l'accès :

• Continuer avec les opérations autorisées.
• Signaler explicitement les commandes refusées dans la sortie.

---

Étape 1 — Capture Rapide de l'État de Santé

Portée de l'espace de noms :

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

Portée du workload :

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

Sélectionner les pods dans les états :

• CrashLoopBackOff
• ImagePullBackOff
• ErrImagePull
• Pending / Unschedulable
• Error
• NotReady
• OOMKilled
• Nombre de redémarrages élevé

Limiter le triage approfondi à $TRIAGE_MAX_PODS (par défaut 5).

---

Étape 2 — Chronologie des Événements

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

Rechercher :

• FailedScheduling
• FailedMount
• Unhealthy (échecs des sondes)
• Back-off pulling image
• Evicted
• Signaux de pression du nœud

---

Étape 3 — Description des Pods et Workloads

Pour chaque pod sélectionné :

kubectl describe pod -n

Capturer :

• État et raison du conteneur
• Nombre de redémarrages
• Raison de la dernière terminaison
• Échecs des sondes
• Problèmes de montage de volume
• Affectation du nœud
• Taints / Tolerations
• Contraintes d'affinité

Si triage au niveau du workload :

kubectl describe -n

---

Étape 4 — Diagnostics du Nœud (Optionnel)

kubectl get nodes -o wide kubectl describe node

Vérifier :

• NotReady
• MemoryPressure
• DiskPressure
• PIDPressure
• Evictions

---

Étape 5 — Journaux (Optionnel)

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

En cas de boucles de redémarrage et si include_previous_logs=true :

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

Règles :

• Préférer les journaux précédents pour CrashLoopBackOff.
• Masquer les motifs sensibles évidents.
• Ne jamais imprimer les valeurs des Secrets.

---

Étape 6 — Métriques Optionnelles

Si activé :

kubectl top pods -n kubectl top node

Ignorer gracieusement si metrics-server est indisponible.

---

Heuristiques de Détection

Classer les problèmes détectés en :

• CrashLoop / Plantage de l'Application
• OOMKilled / Limites de Ressources
• Échec de Récupération d'Image
• Contrainte d'Ordonnancement
• Échec de Sonde
• Échec de PVC / Volume
• Pression du Nœud / Éviction
• Déploiement Bloqué
• Inconnu / Escalade Nécessaire

Pour chaque problème, fournir :

• Hypothèse
• Preuves à l'appui
• Score de confiance (0.0–1.0)
• Commandes recommandées suivantes

---

Structure de Sortie

1) Résumé de l'Incident

• Espace de noms
• Portée (pod/workload/espace de noms)
• Nombre de ressources affectées
• Horodatage

2) Principales Constatations

Résumé concis en points.

3) Causes Racines Probables (Top 3)

Pour chacune :

• Description
• Extrait de preuve
• Confiance
• Actions recommandées

4) Commandes Suivantes

Commandes kubectl prêtes à être copiées-collées.

5) Annexe des Preuves

• Événements (récents)
• Extraits de description
• Extraits de journaux

---

Contraintes de Sécurité

Cette compétence DOIT :

• Effectuer uniquement des opérations kubectl en lecture seule.
• Ne jamais exécuter :
  • apply
  • patch
  • delete
  • exec
  • port-forward
  • scale
  • rollout restart
• Ne jamais imprimer les valeurs des Secrets.
• Éviter de vider complètement les variables d'environnement.

---

Compatibilité Autonome

Cette compétence est conçue pour être invoquée par :

• k8s_alert_handler (triage déclenché par alerte)
• k8s_patrol (analyses de patrouille planifiées)
• Humains via CLI en langage naturel

Elle doit :

• Être idempotente
• Produire des empreintes déterministes
• Éviter une charge excessive du cluster
• Limiter la portée du triage approfondi