Commandes Kubernetes pour les Pods : guide pratique pour les opérations quotidiennes

Introduction

Kubernetes est devenu la norme de facto pour l'orchestration de conteneurs, mais sa puissance s'accompagne de complexité. Pour les développeurs et les opérateurs, la réalité quotidienne consiste à interagir avec les Pods – les plus petites unités déployables d'un cluster. Que vous déboguiez une application en échec, mettiez à l'échelle une charge de travail ou vérifiiez simplement la santé de vos services, connaître les bonnes commandes kubectl est essentiel.

Ce guide se concentre sur les commandes Kubernetes pour les Pods les plus utiles, expliquées avec des exemples pratiques et des étapes de mise en œuvre sûres. Nous couvrirons comment lister, inspecter, créer, mettre à jour et supprimer des Pods, ainsi que les commandes pour les journaux, exec, le transfert de port et le dépannage. Chaque section inclut des extraits de commandes concrets avec la sortie attendue, afin que vous puissiez suivre dans votre propre environnement. Nous aborderons également la vérification, les modes d'échec et les stratégies de récupération pour fluidifier vos opérations.

À la fin, vous disposerez d'un aide-mémoire pratique à utiliser quotidiennement, réduisant les incertitudes et augmentant la confiance dans la gestion des charges de travail Kubernetes.

Inventaire de la version et de l'environnement

Avant d'exécuter toute commande, il est important de connaître la version de Kubernetes et de kubectl que vous utilisez, car la sortie des commandes et les fonctionnalités peuvent varier. Cette section établit une base cohérente pour les exemples de ce guide.

Prérequis :

• Un cluster Kubernetes en cours d'exécution (local comme minikube, kind ou un cluster géré dans le cloud)
• kubectl installé et configuré pour communiquer avec le cluster
• Compréhension de base des concepts Kubernetes comme les Pods, les Deployments et les namespaces

Vérifiez la version de kubectl :

kubectl version --short

Sortie attendue (exemple) :

Client Version: v1.27.3
Kustomize Version: v5.0.1
Server Version: v1.27.3

Remarque : à partir de Kubernetes 1.26, --short est déprécié ; utilisez kubectl version sans option pour une sortie complète.

Vérifiez les informations du cluster :

kubectl cluster-info

Sortie attendue :

Kubernetes control plane is running at https://192.168.49.2:8443
CoreDNS is running at https://192.168.49.2:8443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Vérifiez les nœuds :

kubectl get nodes

Sortie attendue (exemple) :

NAME       STATUS   ROLES           AGE   VERSION
minikube   Ready    control-plane   10d   v1.27.3

Important : les exemples de ce guide utilisent un cluster minikube à nœud unique, mais les commandes sont applicables à tout cluster Kubernetes. Le namespace par défaut est utilisé sauf indication contraire ; nous montrerons également comment travailler dans plusieurs namespaces.

Chemin de configuration sûr

Lors de la gestion des Pods, il est crucial de suivre des pratiques sûres pour éviter des interruptions involontaires. Cette section explique les choix de mise en œuvre délimités : utilisation des namespaces, des libellés et du dry-run avant d'apporter des modifications.

Namespaces pour l'isolation

Travaillez toujours dans un namespace spécifique, en particulier dans les clusters partagés. Utilisez -n ou --namespace pour délimiter les commandes. Exemple : lister les Pods dans le namespace développement :

kubectl get pods -n development

Pour lister les Pods dans tous les namespaces :

kubectl get pods --all-namespaces

Libellés et sélecteurs

Les libellés vous permettent de regrouper et de sélectionner des Pods pour des opérations en masse. Par exemple, pour obtenir les Pods avec un libellé spécifique :

kubectl get pods -l app=nginx

Cela renvoie uniquement les Pods étiquetés app=nginx, réduisant le risque lors du filtrage. Vous pouvez combiner plusieurs sélecteurs :

kubectl get pods -l app=nginx,environment=production

Dry-run pour la validation

Avant d'appliquer des modifications, utilisez --dry-run=client pour valider le manifeste ou la commande sans apporter de modifications :

