Comprendre la différence fondamentale entre les Pods et les Nœuds Kubernetes

Si vous débutez avec Kubernetes, la distinction entre pod et nœud est l'une des premières choses qui fait comprendre le reste du système. Un nœud est la machine. Un pod est la charge de travail que Kubernetes place sur cette machine. Les conteneurs s'exécutent à l'intérieur des pods, et les pods s'exécutent sur les nœuds.

Cela semble simple, mais cela explique beaucoup de dépannage quotidien. Si un pod est Pending, Kubernetes n'a peut-être pas trouvé de nœud approprié. Si un nœud est NotReady, chaque pod sur ce nœud est en danger. Si votre application nécessite une haute disponibilité, exécuter plus de conteneurs ne suffit pas ; vous avez besoin de réplicas répartis sur différents nœuds.

Aperçu de l'architecture du cluster Kubernetes

Un cluster Kubernetes est composé d'un ensemble de machines (physiques ou virtuelles) travaillant ensemble. Ces machines sont largement catégorisées en Plan de Contrôle (le cerveau gérant l'état du cluster) et Nœuds de Travail (le muscle qui exécute les charges de travail réelles). Le Pod et le Nœud interagissent au sein de cette structure.

Nœud : La machine physique ou virtuelle qui fournit le CPU, la mémoire, le disque et le réseau.
Pod : La plus petite unité déployable que Kubernetes planifie. Il héberge un ou plusieurs conteneurs.

Comprendre cette hiérarchie—où les Nœuds hébergent les Pods, et les Pods hébergent les Conteneurs—est le point de départ pour maîtriser Kubernetes.

Le Nœud Kubernetes : Le Fondement de la Puissance de Calcul

Un Nœud Kubernetes (parfois appelé Machine de Travail) est une machine qui fournit les ressources de calcul nécessaires—CPU, RAM et réseau—pour exécuter vos applications. Un cluster doit avoir au moins un Nœud, bien que les environnements de production en utilisent généralement plusieurs pour la redondance et l'évolutivité.

Responsabilités Clés d'un Nœud

Chaque Nœud exécute des composants essentiels qui lui permettent de communiquer avec le Plan de Contrôle et d'héberger les charges de travail des applications :

Kubelet : Un agent s'exécutant sur chaque Nœud responsable de la communication avec le Plan de Contrôle. Il travaille avec le runtime de conteneur pour s'assurer que les conteneurs décrits dans les PodSpecs sont en cours d'exécution et en bonne santé sur son Nœud.
Runtime de Conteneur : Le logiciel responsable du téléchargement des images et de l'exécution des conteneurs, généralement containerd ou CRI-O dans les clusters modernes.
Kube-proxy : Maintient les règles réseau sur le Nœud, permettant la communication vers et depuis les Pods, à la fois en interne et en externe.

Exemple Pratique : Représentation d'un Nœud

Lorsque vous inspectez les Nœuds de votre cluster, vous voyez l'infrastructure sous-jacente que Kubernetes utilise :

kubectl get nodes

NAME           STATUS   ROLES    AGE     VERSION
worker-node-01 Ready    <none>   2d1h    v1.27.4
worker-node-02 Ready    <none>   2d1h    v1.27.4

Point Clé : Un Nœud est la couche machine où l'exécution a lieu.

Le Pod Kubernetes : La Plus Petite Unité Déployable

Un Pod est l'unité atomique de déploiement dans Kubernetes. Ce n'est pas un conteneur en soi, mais plutôt une enveloppe autour d'un ou plusieurs conteneurs qui sont garantis d'être co-localisés sur le même Nœud et de partager les ressources.

Pourquoi des Pods au Lieu de Conteneurs Directs ?

Kubernetes gère les Pods, et non les conteneurs individuels, pour plusieurs raisons critiques :

Contexte Partagé : Tous les conteneurs d'un même Pod partagent le même espace de noms réseau (adresse IP et plage de ports) et peuvent communiquer facilement via localhost.
Stockage Partagé : Les conteneurs dans le même Pod peuvent accéder aux mêmes volumes de stockage montés.
Gestion du Cycle de Vie : Kubernetes traite le Pod comme une entité unique. Si un conteneur du Pod échoue, Kubernetes gère le redémarrage ou la recréation de la structure entière du Pod.

Anatomie d'un Pod

Le plus souvent, un Pod contient un seul conteneur d'application principal. Cependant, ils sont fréquemment utilisés pour le Modèle Sidecar, où un conteneur secondaire assiste le conteneur principal (par exemple, un agent de journalisation, un proxy de maillage de service).

Exemple de Définition de Pod (YAML Simplifié)

Le YAML suivant définit un Pod encapsulant un seul conteneur Nginx :

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

Point Clé : Un Pod est l'hôte logique de vos conteneurs d'application et est l'unité qui est planifiée sur un Nœud.

La Relation Fondamentale : Planification et Placement

