Kubernetes 001 – Histoire, contexte et solutions

TL;DR

Kubernetes nait d’un besoin simple a formuler mais difficile a tenir: executer des applications conteneurisees de facon fiable sur plusieurs machines. Son succes vient de son API declarative, de son ecosysteme et de sa capacite a devenir un socle commun entre developpement, exploitation et plateforme.

La video de reference

Video: https://www.youtube.com/watch?v=eRH_cetVAck

Elle fait le pont entre le preambule et les episodes d’architecture, en expliquant pourquoi Kubernetes s’est impose dans l’univers cloud-native.

Le contexte avant Kubernetes

Les conteneurs ont simplifie le packaging applicatif: une image embarque l’application et ses dependances. Mais lancer un conteneur n’est qu’une partie du probleme. Il faut aussi choisir une machine, surveiller l’etat, relancer en cas de panne, publier un service, mettre a jour sans tout couper et gerer la configuration.

Quand les applications deviennent composees de nombreux services, ces operations ne peuvent plus rester purement manuelles.

L’apport de Kubernetes

Kubernetes propose une API centrale et des objets standards. On decrit des Pods, ReplicaSets, Deployments, Services, ConfigMaps ou Secrets. Le systeme observe ensuite le cluster et fait travailler ses controleurs pour rapprocher l’etat reel de l’etat voulu.

Cette approche explique pourquoi Kubernetes n’est pas seulement un outil d’infrastructure. C’est aussi un contrat entre les equipes: les developpeurs declarent des besoins, la plateforme les execute.

Les grandes familles de solutions

Dans le monde de l’orchestration, plusieurs familles existent: orchestrateurs integres a un fournisseur cloud, distributions Kubernetes managees, distributions legeres pour labs ou edge, et installations plus traditionnelles via kubeadm ou outils equivalents.

Le choix depend du contexte: apprentissage, production, contraintes reseau, besoin multi-cloud, budget, niveau d’automatisation et capacite d’exploitation.

Liens utiles

• Video: https://www.youtube.com/watch?v=eRH_cetVAck
• Depot Xavki: https://gitlab.com/xavki/tutorials-kubernetes-v2
• Concepts Kubernetes: https://kubernetes.io/docs/concepts/
• CNCF Kubernetes: https://www.cncf.io/projects/kubernetes/
• Formation Enix Kubernetes: https://2026-05-enix.container.training/

FAQ

Kubernetes est-il reserve aux grandes entreprises ?

Non. Il peut etre utilise en lab, en formation ou en production. En revanche, sa complexite doit etre proportionnee au besoin.

Pourquoi Kubernetes est-il devenu un standard ?

Parce qu’il fournit une API commune, un ecosysteme tres large et un modele extensible autour des objets et controleurs.

Une solution managee est-elle preferable pour debuter ?

Pour apprendre les concepts, une distribution locale ou legere suffit. Pour la production, un service manage peut reduire la charge d’exploitation.

Pourquoi les conteneurs ne suffisent pas

Les conteneurs ont resolu une grande partie du probleme de packaging. On peut construire une image, la pousser dans un registre, puis la lancer de facon relativement reproductible. Mais un systeme de production demande plus que cela. Il faut savoir combien d’instances doivent tourner, comment repartir la charge, comment remplacer une instance malade, comment injecter la configuration, comment gerer les secrets, et comment faire evoluer une application sans interruption.

Kubernetes arrive precisement a cet endroit. Il ne remplace pas le conteneur: il organise son execution a l’echelle d’un cluster. C’est pour cela que l’histoire de Kubernetes est liee a l’histoire des architectures distribuees, des microservices et du cloud.

Les grandes etapes a retenir

On peut resumer l’evolution en quatre moments:

| Etape | Probleme dominant | Reponse typique |

|---|---|---|

| Serveurs physiques | isolation faible, deploiements lourds | separation par machines |

| Virtualisation | meilleure isolation, mais images lourdes | machines virtuelles |

| Conteneurs | packaging leger et rapide | images et runtimes de conteneurs |

| Orchestration | execution distribuee et fiable | Kubernetes et controleurs |

Cette lecture aide a comprendre pourquoi Kubernetes est parfois juge complexe: il traite des problemes qui apparaissent quand l’application n’est plus seulement un processus local.

Alternatives et complements

Kubernetes n’est pas la seule maniere d’executer des conteneurs. Pour une petite application, un service PaaS, Docker Compose, Nomad, une plateforme serverless ou un orchestrateur cloud specifique peuvent etre plus simples. Kubernetes devient interessant quand on a besoin d’un modele standard, extensible, portable, avec un ecosysteme riche.

Le bon reflexe n’est donc pas de dire: tout doit aller sur Kubernetes. Le bon reflexe est de comprendre ce que Kubernetes apporte, puis de choisir en connaissance de cause.

A retenir pour la suite de la serie

• Kubernetes est ne du besoin d’orchestrer des workloads conteneurises.
• Son API declarative est au centre de son fonctionnement.
• Son ecosysteme est un avantage, mais aussi une source de complexite.
• Les distributions et offres managees ne changent pas les concepts de base: Pod, Service, Deployment, API Server et controleurs restent essentiels.

Pour pratiquer apres cet episode

Une bonne pratique consiste a comparer trois facons de lancer une application simple:

docker run nginx
kubectl run nginx --image=nginx
kubectl create deployment nginx --image=nginx

