Ressources Kubernetes : du Pod aux StatefulSets

Chaque application Kubernetes repose sur des objets qui définissent son comportement, sa configuration et ses interactions réseau. Cette page vous présente toutes les ressources à maîtriser, des Pods de base aux StatefulSets avancés, avec l'ordre idéal pour les apprendre.

Prérequis : architecture Kubernetes et kubectl configuré.

Pourquoi comprendre les ressources Kubernetes ?

Kubernetes ne gère pas directement vos conteneurs, il gère des objets qui décrivent l'état souhaité de votre application. En comprenant ces objets, vous pourrez :

• Déployer vos applications de manière reproductible (Deployments, StatefulSets)
• Exposer vos services sur le réseau (Services)
• Configurer vos applications sans modifier le code (ConfigMaps, Secrets)
• Isoler vos environnements (Namespaces)
• Automatiser les tâches ponctuelles et planifiées (Jobs, CronJobs)
• Garantir la présence d'agents sur chaque nœud (DaemonSets)

Ressources de base

Ces ressources permettent de déployer et exposer vos applications. Maîtrisez-les en premier.

Pod

Le Pod est l'unité d'exécution de Kubernetes. Il contient un ou plusieurs conteneurs qui partagent réseau et stockage. Les Pods sont éphémères, ne les créez jamais directement en production.

→ Apprendre les Pods Kubernetes

Deployment

Le Deployment gère le cycle de vie de vos Pods : création, scaling, mises à jour progressives. C'est la ressource que vous utiliserez le plus souvent pour déployer des applications sans état.

→ Créer et mettre à jour des Deployments Kubernetes

ReplicaSet

Le ReplicaSet maintient un nombre défini de Pods identiques. En pratique, vous ne le créez jamais directement, le Deployment le gère pour vous.

→ Comprendre les ReplicaSets Kubernetes

Service

Un Service expose vos Pods sur le réseau avec une IP stable. Comme les Pods peuvent être recréés à tout moment, le Service garantit un point d'accès permanent.

→ Exposer vos applications avec les Services Kubernetes

Configuration

Ces ressources permettent de configurer vos applications et d'organiser votre cluster.

ConfigMap

Un ConfigMap stocke la configuration non sensible de votre application : URLs, paramètres, fichiers de config. Il permet de séparer la configuration du code.

→ Utiliser les ConfigMaps Kubernetes

Secret

Un Secret stocke les données sensibles : mots de passe, clés API, certificats. Attention : un Secret n'est pas chiffré par défaut, seulement encodé en base64.

→ Stocker des données sensibles avec les Secrets Kubernetes

Namespace

Un Namespace isole un groupe de ressources dans le cluster. Il permet de séparer les environnements (dev, staging, prod) ou les équipes.

→ Comprendre les Namespaces Kubernetes

Ressources avancées

Ces ressources répondent à des besoins spécifiques : applications avec état, agents système et tâches planifiées.

StatefulSet

Un StatefulSet gère des applications avec état : bases de données, systèmes distribués. Contrairement au Deployment, il garantit :

• Des identités stables (pods numérotés : mysql-0, mysql-1, mysql-2)
• Un ordre de démarrage et d'arrêt déterministe
• Des volumes persistants liés à chaque pod

→ Déployer des applications avec état : StatefulSets Kubernetes

DaemonSet

Un DaemonSet garantit qu'un Pod tourne sur chaque nœud du cluster. Utilisé pour :

• Les agents de monitoring (Prometheus Node Exporter, Datadog)
• Les collecteurs de logs (Fluentd, Filebeat)
• Les agents réseau (CNI plugins, kube-proxy)

→ Exécuter un Pod sur chaque nœud : DaemonSets Kubernetes

Job et CronJob

Un Job exécute une tâche jusqu'à complétion : migration de base de données, backup, traitement batch. Un CronJob planifie cette exécution de façon récurrente.

→ Exécuter des tâches avec Jobs et CronJobs Kubernetes

Comment ces ressources travaillent ensemble

Une ressource seule ne sert presque jamais à rien. Les trois assemblages qui suivent couvrent la très grande majorité des déploiements réels, et ils se lisent comme des recettes : chaque numéro correspond à un objet à créer, dans cet ordre, parce que le suivant a besoin du précédent pour se lier à lui.

Application web classique (sans état)

C'est le montage que vous rencontrerez le plus souvent. Le point de vigilance est l'ordre des étapes 2 et 3 : le Service sélectionne les Pods par leurs labels, donc si le sélecteur ne correspond à aucun Pod du Deployment, le Service existe mais ne route vers rien, sans que Kubernetes ne signale d'erreur.

1. Un Namespace isole l'environnement
2. Un Deployment crée et maintient les Pods applicatifs
3. Un Service expose ces Pods sur le réseau interne
4. Un ConfigMap fournit la configuration
5. Un Secret injecte les identifiants

Application avec état (base de données)

Deux différences avec le montage précédent méritent votre attention. Le Service headless (champ clusterIP: None) ne fait pas de répartition de charge : il publie une entrée DNS par Pod, ce qui permet à un réplica de contacter nommément mysql-0 plutôt qu'une instance au hasard. Et les PersistentVolumeClaims sont générés automatiquement par le StatefulSet via son volumeClaimTemplates, un par Pod, conservés même si le Pod est recréé.