L'interaction fondamentale entre les Pods et les Nœuds est régie par le Scheduler Kubernetes, qui réside dans le Plan de Contrôle.

Comment les Pods Atterrissent sur les Nœuds

Création du Pod : Un utilisateur soumet une définition YAML pour un Pod (ou un objet de niveau supérieur comme un Déploiement, qui crée des Pods) au Serveur API.
Décision de Planification : Le Scheduler identifie le meilleur Nœud disponible pour exécuter ce Pod en fonction des demandes de ressources, des contraintes et de la capacité disponible.
Liaison : Une fois qu'un Nœud est choisi, le Pod est lié à ce Nœud spécifique.
Exécution : Le Kubelet sur le Nœud assigné remarque la nouvelle affectation du Pod, télécharge les images nécessaires et démarre les conteneurs.

Point Crucial : Une fois qu'un Pod est planifié sur un Nœud, il reste sur ce Nœud jusqu'à ce qu'il soit terminé, qu'il plante définitivement ou que le Nœud tombe en panne. Kubernetes ne migre généralement pas les Pods en cours d'exécution entre les Nœuds.

Caractéristique	Nœud Kubernetes	Pod Kubernetes
Rôle	Fournit des ressources de calcul physiques/virtuelles.	Exécute un ou plusieurs conteneurs d'application.
Portée	Niveau infrastructure du cluster.	Niveau charge de travail de l'application.
Unité de Planification	Reçoit les Pods du Scheduler.	L'unité qui est planifiée sur un Nœud.
Composants	Kubelet, Runtime de Conteneur, Kube-proxy.	Conteneurs d'Application, volumes partagés, IP partagée.
Quantité	Généralement quelques-uns à plusieurs par cluster.	Peut être des centaines ou des milliers selon la charge de travail.

Un Exemple de Déploiement Réel

Imaginez une application web avec ce Déploiement :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: storefront
spec:
  replicas: 3
  selector:
    matchLabels:
      app: storefront
  template:
    metadata:
      labels:
        app: storefront
    spec:
      containers:
      - name: web
        image: example/storefront:v1
        ports:
        - containerPort: 8080

Cela ne crée pas trois nœuds. Cela crée trois réplicas de pods. Le planificateur décide ensuite quels nœuds existants doivent exécuter ces pods. Dans un petit cluster, vous pourriez voir ceci :

kubectl get pods -o wide

NAME                          READY   STATUS    NODE
storefront-6d8f8c7f9b-2xk9p   1/1     Running   worker-node-01
storefront-6d8f8c7f9b-7hxm4   1/1     Running   worker-node-02
storefront-6d8f8c7f9b-q4zpt   1/1     Running   worker-node-02

Il y a trois pods, mais seulement deux nœuds sont impliqués. Si worker-node-02 tombe en panne, deux réplicas disparaissent en même temps. Le Déploiement essaiera de les remplacer, mais il a besoin de capacité de nœud saine pour le faire. C'est pourquoi le placement des nœuds est important même lorsque votre Déploiement a plusieurs réplicas.

Si vous voulez encourager Kubernetes à répartir les réplicas sur les nœuds, utilisez des contraintes d'étalement de topologie ou l'anti-affinité de pod. Vous n'en avez pas besoin pour chaque petit outil interne, mais vous devriez y penser pour les services destinés aux clients où la défaillance d'un nœud ne devrait pas supprimer la majeure partie de la capacité.

Les Pods Sont Jetables ; Les Nœuds Sont une Capacité Gérée

Un état d'esprit sain dans Kubernetes est que les pods sont remplaçables. Les Déploiements, ReplicaSets, StatefulSets, Jobs et DaemonSets créent et remplacent les pods tout le temps. Un nom de pod avec un suffixe aléatoire n'est pas quelque chose sur lequel vous devriez compter pour toujours.

Les nœuds sont également remplaçables dans un cluster bien géré, mais ce sont des unités de capacité. Ils ont besoin de correctifs du système d'exploitation, de la santé du kubelet, de suffisamment d'espace disque, d'un runtime de conteneur fonctionnel et d'une connectivité réseau. Lorsqu'un nœud a un problème, de nombreux pods peuvent le ressentir en même temps.

Cette différence se manifeste dans la façon dont vous déboguez :

Si un pod échoue et que d'autres pods sur le même nœud sont sains, commencez par les logs du pod, la configuration, les sondes, l'image et les limites de ressources.
Si de nombreux pods non liés sur le même nœud échouent, commencez par le nœud : pression disque, pression mémoire, statut du kubelet, santé du CNI et logs du runtime de conteneur.
Si de nouveaux pods ne peuvent pas démarrer nulle part, regardez la capacité à l'échelle du cluster, les quotas, les règles de planification et la santé du plan de contrôle.

Malentendus Courants

Le premier malentendu est de penser qu'un pod est la même chose qu'un conteneur. La plupart des pods contiennent un conteneur principal, donc le raccourci semble inoffensif. Mais les sidecars rendent la distinction importante. Un proxy de maillage de service, un expéditeur de logs ou un conteneur d'assistance peut s'exécuter dans le même pod que l'application. Ils partagent l'espace de noms réseau du pod, donc localhost entre ces conteneurs fonctionne à l'intérieur de ce pod.

