Comprendre et manipuler les Pods Kubernetes

Mise à jour : 17/02/2025

Après avoir découvert les bases de Kubernetes, il est essentiel de comprendre ses ressources fondamentales. Parmi elles, le pod occupe une place centrale. Il s’agit de l’unité de base déployable dans un cluster Kubernetes, représentant un ou plusieurs conteneurs qui partagent le même environnement réseau et, éventuellement, le même stockage.

Dans cette section, nous allons explorer en détail les pods, leur structure, leur cycle de vie, leur gestion et leur interaction avec d’autres composants du cluster. Que ce soit pour exécuter une simple application conteneurisée ou orchestrer des workloads complexes, maîtriser les pods est une étape clé pour toute personne travaillant avec Kubernetes.

Prérequis

Avant de plonger dans ce guide, il est important de s’assurer que vous avez les bases nécessaires pour tirer le meilleur parti des concepts abordés. Voici ce qu’il faut maîtriser :

Connaissances en ligne de commande Linux
- Être à l’aise avec les commandes de base dans un terminal.
- Savoir naviguer dans un système de fichiers et exécuter des commandes simples.
Connaissances de base sur Kubernetes
- Comprendre l’architecture globale (plan de contrôle, nœuds de travail).
- Savoir ce qu’est un cluster Kubernetes et comment il fonctionne.
Un environnement Kubernetes opérationnel
- Avoir installé un “Mini Kubernetes”, comme Minikube, K3s, ou Kind.
- Vérifier que kubectl est configuré et fonctionne avec votre cluster.
Connaissance de la CLI Kubernetes : kubectl

Si ces prérequis sont en place, vous êtes prêt à démarrer ce guide et à explorer en profondeur les ressources essentielles de Kubernetes.

C’est quoi un Pod Kubernetes ?

Dans Kubernetes, le pod est l’unité fondamentale de déploiement et d’exécution. Tout conteneur fonctionnant dans Kubernetes est encapsulé dans un pod. Contrairement à un conteneur isolé (comme ceux exécutés avec Docker), un pod est une abstraction qui permet à Kubernetes de gérer et d’orchestrer efficacement des applications conteneurisées.

Définition d’un Pod

Un pod est une enveloppe logique qui regroupe un ou plusieurs conteneurs partageant un même environnement d’exécution. Chaque pod possède :

Une adresse IP unique dans le cluster, ce qui permet aux conteneurs qu’il héberge de communiquer facilement entre eux.
Un espace de stockage partagé à travers des volumes Kubernetes, ce qui facilite l’échange de données entre les conteneurs du pod.
Un ensemble de métadonnées définissant son comportement, ses règles d’affinité et ses ressources allouées.

Un pod peut contenir un ou plusieurs conteneurs, mais dans la majorité des cas, il n’héberge qu’un seul conteneur principal.

Création de Pods Kubernetes

Création en mode impératif

La méthode la plus simple pour créer un Pod consiste à utiliser la commande kubectl run.Pour rappel, les commandes kubectl run et kubectl create sont des commandes impératives qui permettent de créer des ressources Kubernetes sans avoir à écrire de fichiers de configuration YAML.

Voici un exemple de création d’un Pod exécutant un serveur Nginx :

kubectl run mon-pod --image=nginx

Après l’exécution de cette commande, voici ce qu’il se passe en coulisses :

kubectl envoie la requête à l’API Server sous forme d’un objet Pod.
L’API Server valide la requête (RBAC, syntaxe) et enregistre le Pod dans etcd.
Le Scheduler détecte un Pod sans nœud et choisit un nœud en fonction des ressources disponibles.
Le kubelet du nœud sélectionné récupère la définition du Pod et demande au container runtime de créer le conteneur. Il met à jour l’état du Pod** auprès de l’API Server (Pending → ContainerCreating).
Le container runtime (Docker, containerd) télécharge l’image du conteneur si elle n’est pas en local.
Le container runtime crée et exécute le conteneur avec les ressources définies.
Le réseau est configuré par le CNI (Container Network Interface), et une IP est assignée au Pod.
Le kubelet met à jour l’état du Pod auprès de l’API Server (ContainerCreating → Running).
Le Controller Manager surveille le Pod, applique les règles de redémarrage et gère l’autoscaling si nécessaire.

