Kubernetes n’est pas réservé aux géants du cloud

Docker seul, Docker Compose, puis Kubernetes : à quel moment le changement vaut le coup pour un petit projet, et à quel moment il ne le vaut pas.

Une phrase que j’entends souvent

Kubernetes, c’est pour Google. Nous, on a trois services et un serveur.

C’est souvent vrai.

Et pourtant, j’exploite aujourd’hui des projets de petite taille sur Kubernetes, et je ne reviendrais pas en arrière.

La contradiction n’est qu’apparente. La bonne question n’est pas la taille du projet. C’est ce qu’on attend de son infrastructure.

Étape 1 : Docker seul

Tout commence généralement par un conteneur lancé à la main sur un serveur.

C’est simple, lisible, et largement suffisant pour :

un site vitrine
un outil interne
un prototype qu’on veut montrer vite

Le problème arrive le jour où il faut se souvenir de la commande exacte qui a servi à lancer le conteneur. Ou le jour où le serveur redémarre.

Étape 2 : Docker Compose

Docker Compose règle ce premier problème : l’infrastructure est décrite dans un fichier, versionné avec le code.

Pour beaucoup de projets, il faut s’arrêter là.

Compose convient très bien tant que :

tout tient sur une seule machine
une coupure de quelques minutes lors d’une mise à jour est acceptable
une seule personne déploie

Je continue de le recommander. Un projet qui tourne proprement sous Compose est en meilleur état qu’un cluster Kubernetes que personne ne comprend.

Les signaux qui annoncent la limite

Dans mon expérience, ce n’est jamais le trafic qui pousse à changer. Ce sont des signaux plus discrets :

on déploie en se connectant en SSH, et on croise les doigts
un deuxième serveur apparaît, puis un troisième
les certificats, les secrets et les sauvegardes sont gérés par des scripts différents sur chaque machine
la mise à jour d’un service impose de prévenir les utilisateurs
personne ne sait dire avec certitude ce qui tourne en production

Quand trois de ces signaux sont réunis, on a déjà commencé à réécrire un orchestrateur. En moins bien.

Ce qui m’a fait franchir le pas

Sur Metalearn, deux besoins ont rendu la question concrète.

La visioconférence. La plateforme propose un système de visio, qui a besoin d’un ou plusieurs serveurs coturn pour fonctionner correctement. Il fallait pouvoir en mettre de nouveaux en service rapidement, et toujours de la même façon.

Un client, un tenant. Chaque client de Metalearn dispose de son propre environnement : les briques qui composent la plateforme sont déployées séparément pour chacun d’eux. Le même déploiement doit donc être rejoué autant de fois qu’il y a de clients.

Déployer une fois à la main reste gérable. Déployer la même chose dix fois, à l’identique, ne l’est plus. Il fallait une méthode unique.

Ce que Kubernetes apporte vraiment à un petit projet

Pas la mise à l’échelle automatique. Un petit projet n’en a presque jamais besoin.

Ce que j’y gagne concrètement :

un état déclaré : ce qui est dans le dépôt Git est ce qui tourne, et inversement
des déploiements sans coupure, avec retour arrière en une commande
une seule manière de faire pour les certificats, les secrets, l’exposition réseau et les sauvegardes
la reproductibilité : remonter un environnement complet devient une opération banale

Avec une approche GitOps, un déploiement se résume à une fusion de branche. Il n’y a plus de connexion manuelle au serveur.

Mon cluster, concrètement

Le cluster tourne chez Scaleway, sur cinq serveurs dédiés de la gamme Elastic Metal :

trois machines pour le plan de contrôle
deux machines pour les nœuds de travail

Ces serveurs sont installés et configurés avec Ansible. Ajouter un nœud revient à modifier un fichier, puis à relancer le déploiement.

Ce que ça coûte

Il serait malhonnête de s’arrêter aux avantages.

Kubernetes coûte :

du temps d’apprentissage, et pas seulement pour celui qui l’installe
des ressources : le plan de contrôle consomme avant même le premier service
de la surface de panne : réseau, stockage, mises à jour du cluster lui-même
de la discipline : sans supervision ni sauvegardes testées, on a juste déplacé le problème

Mon propre cluster en donne la mesure : sur cinq machines, trois servent uniquement à faire tenir le cluster debout. C’est le prix de la haute disponibilité, et il se paie avant d’avoir déployé le moindre service.

Le stockage reste, à mes yeux, la partie la plus délicate : un volume qui refuse de se rattacher à un nouveau nœud bloque un service sans prévenir.

Ma grille de décision

Rester sur Docker Compose si :

une seule machine suffit
une coupure courte est acceptable
personne dans l’équipe n’a le temps d’apprendre Kubernetes

Passer à Kubernetes si :

plusieurs services doivent être déployés indépendamment
le même déploiement doit être répété pour plusieurs clients
plusieurs environnements doivent se ressembler exactement
la disponibilité devient un engagement
quelqu’un est en mesure de l’exploiter dans la durée.

Ce dernier point est le plus important. Un cluster n’est pas un projet qu’on livre. C’est un système qu’on exploite.

Conclusion

Kubernetes n’est ni un objectif ni un signe de maturité.

C’est un outil qui remplace une collection de scripts fragiles par un modèle cohérent. Il devient rentable quand cette collection existe déjà, pas avant.

La bonne question n’est donc pas :

« Sommes-nous assez gros pour Kubernetes ? »

Mais plutôt :

« Combien de temps passons-nous déjà à bricoler ce qu’il fait nativement ? »