1. Un StatefulSet déploie les instances avec des identités stables
2. Un Service headless permet la découverte individuelle de chaque pod
3. Des PersistentVolumeClaims attachent le stockage à chaque instance
4. Un Secret stocke les credentials

Infrastructure système (monitoring)

Ce montage est celui des agents d'infrastructure, et il obéit à une contrainte que les deux précédents n'ont pas : vous ne choisissez pas le nombre de réplicas. Le DaemonSet en place exactement un par nœud, et il en ajoutera un automatiquement quand un nœud rejoindra le cluster. Prévoyez donc des requests CPU et mémoire modestes, puisqu'elles seront réservées sur chaque machine, y compris les plus petites.

1. Un DaemonSet déploie un agent sur chaque nœud
2. Un ConfigMap configure l'agent
3. Un Service expose les métriques

Fil rouge

Pensez à une application web + base de données : le Deployment lance les Pods frontend, un StatefulSet gère PostgreSQL, les Services exposent chacun, les ConfigMaps configurent les deux, et les Secrets stockent les credentials de connexion.

Dans quel ordre apprendre ces ressources ?

Cet ordre n'est pas un classement par difficulté, c'est une chaîne de dépendances : chaque niveau suppose que le précédent est acquis. Comptez une session par niveau, et validez chaque étape sur un cluster réel avant de passer à la suivante.

Niveau 1 : Ressources de base

Ces quatre objets forment le minimum pour faire tourner une application accessible. Le seul qui prête à confusion est le ReplicaSet : vous n'en écrirez jamais, mais vous le verrez apparaître dans kubectl get all après chaque mise à jour d'un Deployment, et savoir pourquoi vous évitera une longue perplexité.

1. Pods, comprendre l'unité d'exécution (mais ne jamais les créer seuls)

2. Deployments, gérer le cycle de vie des applications sans état

3. ReplicaSets, comprendre le mécanisme sous-jacent des Deployments

4. Services, exposer et connecter les Pods

Niveau 2 : Configuration

Ce niveau sort les valeurs variables de l'image de conteneur, ce qui permet de promouvoir la même image de la recette à la production. Traitez les Secrets immédiatement après les ConfigMaps : leur syntaxe est presque identique, mais leurs implications de sécurité n'ont rien à voir, et confondre les deux est l'erreur la plus fréquente à ce stade.

1. ConfigMaps, externaliser la configuration non sensible

2. Secrets, stocker les données sensibles

3. Namespaces, organiser et isoler les ressources

Niveau 3 : Ressources avancées

Ces trois contrôleurs répondent à des besoins que le Deployment ne sait pas couvrir : la persistance de l'identité, la présence sur chaque nœud et l'exécution finie. Abordez-les une fois seulement que le cycle de vie d'un Deployment est clair, sinon leurs différences de comportement au redémarrage paraîtront arbitraires.

1. StatefulSets, déployer des bases de données et systèmes distribués

2. DaemonSets, déployer des agents sur chaque nœud

3. Jobs et CronJobs, automatiser les tâches ponctuelles et planifiées

Travaux pratiques

Les exercices vivent dans le dépôt containers-training, sous le répertoire 03-Kubernetes/. Commencez par 00-prerequis/ pour vérifier que votre cluster et kubectl répondent, sinon les manifestes des dossiers suivants échoueront pour des raisons qui n'ont rien à voir avec les ressources étudiées ici. Le dossier vos-manifests/ sert de bac à sable pour vos propres essais.

• 03-Kubernetes/01-kubernetes-debutant/, Pods, Services, Deployments
• 03-Kubernetes/02-kubernetes-intermediaire/, ConfigMaps, Secrets, volumes
• 03-Kubernetes/03-kubernetes-avance/, StatefulSets, DaemonSets, Jobs

Testez vos connaissances

Ce questionnaire tire ses dix questions de la banque CKAD et porte uniquement sur les ressources décrites ci-dessus. Traitez-le sans revenir en arrière : les points manqués vous indiquent quel guide unitaire ouvrir en priorité, ce qui est plus utile qu'un score parfait obtenu en relisant.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

• Kubernetes ne pilote pas des conteneurs, il réconcilie des objets : vous décrivez un état souhaité, un contrôleur se charge de l'atteindre
• Le Pod est l'unité d'exécution, mais il ne se crée jamais directement en production : passez par un Deployment, un StatefulSet ou un DaemonSet
• Deployment pour le sans état, StatefulSet pour l'état : identités stables, ordre de démarrage et volumes attachés distinguent le second
• Le Service donne un point d'accès stable devant des Pods éphémères ; sans correspondance de labels, il route vers le vide en silence
• ConfigMap et Secret ont la même syntaxe mais pas les mêmes enjeux : un Secret est encodé en base64, pas chiffré, tant que le chiffrement au repos d'etcd n'est pas activé
• Le DaemonSet impose un Pod par nœud, ce qui rend ses requests de ressources structurantes pour tout le cluster
• Job et CronJob sont les seuls contrôleurs à considérer une terminaison comme un succès, pas comme une panne

Prochaines étapes

Écrire des manifests Kubernetes Structure YAML et bonnes pratiques

Probes Kubernetes Liveness, Readiness et Startup Probes

Stockage Kubernetes Volumes, PersistentVolumes et StorageClasses

RBAC Kubernetes Contrôler les accès au cluster

×

📖 Voir la documentation →