C’est magnifique, n’est-ce pas ?

Vérification de l’état d’un Pod

Une fois le Pod créé, on peut vérifier son état avec la commande suivante :

kubectl get pods

Cela affiche une sortie similaire à ceci :

NAME       READY   STATUS    RESTARTS   AGE
mon-pod    1/1     Running   0          10s

Si le STATUS est Running, le Pod fonctionne correctement. En cas de problème, il sera indiqué Pending, CrashLoopBackOff, ou Error.

Afficher les détails d’un Pod

Pour voir des informations détaillées sur un Pod spécifique, j’utilise la commande :

kubectl describe pod mon-pod

Vous obtiendrez des détails sur :

L’image utilisée
L’état des conteneurs
Les événements liés au Pod (redémarrages, erreurs, etc.)
L’adresses IP assignée au Pod
Les volumes montés
Le nom du noeud sur lequel le Pod est déployé
et tout un tas d’autres informations utiles.

Name:             mon-pod
Namespace:        default
Priority:         0
Service Account:  default
Node:             minikube/192.168.39.102
Start Time:       Sun, 16 Feb 2025 08:04:29 +0000
Labels:           run=mon-pod
Annotations:      <none>
Status:           Running
IP:               10.244.0.3
IPs:
  IP:  10.244.0.3
