Bilan du chapitre : construire une application Kubernetes

Vous avez maintenant parcouru les ressources de base pour construire une application Kubernetes. C'est une étape importante, car tout le reste repose sur ces briques : déployer une application, la mettre à jour sans interruption, l'exposer sur le réseau, gérer sa configuration, protéger ses données sensibles et cloisonner le tout dans un namespace.

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 ressources de base de Kubernetes ;
• distinguer les objets qui exécutent, exposent, configurent ou cloisonnent une application ;
• déployer une application avec des Pods, des ReplicaSets et des Deployments ;
• la mettre à jour progressivement et revenir en arrière avec les rolling updates et les rollbacks ;
• l'exposer sur le réseau interne avec un Service ;
• externaliser la configuration avec des ConfigMaps ;
• stocker des données sensibles avec des Secrets ;
• isoler et organiser le tout avec des Namespaces.

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
ReplicaSet	Maintenir un nombre donné de Pods	Principalement via un Deployment
Deployment	Gérer des Pods dans la durée	Déploiement, mise à jour, rollback, scaling
Rolling update	Remplacer les Pods progressivement	Mettre à jour sans couper le service
Service	Fournir un point d'accès réseau stable	Connecter ou exposer des Pods
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

Glissez pour voir

Quatre ressources reviendront plus loin dans le parcours, et il est utile de savoir dès maintenant qu'elles existent, ne serait-ce que pour ne pas détourner un Deployment de son usage :

Ressource	Rôle principal	Où elle est enseignée
Job	Exécuter une tâche jusqu'à complétion	Déployer ses applications
CronJob	Planifier des Jobs	Déployer ses applications
StatefulSet	Gérer des Pods à état avec identité stable	Workloads avancés
DaemonSet	Exécuter un Pod sur chaque nœud	Workloads avancés

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. une rolling update à chaque nouvelle version, et un rollback le jour où elle se passe mal.

Ce qu'il faut retenir

Ces six lignes résument la chaîne de responsabilité. Lues de haut en bas, elles racontent ce qui se passe quand vous déployez : un objet pilote le suivant, jusqu'au conteneur qui tourne réellement.

• Le Pod exécute réellement les conteneurs.
• Le ReplicaSet maintient le nombre de copies, souvent invisible pour vous.
• Le Deployment pilote les ReplicaSets, donc les mises à jour et les retours arrière.
• Le Service fournit une adresse stable vers les Pods, qui eux sont éphémères.
• Le ConfigMap et le Secret injectent ce dont l'application a besoin pour fonctionner.
• Le Namespace cloisonne les noms et sert de périmètre aux quotas et au RBAC.

Les relations importantes à bien comprendre

Les confusions durables ne portent presque jamais sur un objet isolé, mais sur la frontière entre deux objets proches. Les sept paires ci-dessous sont celles qui reviennent le plus souvent en début de parcours ; si l'une d'elles reste floue, c'est le signe qu'il faut rouvrir la leçon correspondante.

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

Ces deux-là sont les seuls contrôleurs à considérer qu'un Pod qui s'arrête a réussi, là où tous les autres y voient une panne à réparer.

• 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

C'est l'erreur qui coûte le plus cher en temps de diagnostic, parce qu'elle ne produit aucun message : la configuration a bien changé côté cluster, et l'application continue de servir l'ancienne. Trois comportements différents cohabitent selon le mode d'injection.

• les variables d'environnement ne se mettent jamais à jour, il faut redémarrer les Pods ;
• les volumes se propagent avec un délai pouvant atteindre deux minutes, et non une ;
• subPath ne se rafraîchit jamais.

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

C'est l'ordre suivi par ce chapitre, et il n'a rien d'arbitraire : chaque leçon s'appuie sur la précédente. Si une notion vous a échappé, reprenez-la à sa place dans cette chaîne, pas isolément.

1. Les Pods, pour identifier l'unité d'exécution de base.

2. Les Deployments, pour déployer une application de façon exploitable.

3. Les ReplicaSets, pour comprendre le mécanisme sur lequel s'appuie un Deployment.

4. Rolling updates et rollbacks, pour mettre à jour sans couper le service, et savoir revenir en arrière.

5. Les Services, pour relier et exposer les Pods de manière stable.

6. Les ConfigMaps, pour sortir la configuration du code applicatif.

7. Les Secrets, pour les données sensibles, et pour mesurer ce qu'ils ne protègent pas.

8. Les Namespaces, pour cloisonner, puis appliquer quotas et RBAC.

Contrôle des connaissances

Vous pouvez maintenant vérifier que les notions essentielles sont 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

Les 25 questions sont tirées uniquement dans les neuf leçons de ce chapitre, à raison de deux ou trois par leçon. Si une famille de questions vous met en difficulté, c'est la leçon correspondante qu'il faut relire, pas l'ensemble.

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. Reste à apprendre à les employer de façon 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 forment un socle cohérent, et chacune a un seul rôle : les Pods exécutent, les Services exposent, les Deployments pilotent, les ConfigMaps configurent, les Secrets protègent, et les Jobs automatisent un traitement ponctuel.

Si ces concepts sont clairs pour vous, vous êtes prêt pour la suite : écrire de meilleurs manifestes et construire des déploiements plus robustes.

×

📖 Voir la documentation →