Kubernetes 000 – Preambule : pourquoi apprendre Kubernetes ?

TL;DR

Kubernetes sert a orchestrer des applications conteneurisees sur un ensemble de machines. Il apporte un modele commun pour declarer l’etat attendu, distribuer les charges, remplacer les instances defaillantes et exposer les applications. Avant de parler de commandes, ce preambule permet de comprendre pourquoi Kubernetes existe.

La video de reference

La video d’introduction de la playlist Kubernetes v2 est disponible ici: https://www.youtube.com/watch?v=KViZkMialxo

Elle ouvre la serie avant les episodes consacres a l’histoire, a l’architecture, aux pods, a kubectl, au scheduler et aux premiers objets Kubernetes.

Kubernetes, c’est quoi exactement ?

Kubernetes est une plateforme d’orchestration. Au lieu de lancer manuellement des conteneurs sur une machine, on decrit ce que l’on veut: combien d’instances, quelle image, quels ports, quelles contraintes, quelles ressources. Kubernetes observe ensuite l’etat reel du cluster et essaie de le rapprocher de l’etat demande.

Cette idee change la maniere de raisonner: on ne pilote plus seulement des processus, on pilote un systeme distribue compose de noeuds, d’objets API, de controleurs et d’un plan de controle.

Le probleme que Kubernetes resout

Sans orchestrateur, il faut gerer soi-meme le placement des conteneurs, les redemarrages, les mises a jour, la decouverte de service, les certificats, la configuration et parfois le stockage. Cela fonctionne sur une petite application, mais devient fragile quand plusieurs services, environnements et equipes entrent en jeu.

Kubernetes fournit un langage commun pour tout cela: manifests YAML, API, controleurs, namespaces, labels, services et outils comme kubectl.

Le modele mental minimal

Un cluster Kubernetes contient un plan de controle et des noeuds de travail. L’utilisateur dialogue avec l’API Server. Les controleurs observent l’etat declare dans l’API. Le scheduler choisit ou placer les pods. Les kubelets, sur les noeuds, lancent les conteneurs via un runtime compatible.

Ce modele sera detaille dans les episodes suivants, mais il suffit deja a comprendre pourquoi Kubernetes est plus qu’un simple lanceur de conteneurs.

Commandes a garder en tete

kubectl cluster-info
kubectl get nodes
kubectl get pods -A
kubectl api-resources

Ces commandes ne remplacent pas l’apprentissage des concepts, mais elles donnent rapidement une premiere vision du cluster.

Liens utiles

• Playlist Kubernetes v2: https://www.youtube.com/playlist?list=PLn6POgpklwWo6wiy2G3SjBubF6zXjksap
• Depot Xavki Kubernetes v2: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Documentation Kubernetes – Overview: https://kubernetes.io/docs/concepts/overview/
• Formation Enix – Kubernetes: https://2026-05-enix.container.training/

Lien interne conseille

Pour demarrer la progression, consultez aussi Kubernetes 001 – Histoire, contexte et solutions.

FAQ

Faut-il deja connaitre Docker pour apprendre Kubernetes ?

Oui, au moins les bases: image, conteneur, port, volume, registry. Kubernetes orchestre des workloads conteneurises, donc ces notions reviennent partout.

Kubernetes remplace-t-il Docker ?

Non. Kubernetes orchestre des conteneurs. Il s’appuie sur un runtime de conteneurs via la CRI, par exemple containerd.

Pourquoi commencer par le pourquoi ?

Parce que Kubernetes est dense. Sans probleme concret en tete, les objets comme Pod, ReplicaSet ou Service ressemblent vite a une accumulation de YAML.

Le vrai changement de perspective

Le point le plus important, au debut, est de ne pas voir Kubernetes comme une simple surcouche a Docker. Avec un conteneur lance a la main, on raisonne en commande immediate: je demarre, je regarde les logs, j’arrete. Avec Kubernetes, on raisonne en intention durable: je declare qu’une application doit exister, etre exposee, etre redemarree si elle tombe, et parfois etre multipliee sur plusieurs replicas.

Cette difference parait theorique, mais elle change tout. Dans un environnement classique, l’administrateur ou le script d’exploitation porte beaucoup de logique: ou lancer l’application, quoi faire si elle tombe, comment la remplacer, comment gerer une mise a jour. Dans Kubernetes, une partie de cette logique est deplacee dans la plateforme. On donne une specification, puis des controleurs travaillent en continu.

