Introduction
Dans le cours Kubernetes pour débutants, vous avez utilisé kubectl get, describe et les étiquettes pour vérifier qu’une application fonctionnait correctement. Les clusters réels contiennent de nombreux objets. L’étape suivante consiste donc à poser des questions plus ciblées et à n’extraire que les informations nécessaires.
Dans ce laboratoire, vous allez déployer une petite application de vitrine et l’inspecter sous plusieurs angles : espace de noms, étiquettes, champs structurés, propriété par les contrôleurs et événements. Vous terminerez par une commande concise reliant un Deployment aux Pods qu’il gère.
Il n’est pas nécessaire de mémoriser tous les formats de sortie. En revanche, entraînez-vous à transformer une question en requête ciblée : « Quels objets existent ? », « Quels Pods correspondent à ce Service ? », « Qui possède ce Pod ? » ou « Que s’est-il passé récemment ? » Chaque étape ajoute un outil à cette méthode d’inspection.
Créer un espace de travail ciblé
Dans cette étape, vous allez créer un espace de noms et y déployer les ressources préparées. Un espace de noms limite la portée des requêtes ultérieures et évite de confondre des objets portant des noms similaires.
Accédez à l’espace de travail du laboratoire, puis vérifiez le contexte actuel avant de modifier l’état du cluster. cd modifie le répertoire de travail du shell ; les noms de fichiers relatifs utilisés ensuite, comme storefront.yaml, feront donc référence à l’espace de travail préparé.
cd /home/labex/project/resource-inspection
kubectl config current-context
La sortie doit être labex-v135. Créez l’espace de noms et appliquez le manifeste contenant plusieurs documents préparé à l’avance :
kubectl create namespace practice-observe
kubectl apply -f storefront.yaml
kubectl rollout status deployment/storefront -n practice-observe --timeout=60s
Les dernières lignes devraient ressembler à ceci. Des messages intermédiaires peuvent s’afficher pendant le démarrage des deux Pods :
namespace/practice-observe created
deployment.apps/storefront created
service/storefront created
deployment "storefront" successfully rolled out
-n practice-observe limite la commande à cet espace de noms. La commande de déploiement attend que les deux réplicas du Deployment soient disponibles, au lieu de s’appuyer sur une durée d’attente arbitraire.
Vous utiliserez régulièrement -n practice-observe. Sinon, les commandes Kubernetes utilisent l’espace de noms configuré dans votre contexte actuel — généralement default — et un objet fonctionnel pourrait sembler « introuvable » simplement parce que la requête porte sur le mauvais périmètre.
Découvrir les ressources et leur périmètre
Dans cette étape, vous utiliserez la découverte de l’API avant d’interroger les objets. kubectl api-resources répertorie les noms de ressources compris par le serveur d’API actuel, ainsi que leurs noms abrégés et l’indication précisant si elles sont liées à un espace de noms. Le pipe vers head limite cette première liste générale à ses dix premières lignes afin de ne pas saturer le terminal.
kubectl api-resources | head
kubectl api-resources --namespaced=true | grep -E 'pods|deployments|services'
Le pipe transmet la liste des ressources à grep. -E active l’alternance avec |, ce qui permet à une seule commande de rechercher plusieurs noms de ressources. Vous remarquerez que les Pods, les Deployments et les Services sont liés à un espace de noms.
Répertoriez les objets de l’application à l’aide de leurs noms complets, puis répétez la requête avec les noms abrégés courants :
kubectl get pods,deployments,services -n practice-observe
kubectl get po,deploy,svc -n practice-observe
Les deux commandes ciblent les mêmes ressources d’API. Les noms abrégés permettent de saisir moins de caractères, tandis que les noms complets sont plus explicites dans les scripts et la documentation.
Recherchez un Deployment, deux Pods générés et un Service. La liste de ressources séparées par des virgules constitue uniquement une commodité de requête ; ces objets conservent des rôles et des schémas d’API différents.
Les préfixes indiquant le type rendent la sortie combinée plus facile à interpréter. Les suffixes générés, les adresses et les durées d’existence varieront :
NAME READY STATUS RESTARTS AGE
pod/storefront-... 1/1 Running 0 ...
pod/storefront-... 1/1 Running 0 ...
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/storefront 2/2 2 2 ...
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/storefront ClusterIP ... <none> 80/TCP ...
Filtrer avec des étiquettes et des sélecteurs
Dans cette étape, vous utiliserez les étiquettes comme métadonnées interrogeables. --show-labels affiche toutes les étiquettes, tandis que -l sélectionne uniquement les objets dont les étiquettes correspondent à une expression.
kubectl get pods -n practice-observe --show-labels
kubectl get pods -n practice-observe -l app=storefront
kubectl get pods -n practice-observe -l 'app=storefront,tier=web'
Une virgule entre plusieurs critères de sélection signifie un ET logique. La dernière requête renvoie donc les Pods portant les deux étiquettes.
Comparez le sélecteur du Service avec les étiquettes des Pods sélectionnés :
kubectl get service storefront -n practice-observe -o jsonpath='Service selector: {.spec.selector.app}{"\n"}'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='NAME:.metadata.name,TIER:.metadata.labels.tier,IP:.status.podIP,READY:.status.containerStatuses[0].ready'
kubectl get endpointslices -n practice-observe -l kubernetes.io/service-name=storefront
JSONPath extrait un champ du Service. -o custom-columns produit un tableau compact à partir de plusieurs champs des Pods. Cette méthode est plus fiable qu’une recherche visuelle dans un document YAML volumineux.
La dernière commande recherche les EndpointSlices dont l’étiquette automatiquement gérée kubernetes.io/service-name correspond à storefront. Un EndpointSlice répertorie les points de terminaison réseau sélectionnés pour un Service. Une colonne ENDPOINTS non vide prouve que les étiquettes correspondantes ont produit des backends accessibles.
Le sélecteur du Service doit afficher storefront, et les deux lignes du tableau des Pods doivent contenir tier=web. L’étiquette app commune constitue le lien : un Service découvre les Pods grâce aux étiquettes, et non grâce à la propriété par un Deployment.
Service selector: storefront
NAME TIER IP READY
storefront-... web 10.244... true
storefront-... web 10.244... true
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
storefront-... IPv4 80 10.244...,10.244... ...
Suivre la propriété exercée par les contrôleurs
Dans cette étape, vous suivrez la chaîne de propriété Kubernetes du Deployment vers son ReplicaSet, puis vers ses Pods. Les contrôleurs ajoutent des ownerReferences afin que Kubernetes sache quel objet de niveau supérieur gère chaque objet dépendant.
kubectl get replicasets -n practice-observe -l app=storefront
kubectl get replicasets -n practice-observe -l app=storefront -o custom-columns='REPLICASET:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='POD:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
Le propriétaire du ReplicaSet doit être le Deployment storefront. Chaque Pod est possédé par le ReplicaSet généré, et non directement par le Deployment :
Deployment/storefront -> ReplicaSet/storefront-... -> Pod/storefront-...
Utilisez kubectl describe lorsque vous avez besoin de consulter cette relation avec les conditions et les événements récents :
kubectl describe deployment storefront -n practice-observe
Ne lisez pas systématiquement toute la sortie de describe de haut en bas. Pour cette question, concentrez-vous sur Selector, les compteurs de réplicas, les conditions et les événements. La meilleure commande d’inspection est celle qui répond à la question actuelle avec le moins de bruit possible.
Lire les événements comme une chronologie
Dans cette étape, vous inspecterez les événements comme des éléments de preuve classés dans le temps. Les événements décrivent les actions liées à la planification, aux images, aux conteneurs et aux contrôleurs, mais ils constituent des diagnostics temporaires et non des journaux d’audit permanents.
kubectl get events -n practice-observe --sort-by=.metadata.creationTimestamp
--sort-by trie les objets à partir d’un chemin de champ. Concentrez d’abord la chronologie sur le Deployment, puis sur l’un des Pods sélectionnés :
kubectl events -n practice-observe --for deployment/storefront
POD_NAME=$(kubectl get pods -n practice-observe -l app=storefront -o jsonpath='{.items[0].metadata.name}')
echo "$POD_NAME"
kubectl events -n practice-observe --for "pod/${POD_NAME}"
$(...) est une substitution de commande : le shell exécute la commande interne et enregistre sa sortie dans POD_NAME. Vous disposez maintenant d’une méthode d’inspection reproductible : restreindre l’espace de noms, sélectionner par étiquettes, extraire des champs, suivre les propriétaires, puis terminer par la chronologie des événements pertinents.
Les noms de Pods générés par les contrôleurs changent lors des remplacements. Il est donc plus sûr de sélectionner le nom actuel à l’aide d’une étiquette que de recopier une ancienne valeur. Ce modèle réapparaîtra dans les laboratoires de dépannage.
Le cycle de vie réussi observé comprend normalement Scheduled, Pulled, Created et Started. Un cluster local récemment démarré peut également conserver un avertissement antérieur tel que FailedCreatePodSandBox, le temps que Calico soit prêt. Ne concluez pas que l’application est toujours défaillante en vous basant uniquement sur un ancien avertissement : comparez son horodatage avec les événements normaux ultérieurs, puis vérifiez l’état READY actuel du Pod. Les horodatages et les noms de Pods générés sont volontairement omis, car ils changent à chaque exécution.
Résumé
Vous avez inspecté une application Kubernetes sans parcourir des objets sans rapport. Vous avez combiné les espaces de noms, les étiquettes, JSONPath, les colonnes personnalisées, les références de propriété et les événements afin de passer d’un inventaire général à des informations opérationnelles précises. Le prochain laboratoire appliquera cette méthode d’inspection à des Pods et des conteneurs défaillants.