kubectl run nginx --image=nginx --dry-run=client -o yaml

Cela affiche le YAML qui serait envoyé au serveur d'API, vous permettant de le réviser. La sortie commence par apiVersion: v1 et kind: Pod, montrant le manifeste généré.

Exemple : créer un Pod en toute sécurité

Au lieu de créer impérativement un Pod, générez un manifeste YAML, révisez-le, puis appliquez-le :

kubectl run nginx --image=nginx --dry-run=client -o yaml > nginx-pod.yaml
# Modifiez le fichier selon vos besoins
kubectl apply -f nginx-pod.yaml

Cette approche s'aligne sur les pratiques GitOps et permet le contrôle de version de vos charges de travail. Préférez toujours les manifestes déclaratifs en production.

Vérification et diagnostics

Après avoir créé ou modifié des Pods, vous devez vérifier leur état et diagnostiquer les problèmes. Cette section couvre les commandes essentielles pour l'observabilité.

Lister les Pods

Liste de base :

kubectl get pods

Sortie attendue :

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          5m

Pour plus de détails, utilisez la sortie large :

kubectl get pods -o wide

Cela montre le nœud, l'IP et plus encore. Exemple de sortie :

NAME    READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          5m    10.244.0.5   minikube   <none>           <none>

Pour observer les changements en direct :

kubectl get pods -w

Cela diffuse les mises à jour jusqu'à ce que vous appuyiez sur Ctrl+C.

Décrire un Pod

Pour des informations détaillées, y compris les événements :

kubectl describe pod nginx

Consultez la section Événements à la fin pour voir la planification, le tirage d'image et le démarrage des conteneurs. La sortie inclut les statuts des conteneurs, les conditions et les volumes. Extrait d'exemple :

Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  5m    default-scheduler  Successfully assigned default/nginx to minikube
  Normal  Pulling    5m    kubelet            Pulling image "nginx"
  Normal  Pulled     5m    kubelet            Successfully pulled image "nginx"
  Normal  Created    5m    kubelet            Created container nginx
  Normal  Started    5m    kubelet            Started container nginx

Obtenir les journaux d'un Pod

Affichez les journaux d'un conteneur :

kubectl logs nginx

S'il y a plusieurs conteneurs, spécifiez le nom du conteneur :

kubectl logs nginx -c nginx-container

Suivez les journaux avec -f :

kubectl logs -f nginx

Pour voir les journaux d'une période spécifique :

kubectl logs nginx --since=1h

Exécuter des commandes dans un conteneur

Lancez un shell dans le Pod :

kubectl exec -it nginx -- /bin/bash

Si l'image ne possède pas bash, essayez sh. Exécutez une seule commande sans shell interactif :

kubectl exec nginx -- ls /

Sortie attendue (exemple) :

bin dev etc home proc root sys tmp usr var

Vous pouvez également définir des variables d'environnement pour la session exec :

kubectl exec nginx -- env

Transfert de port

Accédez localement au port d'un Pod :

kubectl port-forward pod/nginx 8080:80

Vous pouvez maintenant naviguer sur http://localhost:8080. La commande s'exécute au premier plan ; utilisez & pour la mettre en arrière-plan ou ouvrez un autre terminal.

Pour lier à une adresse spécifique :

kubectl port-forward --address 0.0.0.0 pod/nginx 8080:80

Vérifier l'utilisation des ressources

Si metrics-server est installé :

kubectl top pod nginx

Sortie attendue :

NAME    CPU(cores)   MEMORY(bytes)
nginx   1m           4Mi

Pour tous les Pods d'un namespace :

kubectl top pod -n development

Si metrics-server n'est pas installé, vous recevrez une erreur : error: Metrics API not available. Installez-le en utilisant kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml (voir la documentation officielle pour votre cluster).

Modes d'échec et récupération

Les Pods peuvent échouer pour diverses raisons : erreurs de tirage d'image, plantages, limites de ressources ou problèmes de nœud. Savoir identifier et récupérer est essentiel.

Modes d'échec courants

