Bilan du chapitre : construire une application Kubernetes

Vous avez maintenant parcouru les ressources pour construire une application Kubernetes. C’est une étape importante, car tout le reste repose sur ces briques : déployer une application stateless ou stateful, l’exposer sur le réseau, gérer sa configuration, protéger ses données sensibles, exécuter des agents sur chaque nœud ou automatiser des traitements ponctuels.

Cette page ne remplace pas les guides détaillés. Elle sert à faire la synthèse, à remettre les concepts en perspective et à vous montrer où aller ensuite pour passer d’un usage basique de Kubernetes à des déploiements plus propres, plus fiables et plus proches de la production.

Ce que vous savez maintenant faire

À ce stade, vous êtes capable de :

• comprendre le rôle des principales ressources Kubernetes ;
• distinguer les objets qui exécutent, exposent, configurent ou sécurisent une application ;
• déployer une application stateless avec des Pods, des Services et des Deployments ;
• déployer une application stateful avec des StatefulSets ;
• exécuter un agent sur chaque nœud avec des DaemonSets ;
• externaliser la configuration avec des ConfigMaps ;
• stocker des données sensibles avec des Secrets ;
• exécuter des tâches ponctuelles avec des Jobs et des tâches planifiées avec des CronJobs.

Le vrai cap franchi

Vous ne découvrez plus seulement des objets Kubernetes un par un. Vous commencez à comprendre comment ils collaborent pour faire fonctionner une application dans un cluster.

Tableau de synthèse des ressources

Ressource	Rôle principal	Quand l’utiliser
Namespace	Isoler et organiser les ressources	Séparer des environnements, des équipes ou des projets
Pod	Exécuter un ou plusieurs conteneurs	Comprendre l’unité d’exécution de base
Service	Fournir un point d’accès réseau stable	Connecter ou exposer des Pods
ReplicaSet	Maintenir un nombre donné de Pods	Principalement via un Deployment
Deployment	Gérer des Pods stateless dans la durée	Déploiement, mise à jour, rollback, scaling
StatefulSet	Gérer des Pods stateful avec identité stable	Bases de données, applications à état
DaemonSet	Exécuter un Pod sur chaque nœud	Agents de logs, monitoring, réseau
ConfigMap	Fournir la configuration non sensible	Paramètres applicatifs, fichiers de config
Secret	Fournir des données sensibles	Mots de passe, clés API, certificats
Job	Exécuter une tâche jusqu’à complétion	Migration, batch, import, export
CronJob	Planifier des Jobs	Sauvegarde, purge, synchronisation régulière

Glissez pour voir

Comment ces ressources travaillent ensemble

Pris séparément, chaque objet Kubernetes a un rôle simple. En pratique, une application combine souvent plusieurs de ces ressources.

Exemple d’enchaînement classique

Une application Kubernetes simple repose souvent sur cette logique :

1. un Namespace pour isoler l’environnement ;
2. un Deployment pour créer et maintenir les Pods ;
3. un Service pour exposer les Pods sur le réseau interne ;
4. un ConfigMap pour injecter la configuration non sensible ;
5. un Secret pour les identifiants et données sensibles ;
6. éventuellement un Job pour une migration ou un traitement ponctuel ;
7. éventuellement un CronJob pour une tâche récurrente.

Ce qu’il faut retenir

• Le Pod exécute réellement les conteneurs.
• Le Deployment gère les Pods stateless sur la durée.
• Le StatefulSet gère les Pods stateful avec des identités stables et du stockage persistant.
• Le DaemonSet garantit qu’un Pod tourne sur chaque nœud éligible.
• Le ReplicaSet est un mécanisme intermédiaire, souvent invisible pour l’utilisateur.
• Le Service fournit une adresse stable vers les Pods.
• Le ConfigMap et le Secret injectent ce dont l’application a besoin pour fonctionner.
• Le Job et le CronJob couvrent les traitements qui ne tournent pas en continu.

Les relations importantes à bien comprendre

Pod et Deployment

Un Pod peut être créé seul, mais dans la majorité des cas applicatifs, vous utiliserez un Deployment pour éviter une gestion manuelle fragile.

Service et Pod

On ne pointe pas une application vers l’IP d’un Pod. On passe par un Service, car les Pods sont éphémères.

Deployment et ReplicaSet

Un Deployment ne gère pas directement chaque Pod. Il s’appuie sur un ReplicaSet, qui maintient le nombre souhaité de répliques.

ConfigMap et Secret

Les deux servent à injecter des données dans les Pods, mais :

• ConfigMap = configuration non sensible ;
• Secret = données sensibles.

Job et CronJob

• Job = une exécution ponctuelle jusqu’à complétion ;
• CronJob = planification automatique de Jobs.

StatefulSet et PersistentVolumeClaim

Un StatefulSet crée automatiquement un PVC (PersistentVolumeClaim) par Pod grâce à son volumeClaimTemplates. Chaque Pod conserve son volume même après un redémarrage.