Containers:
  mon-pod:
    Container ID:   docker://efddbaac09c1147e39145a8fc7cf9e2460f05016aab1f1f04f77f077fdf17a2d
    Image:          nginx
    Image ID:       docker-pullable://nginx@sha256:91734281c0ebfc6f1aea979cffeed5079cfe786228a71cc6f1f46a228cde6e34
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Sun, 16 Feb 2025 08:04:45 +0000
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-vkzgx (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       True
  ContainersReady             True
  PodScheduled                True
Volumes:
  kube-api-access-vkzgx:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  8m36s  default-scheduler  Successfully assigned default/mon-pod to minikube
  Normal  Pulling    8m35s  kubelet            Pulling image "nginx"
  Normal  Pulled     8m20s  kubelet            Successfully pulled image "nginx" in 14.596s (14.596s including waiting). Image size: 191994076 bytes.
  Normal  Created    8m20s  kubelet            Created container mon-pod
  Normal  Started    8m20s  kubelet            Started container mon-pod

Parfois, il est nécessaire de déboguer un Pod pour comprendre pourquoi il ne fonctionne pas correctement. La commande kubectl describe fournit des informations précieuses pour identifier les problèmes.

Mise à jour d’un Pod

Un Pod étant immuable, il n’est pas possible de modifier directement ses paramètres (comme l’image). Pour mettre à jour un Pod :

Je supprime l’ancien Pod.
Je redéploie un nouveau Pod avec les modifications.

Supprimer un Pod

Pour supprimer un Pod, j’utilise la commande :

kubectl delete pod mon-pod

Créer un Pod en mode déclaratif

Une autre approche plus déclarative consiste à définir un Pod dans un fichier YAML. Voici un exemple avec le fichier mon-pod.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: mon-pod
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - containerPort: 8080

Explication du fichier :

apiVersion: Définit la version de l’API Kubernetes.
kind: Indique le type d’objet (ici, un Pod).
metadata: Contient le nom du Pod (mon-pod).
spec: Décrit la configuration du Pod.
- containers: Liste les conteneurs inclus.
- image: Spécifie l’image Docker utilisée.
- ports: Définit le port exposé à l’intérieur du conteneur.

J’applique ce fichier dans Kubernetes avec la commande :

kubectl apply -f mon-pod.yaml

Pour vérifier son état :

kubectl get pod

Affichage des logs d’un Pod

Chaque conteneur d’un Pod écrit des logs sur sa sortie standard (stdout) et sa sortie d’erreur (stderr). Kubernetes permet de consulter ces logs directement.

Affichage des logs d’un Pod :

kubectl logs mon-pod

Par défaut, cette commande affiche les logs du premier conteneur si le Pod en contient plusieurs.

Afficher les logs d’un conteneur spécifique :

Si un Pod contient plusieurs conteneurs, il faut préciser son nom :

kubectl logs mon-pod -c mon-container

Afficher les logs en temps réel (mode follow) :

kubectl logs -f mon-pod

Utilité : Voir les logs en direct comme avec tail -f.

Afficher les logs des Pods plantés :

Si un Pod s’est terminé ou a crashé (CrashLoopBackOff), on peut récupérer ses logs avant suppression :

kubectl logs --previous mon-pod

Exécuter des commandes dans un Pod (`kubectl exec`)

Si un Pod fonctionne mal, on peut y entrer pour exécuter des commandes et inspecter son état.

Accéder à un shell interactif dans un Pod : Si l’image inclut bash :

kubectl exec -it mon-pod -- bash

Si l’image contient uniquement sh (comme Alpine) :

kubectl exec -it mon-pod -- /sh

Utilisation courante : Vérifier les fichiers de logs, la connectivité réseau, ou tester un processus en cours.

Inspection des événements Kubernetes

Kubernetes enregistre des événements sur les changements d’état des Pods. Ces événements sont visibles avec :

kubectl get events

Exemples d’événements courants :

FailedScheduling : Pas de ressources disponibles sur les nœuds
BackOff : Kubernetes tente de redémarrer un Pod en boucle (CrashLoopBackOff)
OOMKilled : Un conteneur a dépassé sa limite mémoire et a été tué

Analyse des ressources utilisées (`kubectl top`)

Pour voir la consommation mémoire et CPU des Pods en temps réel :

kubectl top pods

Exemple de sortie :

NAME        CPU(cores)   MEMORY(bytes)
mon-pod     250m        150Mi

Détection rapide : Un Pod consommant trop de mémoire ou trop de CPU peut être tué par Kubernetes.

Debugging avancé avec Ephemeral Containers

Depuis Kubernetes 1.23, il est possible d’ajouter un conteneur éphémère dans un Pod pour le debugger sans le redémarrer.

kubectl debug mon-pod -it --image=busybox

Utilité : Permet d’exécuter des commandes sans impacter le Pod existant.

Conclusion

Les Pods Kubernetes sont la plus petite unité déployable dans un cluster, mais en pratique, ils ne sont presque jamais utilisés seuls. Kubernetes offre des mécanismes bien plus avancés pour gérer les applications de manière robuste et scalable.

Dans un environnement de production, il est peu courant de créer des Pods manuellement ou de les gérer individuellement. À la place, on utilise des ressources plus élaborées comme :

Deployments : Pour gérer la montée en charge, les mises à jour et le rollback automatique des Pods.
ReplicaSets : Pour assurer la haute disponibilité en répliquant les Pods.
DaemonSets : Pour exécuter des Pods sur chaque nœud du cluster.
StatefulSets : Pour déployer des applications ayant besoin d’une identité persistante (ex: bases de données).
Jobs et CronJobs : Pour exécuter des tâches ponctuelles ou récurrentes.

Les Pods sont donc une abstraction essentielle, mais ils sont surtout utilisés de manière indirecte, encapsulés dans ces ressources plus avancées qui permettent d’assurer la résilience, la scalabilité et la gestion automatique des déploiements.

En résumé : Comprendre les Pods est fondamental pour maîtriser Kubernetes, mais en production, leur gestion est toujours orchestrée par des contrôleurs plus évolués.