Ces commandes ne produisent pas le meme modele operationnel. La premiere lance un conteneur local. La deuxieme cree un pod. La troisieme cree un controleur qui maintient des pods. Cette progression resume une partie de l’histoire racontee par Kubernetes.

Pourquoi Kubernetes s’est impose

Kubernetes a beneficie d’un alignement rare: un besoin reel, une API extensible, une communaute active et un ecosysteme ouvert. Il n’a pas seulement propose un orchestrateur; il a propose un langage commun pour decrire des workloads conteneurises.

Cette standardisation a beaucoup de valeur. Un developpeur, un administrateur systeme, une equipe plateforme et un outil CI/CD peuvent discuter autour des memes objets: Deployment, Service, ConfigMap, Secret, Ingress, Namespace. Meme si les implementations varient selon les clouds ou les distributions, les concepts restent largement transportables.

Les limites du standard

Le fait que Kubernetes soit un standard ne signifie pas que tous les clusters se valent. Le reseau, le stockage, l’observabilite, les ingress controllers, les policies, les certificats et les integrations cloud changent beaucoup d’un environnement a l’autre.

Il faut donc distinguer deux niveaux:

• les concepts Kubernetes, qui restent relativement stables;
• l’exploitation d’une plateforme Kubernetes, qui depend fortement du contexte.

Cette distinction evite une confusion frequente: savoir ecrire un manifest ne veut pas dire savoir operer un cluster de production. Les deux competences se completent, mais elles ne sont pas identiques.

Choisir une solution selon le besoin

Pour apprendre, une solution locale ou legere suffit souvent. Pour une equipe produit, une offre managee peut reduire la charge de maintenance. Pour une organisation avec fortes contraintes reseau ou souverainete, une installation plus controlee peut etre necessaire.

Le bon choix depend de criteres concrets:

• qui maintient le cluster ?
• quelle disponibilite est attendue ?
• quelles integrations reseau et stockage sont necessaires ?
• quelle strategie de sauvegarde est possible ?
• quelle expertise Kubernetes existe deja dans l’equipe ?

Kubernetes est donc autant un choix technique qu’un choix d’organisation.

Notions et definitions

• API Server: porte d’entree de toutes les operations Kubernetes.
• Objet declaratif: document qui decrit l’etat voulu plutot qu’une suite d’actions imperatives.
• Controleur: composant qui agit pour rapprocher le reel du desire.

Ces definitions donnent le vocabulaire minimal pour suivre l’article sans reduire Kubernetes a une simple commande. Chaque notion doit etre reliee a un objet visible avec kubectl ou a un composant du cluster.

Exemple concret

Un manifest Deployment ne dit pas comment creer chaque pod pas a pas; il declare le resultat attendu, et Kubernetes se charge de converger vers cet etat.

Cet exemple sert de fil conducteur: il montre quel probleme operationnel Kubernetes cherche a resoudre et quelle ressource permet de le formaliser.

How-to rapide

• Explorer le schema de l’objet avec kubectl explain.
• Creer l’objet declarativement avec kubectl apply -f.
• Observer status, conditions et events.
• Modifier le YAML puis reappliquer pour comprendre la reconciliation.

Le how-to est volontairement court: l’idee est d’obtenir un resultat observable, puis d’utiliser les commandes de verification pour comprendre ce qui s’est passe.

Approfondir cet article

Cet episode doit surtout permettre de maitriser le modele mental Kubernetes: API declarative, etat desire, controleurs et observation continue du cluster. L’objectif n’est pas seulement de refaire les commandes, mais de comprendre quel objet Kubernetes est cree, quel composant le prend en charge et comment verifier le resultat.

Questions a se poser

• Quel est l’etat desire exprime dans Kubernetes ?
• Quel composant observe cet etat et tente de le reconciler ?
• Quels symptomes montrent que l’objet est cree mais pas encore operationnel ?
• Quelle commande donne l’information la plus fiable pour diagnostiquer ?

Commandes de verification

• kubectl api-resources pour lister les objets disponibles
• kubectl explain <ressource> pour comprendre le schema d’un objet
• kubectl get events --sort-by=.lastTimestamp pour suivre ce que le cluster decide

Ces commandes ne sont pas a apprendre par coeur. Elles servent a construire un reflexe: partir de l’objet Kubernetes, lire son etat, puis descendre vers les pods, les events, les logs ou le noeud uniquement si c’est necessaire.

Points de vigilance

• voir Kubernetes comme une suite de commandes au lieu d’une API d’etat
• oublier la difference entre creer un objet et obtenir un workload fonctionnel
• ne pas regarder les events et les conditions avant de chercher trop loin

Exercice conseille

Prenez un objet simple, creez-le en imperatif, exportez son YAML, supprimez-le, puis recréez-le en declaratif pour comparer les deux approches.

Pour valider la comprehension, gardez une trace courte: manifest utilise, commandes lancees, resultat attendu, resultat observe et correction appliquee. Cette methode rend les episodes suivants beaucoup plus faciles a enchainer.

Lien interne conseille

Pour poursuivre la progression, consultez aussi Kubernetes 002 – Architecture : declaratif vs imperatif.

Conclusion

Comprendre l’histoire de Kubernetes aide a eviter deux erreurs: le voir comme une simple mode, ou le voir comme une solution magique. C’est une reponse structuree a des problemes reels d’orchestration, mais qui demande un apprentissage progressif.