Vérifier l'état des ressources (`kubectl get pods,deploy,svc`)

Après l'application : la nécessité de vérifier l'état réel

Avoir appliqué un manifeste avec `kubectl apply -f` et reçu un message de confirmation comme `created` ou `configured` est une étape importante, mais elle ne signifie pas nécessairement que votre application est opérationnelle. Cette confirmation indique seulement que l'API Server de Kubernetes a accepté votre demande et a enregistré l'état désiré dans etcd. C'est ensuite aux contrôleurs du cluster de travailler pour atteindre cet état. Il est donc crucial de vérifier l'état réel des ressources pour s'assurer que tout se déroule comme prévu.

Cette phase de vérification permet de confirmer que les objets demandés (Deployments, Pods, Services, etc.) ont bien été créés ou mis à jour et qu'ils sont dans un état stable et sain. Elle permet également de détecter rapidement d'éventuels problèmes, comme des Pods qui ne démarrent pas ou des configurations incorrectes. Pour cela, l'outil `kubectl` offre une série de commandes `get` très utiles.

Nous allons nous concentrer sur les commandes les plus courantes pour inspecter l'état d'un déploiement simple : `kubectl get deployment` (ou sa forme courte `deploy`), `kubectl get pods` (ou `po`), et brièvement `kubectl get service` (ou `svc`), car un déploiement est souvent accompagné d'un service pour l'exposer.

Inspecter le déploiement lui-même : `kubectl get deployment`

La première chose à vérifier est l'état de l'objet Deployment que nous avons créé. Il agit comme le gestionnaire de nos Pods applicatifs. La commande `kubectl get deployment` (ou `kubectl get deploy`) liste les Deployments dans le namespace courant.

En reprenant notre exemple précédent (`nginx-deployment`), l'exécution de la commande pourrait donner une sortie similaire à ceci :

$ kubectl get deployment nginx-deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           5m10s

Analysons les colonnes clés :

• NAME : Le nom de notre Deployment (`nginx-deployment`).
• READY : Indique le nombre de réplicas actuellement prêts (`READY`) sur le nombre total désiré (`replicas` dans le manifeste). `2/2` signifie que nos deux Pods souhaités sont démarrés et considérés comme prêts (nous verrons plus tard comment définir la "prêtitude" avec les Readiness Probes). C'est un indicateur clé de santé. Si vous voyez `0/2` ou `1/2`, cela signifie qu'un ou plusieurs Pods ne sont pas encore prêts ou ont des problèmes.
• UP-TO-DATE : Nombre de réplicas qui ont été mis à jour pour correspondre à la dernière version du template de Pod spécifiée dans le Deployment. Utile lors des mises à jour.
• AVAILABLE : Nombre de réplicas qui sont prêts et disponibles pour servir du trafic (selon les critères des Readiness Probes). C'est souvent la métrique la plus importante pour s'assurer que l'application est fonctionnelle.
• AGE : Depuis combien de temps l'objet Deployment existe.

Voir `READY` et `AVAILABLE` correspondre au nombre de `replicas` souhaité est un excellent signe que le Deployment lui-même se porte bien et a réussi à orchestrer ses Pods.

Plonger au niveau des pods : `kubectl get pods`

Le Deployment gère les Pods, mais ce sont les Pods qui exécutent réellement nos conteneurs applicatifs. Il est donc essentiel de vérifier leur état individuel. La commande `kubectl get pods` liste les Pods.

Pour voir les Pods créés par notre `nginx-deployment`, nous pouvons utiliser les labels que nous avons définis dans le manifeste. Rappelez-vous, nous avons mis le label `app: nginx` sur le template de Pod. Nous pouvons donc filtrer avec l'option `-l` (ou `--selector`) :

kubectl get pods -l app=nginx

La sortie pourrait ressembler à ceci :

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-6799fc88d8-abcde   1/1     Running   0          6m20s
nginx-deployment-6799fc88d8-fghij   1/1     Running   0          6m20s

Ici, nous voyons deux Pods, comme demandé par `replicas: 2`. Analysons les colonnes :

