Kubernetes, c'est quoi ? Le guide d'une équipe qui l'exploite en production

La plupart des articles qui expliquent Kubernetes s'arrêtent au même endroit : la définition, l'architecture, quelques commandes kubectl, une liste d'avantages. C'est utile, et c'est incomplet, parce que les deux questions qu'on nous pose réellement en réunion client sont ailleurs : combien ça coûte, et est-ce qu'on en a vraiment besoin.

Nous faisons tourner Kubernetes en production : une flotte de microservices Go sur GKE, avec Traefik et Cloud SQL. Nous avons aussi sorti certaines charges de Kubernetes parce que c'était le mauvais outil pour elles, et nous avons les chiffres. Cet article couvre les bases, puis les deux parties que presque personne n'écrit.

Sommaire

• Kubernetes, c'est quoi ?
• Quel est le rôle de Kubernetes ?
• Quelle est la différence entre Kubernetes et Docker ?
• À quoi sert exactement Kubernetes ?
• Combien coûte un cluster Kubernetes ?
• Quand Kubernetes est le mauvais choix
• Par où commencer concrètement

---

Kubernetes, c'est quoi ?

Kubernetes est un orchestrateur de conteneurs. Vous lui décrivez l'état souhaité de votre application : quelle image, combien d'exemplaires, quelles limites de mémoire et de CPU, comment on y accède depuis l'extérieur. Il se charge ensuite de maintenir cet état en permanence.

C'est ce dernier point qui fait la différence avec un simple script de déploiement. Kubernetes ne déploie pas puis s'arrête : il compare en boucle l'état réel à l'état déclaré, et corrige l'écart. Un conteneur qui plante est redémarré. Une machine qui disparaît voit ses conteneurs replacés ailleurs. Une nouvelle version se substitue à l'ancienne un exemplaire à la fois.

On résume souvent cela par le mot « déclaratif », qui est exact mais abstrait. La formulation concrète est plus utile : vous décrivez le résultat, pas les étapes, et vous acceptez que le système prenne les décisions de placement à votre place.

Quel est le rôle de Kubernetes ?

Son rôle est de rendre un parc de machines interchangeable. Sans orchestrateur, un service vit sur un serveur précis, et ce serveur devient précieux : on sait laquelle des machines fait tourner quoi, on la sauvegarde, on évite d'y toucher. Avec un orchestrateur, les machines deviennent un stock de capacité, et savoir laquelle héberge quoi cesse d'être une information intéressante.

Concrètement, il prend en charge quatre choses que vous devriez sinon écrire vous-même :

• Le placement. Choisir quelle machine a assez de ressources libres pour accueillir un conteneur.
• La guérison. Redémarrer ce qui tombe, remplacer ce qui ne répond plus aux sondes de santé.
• Le réseau interne. Donner un nom stable à un service dont les exemplaires apparaissent et disparaissent.
• Le déploiement progressif. Remplacer une version par une autre sans interruption, et revenir en arrière si la nouvelle échoue.

Ce sont des problèmes réels. La question n'est pas s'ils existent, mais si vous en avez assez pour justifier d'exploiter un cluster.

Quelle est la différence entre Kubernetes et Docker ?

C'est la confusion la plus fréquente, et elle vient du fait que les deux mots apparaissent toujours ensemble. Ils ne sont pas concurrents, ils sont empilés.

Docker construit et exécute un conteneur sur une machine. Vous écrivez un Dockerfile, vous obtenez une image, vous la lancez.

Kubernetes décide où ce conteneur tourne, en combien d'exemplaires, et ce qui se passe quand la machine meurt. Il ne construit pas d'image et n'en exécute pas directement.

Une précision technique que beaucoup d'articles ont ratée : Kubernetes n'utilise plus le moteur Docker en interne depuis la version 1.24. Il s'appuie sur containerd via une interface standard. Cela ne change rien pour vous : les images construites avec Docker fonctionnent toujours, parce que le format d'image est standardisé. Mais « Kubernetes utilise Docker » est devenu faux, et c'est le genre de détail qui trahit un article recopié.

La bonne image mentale : Docker est l'unité de transport, Kubernetes est le port qui décide où chaque conteneur est déchargé.

À quoi sert exactement Kubernetes ?

Les usages où il se justifie ont un point commun : plusieurs services, et une charge assez continue pour que les machines soient allumées de toute façon.

Chez nous, cela correspond à une flotte de microservices Go qui se parlent en gRPC, exposés par Traefik, avec PostgreSQL managé derrière. Il y a des dizaines de services, ils sont déployés plusieurs fois par semaine, chacun a ses secrets et ses limites de ressources, et le trafic ne descend jamais à zéro. C'est le cas nominal.

