2. Les outils de test

Formation suivie via le blog de Stéphane Robert : parcours Kubernetes.

En bref

Outil	Ce qu’il donne	Où l’utiliser
`describe`	la configuration complète et les événements récents d’un objet	`kubectl`
`events`	le journal de bord du namespace : pourquoi Kubernetes a agi	`kubectl`
`logs`	ce que raconte l’application (toujours depuis un Pod)	`kubectl`
`port-forward`	un accès rapide à une application pour la tester (pas pour la production)	`kubectl`
`crictl`	ce qui tourne réellement sur un node, quand `kubectl` ne peut plus aider	sur le node, en SSH
`kube-score`	les mauvaises pratiques d’un manifest, avant même de le déployer	en local ou en CI, sans cluster

describe

Donne la configuration complète et les événements récents de l’objet.

events

Les événements forment le journal de bord du namespace : c’est là que Kubernetes explique pourquoi il a agi. Le tri par .lastTimestamp est indispensable, car sans lui la sortie n’est pas chronologique et devient vite illisible.

kubectl get events -n demo-app --sort-by='.lastTimestamp'

logs

Donne ce que l’application raconte. Les logs viennent toujours d’un Pod.

La commande kubectl permet de lire les logs via le nom du Deployment :

kubectl logs deployment/nginx -n tuto --tail=10

Mais retenir que les logs viennent toujours d’un Pod. La commande kubectl en choisit un et affiche les logs.

port-forward

kubectl port-forward est idéal pour tester rapidement une application locale ou déboguer. Ce n’est pas le mode d’exposition habituel en production. Pour cela, on utilise un Ingress ou un LoadBalancer.

La session de port-forward se termine si le Pod sélectionné s’arrête.

Exemple : après déploiement d’une application :

kubectl port-forward svc/<app_name> 8080:80 -n <namespace>

crictl

crictl est l’outil en ligne de commande pour interroger directement le runtime de conteneurs (containerd, CRI-O) d’un node, via le CRI. Il s’utilise sur le node lui-même (en SSH), sans passer par l’API Server.

C’est l’outil de secours quand kubectl ne peut plus aider : API Server indisponible, node NotReady, Static Pod qui ne démarre pas… On voit alors ce qui tourne réellement sur la machine.

Commande	Ce qu’elle fait
`crictl pods`	liste les Pods présents sur le node
`crictl ps -a`	liste les conteneurs, y compris ceux qui sont arrêtés
`crictl logs <id-conteneur>`	affiche les logs d’un conteneur
`crictl inspect <id-conteneur>`	donne le détail d’un conteneur (état, code de sortie…)
`crictl images`	liste les images présentes sur le node
`crictl rmi --prune`	supprime les images inutilisées, pour libérer du disque

kube-score

kube-score fait une analyse statique des manifests YAML : il les lit sans rien déployer, donc sans cluster. Il signale les oublis et les mauvaises pratiques : pas de requests/limits sur les ressources, pas de probes, image en tag latest, conteneur qui tourne en root, pas de NetworkPolicy…

Chaque vérification ressort en OK, WARNING ou CRITICAL, avec une explication.

# Analyser un ou plusieurs fichiers
kube-score score deployment.yaml service.yaml

# Analyser un chart Helm ou un overlay Kustomize (lecture sur l'entrée standard avec -)
helm template mon-app ./chart | kube-score score -
kubectl kustomize ./overlays/prod | kube-score score -

Option	Ce qu’elle fait
`--output-format ci`	une ligne par vérification, plus facile à lire dans un pipeline
`--ignore-test <test>`	désactive une vérification (ex. `container-image-pull-policy`)
`--exit-one-on-warning`	fait aussi échouer la commande sur les `WARNING`, pas seulement sur les `CRITICAL`

Pour ignorer une vérification sur un seul objet, on ajoute une annotation dans son manifest :

metadata:
  annotations:
    kube-score/ignore: pod-probes