Aller au contenu

Kubernetes Mis à jour le 2026-05-27

Dépannage Kubernetes

Où regarder quand quelque chose va de travers sur un cluster Kubernetes Stack Harbor PaaS — journaux d'installation, vérification de santé, flux d'événements et journaux de pods.

Le paquet Kubernetes Cluster du Stack Harbor PaaS est une pile de composants coopérants — kubelet, kube-proxy, CNI, contrôleur d’ingress, dashboard, metrics server, Prometheus optionnel, Jaeger optionnel — qui peuvent chacun défaillir indépendamment. Cette page est le point d’entrée de la surface diagnostique : où la plateforme écrit ses erreurs, comment les lire, et comment escalader quand un problème dépasse le libre-service.

Trois niveaux d’investigation :

  • Installation — le cluster n’est jamais monté proprement.
  • Événements — le cluster est en marche mais quelque chose se comporte mal.
  • Journaux de pod — une charge précise se comporte mal.

Dépannage d’installation

L’installation du cluster est automatisée et inclut un traitement d’erreurs intégré. La plateforme attrape la plupart des échecs récupérables et expose la cause racine directement dans le tableau de bord.

Quand l’installation échoue :

  1. Lisez l’erreur exposée par la boîte d’installation. Les causes les plus courantes — identifiant de registre, licence manquante, quota de ressources épuisé — sont nommées directement.
  2. Si la cause racine n’est pas évidente, utilisez le widget Send Report dans l’installeur. Le rapport empaquette les journaux d’installation, les messages d’erreur et les informations de débogage plateforme ; il va au support Stack Harbor avec assez de contexte pour enquêter sans aller-retour.

Après une installation réussie, un utilitaire de vérification de santé tourne et valide que tous les composants du cluster sont Running. Vérifiez le résultat à /var/log/k8s-health-check.log sur le nœud maître. Le script vérifie :

  • Le plugin CNI Weave.
  • Le contrôleur d’ingress.
  • Le metrics server.
  • Le Kubernetes Dashboard.
  • Le node problem detector.
  • La pile de supervision (Prometheus / Grafana, si installée).
  • L’accès Remote API.
  • Le palier de stockage NFS (si activé).
  • L’application exemple (si vous avez choisi un cluster propre avec exemple).

Si la vérification de santé marque un composant comme non Running, la fenêtre post-installation affiche un avertissement. L’avertissement n’est pas toujours un vrai échec — un déploiement peut simplement être encore en cours. Lancez kubectl get pods --all-namespaces pour vérifier l’état réel. Si tout est Running, le cluster est sain. Si quelque chose est CrashLoopBackOff, ImagePullBackOff ou bloqué Pending, c’est la piste.

Événements : changements d’état au niveau cluster

Une fois le cluster en marche, la couche diagnostique suivante est le flux d’événements — l’enregistrement par Kubernetes de ce que font les contrôleurs et l’ordonnanceur.

Deux surfaces :

  • Kubernetes Dashboard — la vue Events, optionnellement filtrée par namespace.

  • kubectl get events — les mêmes données en ligne de commande :

    kubectl get events -n {namespace}

    Ajoutez --sort-by='.lastTimestamp' pour l’ordre chronologique, ou --watch pour suivre en temps réel.

Les événements exposent les raisons des décisions d’ordonnancement, les échecs de pull d’image, les échecs de readiness probe et les pressions de ressources. C’est le bon arrêt après une consultation d’état de pod.

Journaux de pod : sortie au niveau conteneur

Pour une charge déraillée, descendez d’un cran vers le stdout/stderr du conteneur.

Deux surfaces :

  • Kubernetes Dashboard — ouvrez la page du pod et cliquez sur Logs en haut à droite.

  • kubectl logs :

    kubectl logs {pod-name} -n {namespace}
kubectl logs -f {pod-name} -n {namespace}    # suivre
kubectl logs --previous {pod-name} -n {namespace}    # conteneur précédent, en cas de crash
kubectl logs {pod-name} -c {container-name}    # un conteneur dans un pod multi-conteneur

Les événements Back-off restarting failed container sur un pod ont presque toujours leur cause racine dans le journal du conteneur précédent — kubectl logs --previous est la bonne commande dans ce cas.

Quand escalader

Le libre-service s’épuise quand :

  • Les pods kube-system du cluster sont malsains et une plongée dans les journaux de pod ne révèle pas de cause corrigeable.
  • La Remote API n’est pas joignable et vous avez écarté les problèmes réseau de votre côté.
  • Un nœud est passé NotReady et les redémarrages / drains ne le récupèrent pas.
  • La vérification de santé marque répétitivement un composant qui tourne bien, suggérant que la vérification elle-même est mal configurée.

Pour ces cas, ouvrez un ticket au support Stack Harbor. Incluez :

  • Le nom d’environnement du cluster.
  • La version de Kubernetes.
  • La sortie de kubectl get nodes, kubectl get pods --all-namespaces, et la section pertinente de /var/log/k8s-health-check.log.
  • Tout journal plateforme depuis /var/log sur le nœud maître qui semble lié.

Voir aussi