Qu’est-ce qu’un nœud Kubernetes ?
Renforcez votre sécurité cloud
Découvrez des pratiques avancées pour réduire les risques, prioriser les actions et protéger vos environnements cloud.
Un nœud Kubernetes est une machine de travail de votre cluster qui exécute des applications en containers. C’est l’ordinateur réel, physique ou virtuel, qui fait tourner vos applications.
Chaque nœud contient les services nécessaires à l’exécution des pods et reste géré par les composants du control plane. Un nœud peut être un serveur physique dans un data center on-premises ou une machine virtuelle hébergée dans le cloud, sur AWS EC2, Google Compute Engine ou Azure Virtual Machines.
Chaque nœud exécute des composants essentiels. On y trouve le kubelet, qui garantit que les containers tournent bien dans les pods. Il y a aussi le container runtime, en général containerd ou CRI-O, l’implémentation de l’interface Container Runtime Interface. Enfin, kube-proxy gère les règles réseau, même si des dataplanes CNI basés sur eBPF comme Cilium peuvent le remplacer entièrement. Le nœud fournit les ressources de calcul réelles (CPU, mémoire, stockage et réseau) que les pods consomment pour exécuter les applications.
Qu’est-ce qu’un pod Kubernetes ?
Un pod est la plus petite unité déployable que vous créez dans Kubernetes. Plutôt que d’exécuter les containers directement, Kubernetes regroupe un ou plusieurs containers dans un pod. Ce pod agit comme une enveloppe qui fournit des ressources partagées : volumes de stockage, namespace réseau et spécifications d’exécution des containers.
Les containers d’un même pod partagent une adresse IP et un espace de ports. Ils communiquent entre eux via localhost et accèdent à des volumes de stockage partagés. Ce couplage étroit permet trois patterns multi-containers standards : le sidecar (agent de logging ou de monitoring aux côtés de l’application principale), l’ambassador (proxy qui simplifie les connexions aux services externes) et l’adapter (qui normalise le format de sortie de containers hétérogènes). Par exemple, un pattern sidecar peut associer un container nginx à un container Fluent Bit qui envoie les logs vers Elasticsearch. La plupart des pods ne contiennent toutefois qu’un seul container, suivant le principe d’une application principale par pod.
Nœuds et pods Kubernetes : différences fondamentales
La distinction fondamentale entre nœuds et pods tient à leur rôle dans la hiérarchie Kubernetes. Les nœuds sont des composants d’infrastructure qui fournissent les ressources physiques ou virtuelles. Les pods, eux, sont des abstractions applicatives qui consomment ces ressources.
Commandes de diagnostic rapides :
# View all nodes with IP addresses and roles kubectl get nodes -o wide # Inspect node details, conditions, and capacity kubectl describe node # List all pods across namespaces with node placement kubectl get pods -A -o wide # Examine pod events and configuration kubectl describe pod -n # Check real-time resource usage kubectl top nodes kubectl top pods -ACes commandes vous aident à évaluer rapidement l’état des nœuds, le placement des pods et la consommation de ressources dans tout votre cluster.
Un node pool (ou node group sur EKS) représente un groupe de nœuds qui partagent le même type d’instance, la même zone de disponibilité et la même configuration. Cela permet de répondre à des besoins variés : nœuds GPU pour le machine learning ou instances spot pour les jobs batch.
Les node pools interagissent avec l’autoscaling à deux niveaux :
Horizontal Pod Autoscaler (HPA) ajuste le nombre de replicas de pods selon les métriques CPU et mémoire.
Cluster Autoscaler ajoute des nœuds à un pool quand des pods sont en attente faute de ressources, puis retire les nœuds sous-utilisés après un délai de scale-down.
Par exemple, si HPA fait passer un Deployment de 5 à 20 replicas mais que seuls 10 tiennent sur les nœuds existants, le Cluster Autoscaler provisionne des nœuds supplémentaires dans le pool adéquat pour accueillir les 10 pods restants.
Comment les nœuds et les pods fonctionnent ensemble dans l’architecture Kubernetes
Le cluster Kubernetes orchestre la relation entre nœuds et pods via le control plane. Quand vous déployez une application, le scheduler Kubernetes évalue les nœuds selon plusieurs critères : resource requests des pods, règles d’affinité et d’anti-affinité, contraintes de répartition topologique, taints et tolerations, et policies de scheduling personnalisées. Il associe ensuite chaque pod à un seul nœud qui satisfait toutes les exigences. Sur chaque nœud, le kubelet veille à ce que les pods assignés tournent et restent sains.
Cette architecture rend possibles plusieurs fonctionnalités clés de Kubernetes :
Placement automatique des pods : le scheduler répartit intelligemment les pods entre les nœuds selon les ressources disponibles et les contraintes.
Auto-réparation : si un pod échoue, Kubernetes crée automatiquement un remplaçant ; si un nœud tombe, les pods sont replanifiés sur des nœuds sains.
Scaling : l’autoscaling horizontal des pods crée ou supprime des replicas selon les métriques, tandis que l’autoscaling du cluster ajoute ou retire des nœuds selon la demande en ressources des pods.
Répartition de charge : plusieurs replicas d’un pod se répartissent sur différents nœuds pour assurer une haute disponibilité.
La relation entre nœuds et pods s’étend aux controllers Kubernetes, qui gèrent le cycle de vie des pods :
Deployment : gère les replicas de pods stateless avec des mises à jour progressives (applications web, API).
StatefulSet : gère les pods stateful dotés d’identités réseau stables et d’un stockage persistant (bases de données, files de messages).
DaemonSet : garantit un pod par nœud pour les services à l’échelle du cluster (collecteurs de logs, agents de monitoring).
Job/CronJob : exécute des pods jusqu’à leur terme pour du traitement batch ou des tâches planifiées.
Les Deployments gèrent l’état souhaité des replicas de pods sur les nœuds. Lors des mises à jour, ils créent de nouveaux pods avant de supprimer les anciens.
Implications de sécurité des nœuds et des pods
Le guide pratique des responsables sécurité
Obtenez des conseils concrets pour structurer votre stratégie CloudSec et aligner sécurité, équipes et priorités métier.
La sécurité diffère nettement entre les nœuds et les pods, en raison de leurs rôles distincts dans le cluster. Les organisations rattachent en général ces contrôles à des cadres de conformité :
CIS Kubernetes Benchmark fournit plus de 100 contrôles couvrant le durcissement des nœuds (4.1 : restreindre les permissions du kubelet) et la sécurité des pods (5.2 : limiter les containers privilégiés).
NIST 800-190 traite la sécurité des containers sur tout le cycle de vie des images, le runtime et l’orchestration.
ISO 27001 et SOC 2 imposent des contrôles d’accès documentés et une journalisation d’audit, au niveau de l’infrastructure comme des applications.
Les outils de policy as code comme OPA Gatekeeper, Kyverno ou le Wiz Policy Engine appliquent ces standards automatiquement. Ils bloquent les déploiements de pods non conformes et signalent les nœuds mal configurés avant leur passage en production.
Une visibilité agentless et unifiée sur les nœuds, les pods et les identités permet d’appliquer le least privilege. Elle détecte les tentatives de container escape et empêche le lateral movement en corrélant le contexte de l’infrastructure et des applications. La sécurité des nœuds vise à protéger l’infrastructure sous-jacente : système d’exploitation, kubelet et container runtime. Elle passe par le durcissement de l’OS hôte, la gestion des accès SSH, la mise à jour des paquets système et la segmentation réseau au niveau de l’infrastructure.
La sécurité des pods s’exerce au niveau applicatif et comprend plusieurs éléments clés :
Security contexts : définissent les réglages de privilège et de contrôle d’accès des pods et des containers via un security context ;
Pod security standards et admission : appliquent les Pod Security Standards (PSS) à l’aide des controllers Pod Security Admission (PSA). PodSecurityPolicy a été supprimé dans Kubernetes v1.25 et remplacé par le plugin d’admission PSA intégré, avec les niveaux Restricted, Baseline et Privileged ;
Network policies : contrôlent les flux de trafic entre les pods au niveau applicatif ;
Service accounts : gèrent les identités des pods et les permissions RBAC dans le cluster. Appliquez le least privilege en limitant strictement les rôles et définissez automountServiceAccountToken: false pour les pods qui n’ont pas besoin d’accéder à l’API ;
Gestion des secrets : utilisez des Kubernetes Secrets avec le chiffrement d’etcd au repos activé. Intégrez des coffres externes comme HashiCorp Vault, AWS Secrets Manager ou Azure Key Vault via le Secrets Store CSI Driver pour une rotation automatique et une exposition réduite du cluster.
Les vulnérabilités de container escape constituent un risque critique : un attaquant qui s’échappe d’un container peut compromettre le nœud entier, puis réaliser un lateral movement vers d’autres pods. On comprend alors pourquoi les stratégies defense-in-depth doivent couvrir les contrôles de sécurité au niveau des nœuds comme des pods.
Gestion et allocation des ressources entre nœuds et pods
La gestion des ressources dans Kubernetes repose sur un système hiérarchique : les nœuds fournissent les ressources et les pods les consomment via des requests et des limits. Chaque nœud dispose de ressources allouables (CPU, mémoire, stockage) que le kubelet réserve à l’exécution des pods, une fois pris en compte les daemons système et les composants Kubernetes.
Les pods expriment leurs besoins en ressources via plusieurs mécanismes :
Resource requests : quantité minimale de CPU et de mémoire garantie au pod ;
Resource limits : quantité maximale de ressources que le pod peut consommer ;
Classes de qualité de service (QoS) : Kubernetes attribue les classes Guaranteed, Burstable ou BestEffort selon les requests et les limits.
Le scheduler s’appuie sur les resource requests pour décider du placement, en vérifiant que les nœuds disposent d’assez de capacité. Si un pod dépasse sa limite de mémoire, le kernel déclenche un OOMKill immédiat du container. Les limites CPU, elles, throttlent l’usage via les quotas CFS sans arrêter le pod. Quand un nœud manque de ressources, des conditions de node pressure apparaissent et provoquent l’éviction de pods selon leur classe QoS et leur consommation.
Une bonne gestion des ressources commence par la surveillance de la capacité des nœuds. En suivant l’utilisation des ressources sur l’ensemble des nœuds, vous repérez les goulets d’étranglement. Des insights de risque et de capacité tenant compte du contexte aident à dimensionner correctement les requests et limits des pods. Vous évitez ainsi les containers OOMKilled et le throttling CPU avant qu’ils ne dégradent les performances ou ne déclenchent des défaillances en cascade en production. À noter : Kubernetes prend officiellement en charge des clusters allant jusqu’à 5 000 nœuds et 150 000 pods, d’après les seuils de scalabilité documentés par le projet Kubernetes. Vous devez aussi dimensionner les pods avec des requests et limits adaptés aux besoins réels de l’application. L’affinité et l’anti-affinité de nœud pilotent le placement selon les labels, tandis que les taints et tolerations autorisent ou interdisent des pods sur certains nœuds. Par exemple, voici comment dédier des nœuds GPU aux workloads de machine learning :
# Taint GPU nodes kubectl taint nodes gpu-node-1 workload=ml:NoSchedule # Pod tolerates the taint tolerations: - key: workload operator: Equal value: ml effect: NoSchedule # Require GPU node via affinity affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: accelerator operator: In values: - gpuAinsi, seuls les pods de machine learning dotés de la toleration correspondante peuvent se planifier sur ces nœuds GPU coûteux.
Surveillance et dépannage des nœuds et des pods
Le dépannage dans Kubernetes n’aborde pas les nœuds et les pods de la même façon. La traçabilité code-to-cloud réduit le mean time to resolution (MTTR) : elle relie les pods défaillants à leurs manifests source, à leurs container images et aux équipes responsables. Elle corrèle ensuite les détections en runtime avec les chemins d’exposition réels grâce au security graph. Les problèmes de nœud se traduisent souvent par des incidents systémiques touchant plusieurs pods. Les problèmes de pod, à l’inverse, sont généralement propres à l’application ou liés à la configuration du container.
Pour dépanner les nœuds, concentrez-vous sur ces points :
État et conditions du nœud : vérifiez le statut Ready et les conditions MemoryPressure, DiskPressure, PIDPressure et NetworkUnavailable, chacune signalant un épuisement de ressources ou un problème de connectivité précis ;
Ressources système : surveillez le CPU, la mémoire, l’usage disque et la connectivité réseau au niveau de l’OS ;
Logs du kubelet : examinez les logs du kubelet à la recherche d’erreurs liées au cycle de vie des pods ou aux échanges avec l’API server ;
Container runtime : vérifiez que le container runtime fonctionne et parvient à récupérer les images.
Le dépannage des pods suppose de diagnostiquer des modes de défaillance précis.
Pods en attente (Pending)
vérifiez les événements de kubectl describe pod : « Insufficient CPU/memory » signale qu’il faut ajouter des nœuds ou réduire les requests ;
repérez « 0/3 nodes available: taint », puis ajoutez des tolerations ou retirez les taints ;
vérifiez « ImagePullBackOff » en contrôlant le nom de l’image, les identifiants du registry et l’accès réseau.
CrashLoopBackOff
consultez les logs du container avec kubectl logs --previous ;
vérifiez la configuration des probes liveness et readiness, parfois trop agressives ;
contrôlez les dependencies de l’application (connexions aux bases de données, fichiers de configuration).
NodeNotReady
connectez-vous en SSH au nœud et lancez systemctl status kubelet ;
vérifiez le plugin CNI avec kubectl get pods -n kube-system | grep cni ;
examinez les conditions du nœud avec kubectl describe node pour la pression disque, mémoire ou PID.
Cette approche méthodique permet d’isoler l’origine du problème : contraintes de scheduling, erreurs applicatives ou défaillances d’infrastructure.
Des commandes de dépannage courantes aident à diagnostiquer les problèmes aux deux niveaux. kubectl describe fournit notamment des informations détaillées sur le statut, les événements et les conditions des nœuds comme des pods.
Comment Wiz sécurise les nœuds et les pods Kubernetes
Wiz offre une visibilité agentless sur toute votre infrastructure Kubernetes et analyse les nœuds comme les pods, sans impact sur les performances ni complexité de déploiement. La plateforme dresse un inventaire complet de vos ressources Kubernetes, de l’infrastructure des nœuds jusqu’aux containers individuels qui tournent dans les pods. Vos équipes de sécurité comprennent ainsi l’intégralité de leur surface d’attaque.
Le Wiz Security Graph cartographie les relations entre nœuds, pods, containers, identités, données sensibles et services cloud. Il révèle ainsi les attack paths réels à travers les couches d’infrastructure. Il priorise ensuite la remédiation selon l’exploitabilité (exploits actifs, CVE weaponisées), l’exposition (accès Internet, permissions excessives) et le rayon d’impact (ou « blast radius ») (accès aux données les plus sensibles). Cette compréhension contextuelle montre comment un pod compromis peut obtenir un accès au niveau du nœud, ou comment un nœud mal configuré peut exposer plusieurs pods. En corrélant les vulnérabilités, les erreurs de configuration, l’exposition réseau et les permissions d’identité sur les nœuds et les pods, Wiz identifie les combinaisons toxiques à l’origine de risques réels.
Un Runtime Sensor eBPF léger ajoute des détections real-time sur les nœuds et les pods. Il repère les container escapes, les tentatives de privilege escalation, les processus de crypto-mining, les reverse shells et les connexions sortantes suspectes. Le tout avec un contexte de réponse précis au niveau du processus et sans surcharge d’agent. Le sensor surveille à la fois les appels système au niveau du nœud et le comportement applicatif au niveau du pod. Il détecte ainsi les activités anormales, les tentatives d’accès non autorisées et les compromissions potentielles dès qu’elles surviennent.
L’attack path analysis montre comment un pod compromis peut obtenir un accès au niveau du nœud, puis atteindre des ressources cloud plus larges via des combinaisons de risques toxiques. Cette vision d’ensemble permet une remédiation priorisée selon l’exploitabilité réelle, et non selon des scores de gravité théoriques.
Wiz Code applique le shift left (approche préventive en amont du cycle de développement) en analysant les templates IaC, les Helm charts et les container images dans les pipelines CI. Il bloque ensuite les déploiements risqués grâce au même policy engine que celui qui gouverne le runtime. Cette approche unifiée évite la dérive des policies et garantit que les Pod Security Standards appliqués en production sont validés avant la fusion du code. En analysant les définitions YAML, les Helm charts et les container images avant le déploiement, vos équipes détectent et corrigent les problèmes avant qu’ils n’atteignent les nœuds et les pods en production.
Une protection complète des workloads couvre aussi bien les vulnérabilités des container images dans les pods que les risques au niveau de l’OS sur les nœuds worker, avec une priorisation unifiée des risques. Cette approche supprime le besoin d’outils distincts pour la sécurité des nœuds et des pods, tout en appliquant des policies cohérentes sur l’ensemble de votre parc Kubernetes. Envie de découvrir une visibilité agentless et code-to-cloud sur vos nœuds et vos pods, avec des insights graphiques priorisés par le risque qui révèlent les attack paths réels plutôt que d’interminables listes de vulnérabilités ? Voir Wiz en action et découvrez comment Wiz transforme la complexité de Kubernetes en actions concrètes.
Découvrez Wiz en action
Voyez comment Wiz offre une visibilité complète et aide vos équipes à corriger les risques cloud plus vite.