• NAME : Le nom unique de chaque Pod. Notez qu'il est généré automatiquement par Kubernetes en ajoutant un identifiant unique (basé sur le ReplicaSet géré par le Deployment, `6799fc88d8`, et un suffixe aléatoire, `abcde`, `fghij`) au nom du Deployment.
• READY : Nombre de conteneurs prêts dans le Pod sur le nombre total de conteneurs définis dans sa `spec`. `1/1` signifie que notre unique conteneur Nginx est prêt.
• STATUS : L'état actuel du Pod. `Running` est l'état idéal, signifiant que le Pod est démarré et que ses conteneurs s'exécutent. D'autres statuts courants incluent `Pending` (le Pod attend d'être assigné à un noeud ou que ses ressources soient disponibles), `ContainerCreating` (le noeud télécharge l'image ou prépare le conteneur), `Error` ou `CrashLoopBackOff` (indiquant un problème sérieux avec le conteneur qui plante de manière répétée). Voir un statut autre que `Running` nécessite une investigation (via `kubectl describe pod` ou `kubectl logs`).
• RESTARTS : Combien de fois les conteneurs dans ce Pod ont redémarré. Un nombre élevé ici indique généralement un problème.
• AGE : Depuis combien de temps le Pod existe.

Voir tous les Pods associés à votre Deployment dans l'état `Running` avec `READY 1/1` (ou `N/N` si N conteneurs) et 0 `RESTARTS` est l'objectif.

Vérifier l'exposition (si applicable) : `kubectl get service`

Si votre manifeste incluait également un objet `Service` pour exposer votre Deployment (ce qui sera abordé plus en détail dans des chapitres ultérieurs), vous utiliseriez `kubectl get service` (ou `svc`) pour vérifier son état.

Supposons que nous ayons créé un Service nommé `nginx-service` de type `NodePort` pour exposer notre `nginx-deployment`. La commande `kubectl get svc nginx-service` pourrait afficher :

NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
nginx-service   NodePort   10.100.50.20           80:30080/TCP   2m30s

Les informations clés ici sont :

• NAME : Nom du Service.
• TYPE : Le type de Service (`NodePort` dans cet exemple).
• CLUSTER-IP : L'adresse IP interne au cluster assignée au Service.
• EXTERNAL-IP : L'adresse IP externe (si applicable, par exemple pour un `LoadBalancer` fourni par un cloud provider). Pour `NodePort`, c'est souvent `` ou l'IP du noeud.
• PORT(S) : Mappage des ports. `80:30080/TCP` signifie que le Service écoute sur le port 80 (accessible depuis l'intérieur du cluster via le CLUSTER-IP) et le redirige vers le `targetPort` des Pods (implicitement 80 ici). De plus, comme c'est un `NodePort`, ce service est également accessible sur le port `30080` de chaque noeud du cluster.
• AGE : Depuis combien de temps le Service existe.

Vérifier que le Service existe et que les ports sont correctement configurés est essentiel si vous avez besoin d'accéder à votre application.

Commandes combinées et options utiles

Pour avoir une vue d'ensemble rapide, vous pouvez demander plusieurs types de ressources dans une seule commande `kubectl get` :

kubectl get deploy,pods,svc -l app=nginx

Cela affichera l'état du Deployment, des Pods correspondants (grâce au label selector), et du Service associé (s'il a aussi le label `app=nginx`).

Une autre option très utile est `-o wide`. Elle ajoute des colonnes d'information supplémentaires à la sortie, notamment l'adresse IP interne du Pod et le nom du noeud sur lequel il s'exécute :

kubectl get pods -l app=nginx -o wide

NAME                                READY   STATUS    RESTARTS   AGE     IP          NODE             NOMINATED NODE   READINESS GATES
nginx-deployment-6799fc88d8-abcde   1/1     Running   0          8m10s   172.17.0.5   minikube                    
nginx-deployment-6799fc88d8-fghij   1/1     Running   0          8m10s   172.17.0.6   minikube                    

Enfin, si vos ressources ne sont pas dans le namespace `default`, n'oubliez pas d'ajouter l'option `-n ` à toutes vos commandes `kubectl`.

La vérification de l'état via `kubectl get` est une étape réflexe après chaque `kubectl apply`. Elle vous donne la confirmation visuelle que Kubernetes a bien compris et exécuté votre demande, et vous alerte immédiatement si quelque chose ne va pas, vous permettant de passer à l'étape de diagnostic si nécessaire.