Le deuxième malentendu est de penser que Kubernetes déplace un pod en cours d'exécution vers un autre nœud comme une migration de VM en direct. Il ne le fait généralement pas. Si un nœud est drainé ou tombe en panne, Kubernetes termine ou perd l'ancien pod et crée un pod de remplacement ailleurs. Ce remplacement a une identité de pod différente, et toutes les modifications locales du système de fichiers du conteneur de l'ancien pod sont perdues à moins qu'elles n'aient été écrites sur un stockage persistant.

Le troisième malentendu est de supposer qu'un Service s'exécute sur un nœud. Un Service est une abstraction réseau stable devant les pods. Il sélectionne les pods par étiquettes et achemine le trafic vers leurs IP. Les nœuds fournissent l'endroit où ces pods s'exécutent, mais le Service lui-même n'est pas "sur" un nœud de travail de la même manière qu'un pod.

Comment Cela Affecte la Conception Quotidienne

Lorsque vous choisissez un nombre de réplicas, vous choisissez combien de copies de pods Kubernetes doit essayer de maintenir en cours d'exécution. Vous ne choisissez pas combien de nœuds existeront. Un Déploiement avec dix réplicas peut toujours placer plusieurs pods sur le même nœud à moins que vous n'ajoutiez des règles d'étalement et que le cluster ait suffisamment de capacité de nœuds.

Lorsque vous choisissez la taille des nœuds, vous choisissez la forme du pool de capacité. Quelques grands nœuds peuvent être efficaces, mais la défaillance d'un nœud supprime une plus grande partie de vos pods en cours d'exécution. Plus de petits nœuds peuvent améliorer l'isolation des défaillances, mais ils ajoutent des frais généraux et peuvent rendre le bin-packing moins efficace. Il n'y a pas de réponse universelle ; le bon choix dépend de la taille de la charge de travail, des besoins de disponibilité et du coût.

Les charges de travail avec état ajoutent une autre complication. Un StatefulSet crée toujours des pods, et ces pods s'exécutent toujours sur des nœuds, mais chaque pod peut avoir une identité stable et un volume persistant. Si le nœud meurt, Kubernetes peut recréer le pod ailleurs, mais la couche de stockage doit prendre en charge l'attachement ou l'accès au volume depuis le nouvel emplacement.

Bonnes Pratiques et Conseils de Dépannage

Comprendre cette architecture aide à la gestion pratique du cluster :

Gestion des Ressources

Demandes/Limites de Ressources : Définissez toujours les requests et limits de ressources dans vos spécifications de Pod. Cela permet au Scheduler de faire correspondre avec précision les Pods aux Nœuds qui ont une capacité suffisante, évitant ainsi la contention des ressources.
Pression sur le Nœud : Si un Nœud devient surchargé (plus d'espace disque ou de mémoire), le Kubelet signale cette condition. Kubernetes peut alors expulser les Pods de ce Nœud pour maintenir la stabilité.

Haute Disponibilité (HA)

Redondance : Pour atteindre la HA, vous devez exécuter plusieurs copies (réplicas) de vos Pods, gérées par des Déploiements ou des StatefulSets. Le Scheduler tentera de placer ces réplicas sur différents Nœuds pour garantir que la défaillance d'un Nœud ne fasse pas tomber l'ensemble de l'application.

Dépannage

Lorsqu'une application ne démarre pas :

Vérifiez le Statut du Pod : Utilisez kubectl describe pod <nom-du-pod>. Regardez la section 'Events' pour voir sur quel Nœud le Pod a été planifié.
Vérifiez le Statut du Nœud : Si le Pod est bloqué sur Pending, le problème est généralement lié à la planification (par exemple, aucun Nœud ne répond aux contraintes requises). Si le Pod est en cours d'exécution mais échoue, vérifiez les logs du Kubelet sur le Nœud spécifique où il a atterri.

Commandes utiles :

kubectl get pods -o wide
kubectl describe pod <nom-du-pod>
kubectl get nodes
kubectl describe node <nom-du-nœud>

La sortie -o wide est sous-estimée. Elle montre sur quel nœud chaque pod a atterri, ce qui est souvent l'indice qui sépare un problème d'application d'un problème d'infrastructure.

La Version Courte

Un nœud répond à "où cela peut-il s'exécuter ?" Un pod répond à "qu'est-ce qui devrait s'exécuter ensemble ?" Le planificateur connecte ces deux idées en plaçant les pods sur les nœuds. Une fois que vous voyez cette relation, les erreurs Kubernetes deviennent plus faciles à lire : les pods en attente sont souvent des problèmes de placement, les pods qui échouent sont souvent des problèmes de charge de travail, et les nœuds malsains peuvent créer de nombreux problèmes de pods en même temps.