DaemonSet et nœuds

Un DaemonSet s’assure qu’un Pod tourne sur chaque nœud éligible du cluster. Il est utilisé pour les agents système (logs, monitoring, réseau).

Les erreurs fréquentes en début de parcours

Quand on débute avec Kubernetes, certaines confusions reviennent très souvent.

1. Créer des Pods à la main pour une application durable

Un Pod seul est utile pour apprendre ou tester. Pour une application stateless, utilisez un Deployment.

2. Confondre Service et Ingress

Un Service fournit un point d’accès stable à des Pods. Un Ingress ajoute du routage HTTP/HTTPS au-dessus de Services.

3. Utiliser un ConfigMap pour des mots de passe

Un ConfigMap n’est pas fait pour stocker des données sensibles. Utilisez un Secret.

4. Penser qu’un ReplicaSet remplace un Deployment

Le ReplicaSet maintient un nombre de Pods, mais ne gère pas correctement les mises à jour applicatives comme le fait un Deployment.

5. Oublier le comportement des mises à jour de ConfigMaps et Secrets

• les variables d’environnement ne se mettent pas à jour automatiquement ;
• les volumes se propagent avec délai ;
• subPath ne se rafraîchit pas automatiquement.

6. Utiliser un Deployment pour une tâche batch

Une tâche ponctuelle ou planifiée doit aller dans un Job ou un CronJob, pas dans un Deployment.

7. Utiliser un Deployment pour une base de données

Une base de données a besoin d’une identité stable et d’un stockage persistant. Utilisez un StatefulSet, pas un Deployment.

8. Confondre DaemonSet et Deployment avec nodeSelector

Un DaemonSet garantit un Pod par nœud éligible. Un Deployment avec nodeSelector peut créer zéro ou plusieurs Pods par nœud selon les répliques.

Erreur de raisonnement classique

Kubernetes ne consiste pas à empiler des objets “parce qu’ils existent”. Chaque ressource répond à un besoin précis. La bonne question est toujours : quel problème suis-je en train de résoudre ?

Dans quel ordre apprendre les ressources

Si vous deviez refaire ce chapitre avec du recul, voici l’ordre le plus logique :

1. Namespaces — Pour comprendre comment organiser les ressources dans le cluster.

2. Pods — Pour identifier l’unité d’exécution de base.

3. Services — Pour relier et exposer les Pods de manière stable.

4. Deployments — Pour déployer une application stateless de façon exploitable.

5. ReplicaSets — Pour comprendre le mécanisme utilisé par les Deployments.

6. ConfigMaps et Secrets — Pour séparer configuration et données sensibles du code applicatif.

7. StatefulSets — Pour comprendre les workloads avec état et stockage persistant.

8. DaemonSets — Pour exécuter des agents sur chaque nœud du cluster.

9. Jobs et CronJobs — Pour couvrir les traitements ponctuels et planifiés.

Contrôle des connaissances

Vous pouvez maintenant vérifier que les notions essentielles sont bien acquises.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

25 questions

15 min.

80% 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

Travaux pratiques

La théorie seule ne suffit pas. Pour ancrer les concepts durablement, passez par les travaux pratiques disponibles dans le dépôt GitHub associé.

TP Kubernetes sur GitHub Manipulez les ressources de base, testez vos manifests et observez le comportement réel du cluster.

La suite du parcours Kubernetes

Vous connaissez maintenant les objets fondamentaux de Kubernetes. La prochaine étape consiste à apprendre à les utiliser de manière plus propre, plus fiable et plus proche d’un contexte de production.

La suite du parcours peut se résumer en cinq axes :

• écrire de meilleurs manifests pour produire des déploiements plus lisibles et maintenables ;
• fiabiliser les applications avec les probes, les ressources et le scaling ;
• gérer le réseau et l’exposition avec les Services, l’Ingress et les politiques réseau ;
• maîtriser le stockage et les workloads avancés pour les applications stateful ou spécialisées ;
• sécuriser le cluster et les workloads avec RBAC, Secrets et politiques de sécurité.

Écrire des manifests Kubernetes La suite la plus naturelle pour produire des déploiements propres.

Probes Kubernetes Rendre vos applications réellement exploitables et fiables.

Ingress Kubernetes Apprendre à exposer correctement vos applications.

Sécuriser Kubernetes Durcir le cluster et mieux protéger les workloads.

Ce qu’il faut retenir avant d’aller plus loin

Les ressources de base de Kubernetes forment un socle cohérent : les Pods exécutent, les Services exposent, les Deployments pilotent, les ConfigMaps configurent, les Secrets protègent, et les Jobs automatisent des traitements ciblés.

Si ces concepts sont clairs pour vous, vous êtes prêt à passer à l’étape suivante : écrire de meilleurs manifests et construire des déploiements plus robustes.

×

📖 Voir la documentation →