Il faut donc accepter de perdre un peu de controle immediat pour gagner un systeme qui observe, compare et corrige. C’est ce qu’on appelle souvent la reconciliation: Kubernetes compare l’etat voulu et l’etat reel.

Exemple concret: une application web simple

Prenons une application web exposee en HTTP. Sans orchestrateur, il faut choisir une machine, lancer le conteneur, ouvrir le port, gerer les variables d’environnement, surveiller le processus et prevoir un redemarrage. Si la machine tombe, il faut relancer ailleurs. Si on veut trois instances, il faut reproduire la meme logique plusieurs fois.

Avec Kubernetes, cette application sera progressivement decrite par plusieurs objets: un Pod ou un Deployment pour executer le workload, un Service pour l’exposer dans le cluster, une ConfigMap ou un Secret pour injecter de la configuration, puis eventuellement un Ingress pour l’exposer vers l’exterieur.

Ce decoupage peut sembler plus complexe au depart, mais il rend chaque responsabilite explicite. C’est aussi pour cela qu’une formation Kubernetes commence souvent lentement: avant de vouloir tout deployer, il faut comprendre le role de chaque brique.

Erreurs frequentes au debut

• Croire que Kubernetes sert uniquement a lancer des conteneurs.
• Confondre image, conteneur, pod et deployment.
• Vouloir apprendre tous les objets Kubernetes en meme temps.
• Copier du YAML sans comprendre quel controleur va agir dessus.
• Oublier que Kubernetes est un systeme distribue: reseau, stockage et securite comptent autant que l’application.

Pour pratiquer apres cet episode

Avant meme de creer un pod, il est utile d’explorer un cluster existant ou un lab:

kubectl get nodes -o wide
kubectl get namespaces
kubectl get pods -A
kubectl api-resources | head

L’objectif n’est pas encore de tout comprendre. L’objectif est de voir que Kubernetes expose une API riche, organisee autour de ressources, et que kubectl n’est qu’un client pour interroger cette API.

Ce que Kubernetes apporte vraiment

Kubernetes n’apporte pas seulement une maniere de lancer des conteneurs. Il apporte surtout un cadre commun pour decrire et exploiter des applications. Ce cadre inclut une API, des objets, des conventions de nommage, des mecanismes de reconciliation et une separation claire entre l’etat souhaite et l’etat observe.

Cette approche devient utile des que l’on veut reproduire un environnement, partager une configuration, automatiser un deploiement ou deleguer une partie de l’exploitation a une plateforme. Un pod, un service ou un deployment ne sont pas seulement des bouts de YAML: ce sont des contrats passes avec le cluster.

Ce que Kubernetes ne resout pas automatiquement

Kubernetes est puissant, mais il ne rend pas une application fiable par magie. Si l’application demarre lentement, consomme trop de memoire, gere mal ses erreurs ou depend d’un service externe instable, Kubernetes ne fera que rendre ces comportements plus visibles.

Il faut donc continuer a travailler les bases:

• images propres et reproductibles;
• configuration explicite;
• logs exploitables;
• metriques et supervision;
• readiness et liveness probes;
• strategie de sauvegarde pour les donnees;
• droits limites et secrets bien geres.

Kubernetes fournit des mecanismes, mais l’architecture applicative et les pratiques d’exploitation restent essentielles.

Une progression raisonnable pour apprendre

Pour ne pas se perdre, il vaut mieux progresser par couches. D’abord comprendre le vocabulaire: cluster, noeud, pod, API Server, scheduler, kubelet. Ensuite manipuler quelques pods et lire leurs statuts. Puis passer aux manifests, aux labels, aux ReplicaSets, aux Deployments et aux Services.

Cette progression evite de commencer par des sujets avances comme les operateurs, le service mesh, le stockage complexe ou les politiques de securite. Ces sujets ont du sens, mais seulement quand les bases sont solides.

Questions a garder en tete

Pendant toute la serie, quelques questions reviennent souvent:

• quel objet suis-je en train de manipuler ?
• quel composant Kubernetes va agir sur cet objet ?
• quel est l’etat souhaite ?
• quel est l’etat reel ?
• ou puis-je lire les events, les logs et le status ?

Ces questions forment une grille de lecture simple. Elles aident a rester methodique quand Kubernetes semble trop vaste.

Conclusion

Ce preambule sert a poser le cadre: Kubernetes n’est pas seulement un outil de commande, c’est un systeme de convergence vers un etat desire. La suite de la playlist peut alors avancer progressivement: histoire, architecture, API, pods et premiers usages concrets.