• ImagePullBackOff : l'image ne peut pas être tirée (mauvais nom, authentification du registre privé, réseau).
• CrashLoopBackOff : le conteneur démarre puis se termine de manière répétée, souvent à cause d'une erreur d'application.
• Pending : le Pod ne peut pas être planifié, souvent à cause de ressources insuffisantes.
• OOMKilled : le conteneur a dépassé la limite de mémoire et a été tué.

Commandes de diagnostic

• kubectl describe pod <name> : vérifiez les événements et l'état.
• kubectl logs <name> --previous : obtenez les journaux de l'instance précédente du conteneur qui a planté.
• kubectl get events --field-selector involvedObject.name=<pod-name> : listez les événements du cluster liés au Pod.

Exemple pour les événements :

kubectl get events --field-selector involvedObject.name=nginx

Exemple : déboguer CrashLoopBackOff

1. Décrivez le pod : kubectl describe pod myapp-7d9f8c5b-xyz
2. Vérifiez les événements : vous pourriez voir Back-off restarting failed container.
3. Vérifiez les journaux : kubectl logs myapp-7d9f8c5b-xyz --previous pour voir pourquoi il s'est terminé.
4. Si c'est une erreur de configuration, corrigez la ConfigMap ou le Secret et réappliquez.

Par exemple, si le conteneur se termine avec le code 1 en raison d'une variable d'environnement manquante, modifiez le Deployment pour ajouter la variable, puis appliquez :

kubectl edit deployment myapp
# ou modifiez le manifeste et kubectl apply -f deployment.yaml

Actions de récupération

• Supprimez et recréez le Pod (s'il est géré par un Deployment, il sera automatiquement recréé).
• Revenez à une révision précédente du Deployment : kubectl rollout undo deployment/myapp.
• Réduisez à zéro puis remontez si nécessaire.
• Ajustez les limites de ressources dans la spécification du Pod pour éviter OOMKilled.

Exemple : vérifiez l'historique des déploiements :

kubectl rollout history deployment/myapp

Puis revenez à une révision spécifique :

kubectl rollout undo deployment/myapp --to-revision=2

Important : ne modifiez jamais un Pod directement (sauf pour le débogage avec kubectl edit pod). Les Pods sont immuables ; utilisez des contrôleurs comme les Deployments pour les mises à jour.

Liste de contrôle des opérations

Utilisez cette liste de contrôle pour les opérations quotidiennes sur les Pods afin d'assurer cohérence et sécurité.

Étapes de révision :

1. Spécifiez toujours le namespace en cas de doute.
2. Préférez les manifestes déclaratifs (apply -f) aux commandes impératives en production.
3. Utilisez --dry-run=client avant d'apporter des modifications.
4. Surveillez le statut des Pods après tout changement.
5. Utilisez les libellés et les sélecteurs pour éviter d'agir sur des Pods non intentionnels.

Conclusion

Maîtriser les commandes Kubernetes de base pour les Pods est essentiel pour toute personne travaillant avec des applications conteneurisées. Dans ce guide, nous avons couvert les commandes fondamentales pour lister, inspecter, créer, déboguer et supprimer des Pods, avec des pratiques sûres et des exemples concrets. En suivant l'inventaire de version, le chemin de configuration sûr, les méthodes de vérification et les stratégies de récupération, vous pouvez opérer des clusters Kubernetes en toute confiance.

Points clés à retenir :

• Utilisez kubectl get, describe et logs pour l'observation quotidienne.
• Utilisez exec et port-forward pour le débogage et l'accès local.
• Délimitez toujours les commandes avec les namespaces et les libellés.
• Préférez les manifestes déclaratifs et le dry-run pour les modifications.
• Sachez diagnostiquer et récupérer des échecs courants des Pods.

Prochaines étapes : pratiquez ces commandes dans un environnement de bac à sable, commencez avec un seul Pod, puis passez aux Deployments et à des charges de travail plus complexes. Utilisez la liste de contrôle des opérations comme référence rapide. Avec ces compétences, vous serez bien équipé pour gérer les Pods Kubernetes en production.