Cela sert aussi à des choses moins évoquées et très utiles au quotidien : standardiser la façon dont un service déclare ses secrets, ses sondes de santé et ses ressources, pour que le dixième service se déploie comme le premier. Une bonne partie de la valeur de Kubernetes n'est pas technique, elle est organisationnelle : il impose une forme commune.

Combien coûte un cluster Kubernetes ?

Presque aucun article ne répond à cette question, alors qu'elle arrive systématiquement. Voici la structure réelle du coût.

Le plan de contrôle (la partie managée par le fournisseur) coûte peu : de l'ordre de quelques dizaines d'euros par mois par cluster chez les principaux fournisseurs, parfois offert sur un premier cluster. Ce n'est jamais la ligne qui fait mal.

Les machines coûtent, et les machines inutilisées coûtent autant que les autres. C'est là que se joue la facture, et c'est indépendant de Kubernetes : un nœud allumé est facturé qu'il travaille ou non. Kubernetes n'aggrave pas ce problème, mais il le rend facile à ignorer, parce qu'il masque justement les machines derrière une abstraction.

Deux chiffres mesurés chez nous, sur des charges réelles :

Le service de diarisation a donc coûté vingt-cinq fois moins cher hors de Kubernetes. Non pas parce que Kubernetes est cher, mais parce que ces deux charges étaient irrégulières : du trafic aux heures de bureau, quasi rien la nuit. Nous payions une capacité permanente pour un besoin intermittent.

La bonne question de coût n'est donc pas « combien coûte Kubernetes » mais « quel est mon taux d'utilisation ». Si vos machines sont occupées, Kubernetes est un excellent moyen de les remplir. Si elles attendent, vous payez du vide avec une couche d'abstraction par-dessus.

Quand Kubernetes est le mauvais choix

Nous avons déplacé nos deux services de calcul de GKE vers Cloud Run, et nous le referions. Les cas où Kubernetes est le mauvais outil, d'après cette expérience :

Une charge en pointes, avec des périodes creuses. C'était notre cas. Un modèle qui travaille deux heures par jour n'a pas besoin d'un nœud allumé vingt-quatre heures. Le serverless descend à zéro exemplaire, et vous payez à l'usage. Le prix à accepter est le démarrage à froid : environ 30 secondes pour notre service GPU, environ 10 secondes pour le service CPU. Pour du traitement asynchrone de messages vocaux, c'est indolore. Pour une API interactive, ce serait inacceptable.

Un seul service, un trafic modeste. Exploiter un cluster pour une application unique, c'est ajouter un métier (l'exploitation du cluster) pour résoudre un problème que vous n'avez pas encore. Une plateforme managée fait la même chose sans ce métier.

Pas d'équipe pour l'exploiter. Kubernetes déplace la complexité, il ne la supprime pas. Les sondes de santé mal réglées, les limites de mémoire trop basses, les quotas de la région : ce sont des problèmes qu'il faut savoir diagnostiquer. Nous avons perdu du temps sur exactement ces trois-là. Si personne dans l'équipe ne veut de ce sujet, le cluster deviendra une dette.

Une contrainte de région forte. Ce n'est pas propre à Kubernetes, mais la disponibilité matérielle décide parfois de l'architecture avant vous. Les GPU L4 n'étaient pas disponibles dans la région Paris pour le service que nous voulions y mettre, ce qui nous a obligés à déployer en Belgique et à relier les deux réseaux. Vérifiez la disponibilité avant de concevoir, pas après.

Rien de tout cela ne dit que Kubernetes est un mauvais outil. Notre plateforme principale tourne dessus. Cela dit qu'il résout un problème précis, et qu'il faut avoir ce problème.

Par où commencer concrètement

Si vous voulez apprendre pour de vrai plutôt que suivre un tutoriel de cinq minutes, nous avons publié notre formation complète en accès libre : 22 heures, onze séances, sous licence CC BY-NC.

Elle est faite pour un développeur backend compétent qui veut devenir autonome en un week-end, ce qui est exactement le trou entre la démonstration kubectl run et la certification de quarante heures. Tout tourne sur un cluster local, donc aucune facture cloud pour commencer. Les séances avancées vont jusqu'à Terraform pour provisionner un vrai cluster GKE, la gestion des secrets via un gestionnaire externe, et la mise en production avec sondes, limites et montée en charge automatique.

Vous pouvez la forker, la faire tourner, et enseigner avec.

Pour le contexte d'architecture autour de tout cela, voir notre infrastructure IA européenne, le détail chiffré du passage au serverless dans inférence GPU à la demande en Europe, et la charge de travail qui justifie le plus un cluster que vous maîtrisez : les comptes rendus de réunion auto-hébergés pour les réunions confidentielles.