Un mesh mal configuré n’échoue souvent pas bruyamment : le trafic ne suit simplement pas la route attendue, ou un Pod ne reçoit jamais le sidecar que vous supposiez. istioctl dispose de commandes dédiées à cela : détecter les problèmes avant qu’ils ne causent des symptômes déroutants. Ce guide couvre celles qu’il vaut la peine d’exécuter régulièrement.

istioctl analyze : trouver les problèmes de configuration avant qu’ils ne vous pénalisent

istioctl analyze
istioctl analyze -n my-namespace
istioctl analyze -A

analyze inspecte la configuration Istio réelle de votre cluster, pas seulement un fichier que vous êtes sur le point d’appliquer, et signale de vrais problèmes : un namespace qui n’est pas étiqueté pour l’injection alors que vous le vouliez manifestement, un VirtualService qui référence un hôte inexistant, une configuration en conflit entre deux ressources. Exécutez-la sans option de namespace pour le namespace par défaut du contexte courant, avec -n pour un namespace précis, ou avec -A sur tous les namespaces du cluster. Prenez-en l’habitude après chaque changement de configuration, pas seulement quand quelque chose est visiblement cassé ; elle détecte régulièrement un problème avant qu’il ne devienne un symptôme.

istioctl validate : vérifier un fichier avant de l’appliquer

istioctl validate -f my-virtualservice.yaml

Là où analyze inspecte ce qui est déjà en place dans le cluster, validate vérifie un manifeste avant son application, en détectant les erreurs de schéma et les valeurs de champs invalides. Exécutez-la systématiquement avant kubectl apply sur tout ce qui concerne Istio, le même réflexe que kubectl apply --dry-run pour les ressources Kubernetes classiques.

istioctl proxy-status : chaque sidecar est-il synchronisé ?

istioctl proxy-status

Cette commande liste chaque sidecar connu d’istiod et indique si chacun a la dernière configuration (SYNCED) ou est en retard (STALE, ou affichant une erreur). Un sidecar bloqué en STALE est souvent l’explication réelle lorsqu’un changement de routage que vous venez d’appliquer ne semble pas prendre effet sur un Pod en particulier, ce qui vaut la peine d’être vérifié avant de supposer que la configuration elle-même est erronée.

istioctl proxy-config : que fait tourner réellement ce sidecar ?

Pour examiner directement la configuration Envoy d’un seul Pod, plutôt que de deviner à partir du comportement :

istioctl proxy-config routes <pod-name> -n <namespace>
istioctl proxy-config clusters <pod-name> -n <namespace>
istioctl proxy-config listeners <pod-name> -n <namespace>

C’est la même idée sous-jacente que celle des guides Envoy de cette bibliothèque sur l’inspection d’une configuration en cours d’exécution, mais via le wrapper propre à Istio plutôt que l’API d’administration brute d’Envoy.

Le label app : facile à oublier, il casse silencieusement la visualisation

Un piège précis est assez courant pour être signalé à part. Istio (et les outils construits dessus, comme Kiali, traité dans le guide suivant) s’appuient sur un label app présent sur vos Deployments et Services pour se faire une image exacte de quels workloads communiquent avec lesquels :

metadata:
  labels:
    app: reviews

Omettez-le, et rien ne casse bruyamment : les Pods se déploient, les sidecars s’injectent, le trafic circule toujours. Ce qui cesse silencieusement de fonctionner, c’est tout ce qui dépend de ce label pour identifier un workload : le graphe de services de Kiali n’affichera pas correctement la connexion, et certaines fonctionnalités de gestion du trafic et de télémétrie qui s’appuient sur app se comportent de façon imprévisible. Si un mesh paraît sain par ailleurs mais que ses outils d’observabilité montrent une image confuse ou incomplète, des labels app manquants sur les Deployments et Services sous-jacents font partie des premières choses à vérifier, précisément parce que ce mode de défaillance ne produit aucun message d’erreur désignant la cause.

Une habitude raisonnable à prendre

Exécutez istioctl analyze après chaque changement de configuration, istioctl validate avant d’appliquer quoi que ce soit de nouveau, et istioctl proxy-status chaque fois qu’un changement ne semble pas prendre effet à un endroit précis. Aucune de ces commandes ne détecte tout, la surface de configuration d’Istio est vaste, mais ensemble elles détectent les erreurs à la fois courantes et fastidieuses à déboguer en se contentant de fixer du YAML.