Kubernetes : quand une PME n'en a pas besoin

Kubernetes est partout : dans les offres d’emploi, dans les propositions d’architecture, dans les plateformes des grands fournisseurs de cloud. Il est devenu la norme des systèmes qui font tourner des centaines de services, et c’est mérité. Pour une entreprise de 20 à 500 personnes qui fait tourner une poignée d’outils, la question n’est pas de savoir si Kubernetes est un bon outil, il l’est, mais s’il résout un problème qu’elle a.

Cet article de notre rubrique Infrastructure et cloud explique ce que Kubernetes apporte, ce qu’il coûte à entretenir, et les signes qui disent qu’on peut s’en passer, pour l’instant ou durablement.

Ce que fait Kubernetes, en une phrase

La documentation de Kubernetes le présente comme une plateforme open source, portable et extensible, qui gère des charges de travail en conteneurs. Concrètement, vous lui décrivez l’état voulu (tel service, en trois exemplaires, avec telle mémoire) et il s’emploie en continu à atteindre cet état sur un ensemble de machines : il relance ce qui tombe, répartit la charge, déploie les nouvelles versions progressivement.

Le premier chiffre dit que Kubernetes est devenu la norme chez ceux qui utilisent déjà des conteneurs à grande échelle. Les deux suivants rappellent qu’il ne s’adopte pas comme un logiciel qu’on installe : il change la façon dont une équipe travaille.

Ce que Kubernetes ne fait pas

C’est la partie la moins connue, et la documentation officielle est très claire. Dans sa section « ce que Kubernetes n’est pas », elle précise qu’il :

• ne fournit pas de services applicatifs intégrés, comme une base de données, un cache ou un système de stockage partagé ;
• n’impose et ne fournit pas de solution de journalisation, de surveillance ou d’alerte, au-delà de mécanismes pour collecter et exporter des métriques ;
• ne construit pas votre application et ne déploie pas votre code source ;
• ne fournit pas de système complet de configuration, de maintenance ou de gestion des machines.

Autrement dit, adopter Kubernetes ne règle ni les sauvegardes, ni la surveillance, ni la base de données : ces chantiers restent entiers, et il faut en plus les faire tenir dans Kubernetes. Pour une petite équipe, c’est le point qui compte : on ajoute une couche à exploiter, on n’en retire aucune.

Ce qu’il coûte à entretenir

Kubernetes évolue vite. La page des versions du projet indique que seules les trois dernières versions mineures sont maintenues, et que chacune reçoit environ un an de correctifs. Un cluster doit donc être mis à jour au moins une fois par an, en vérifiant à chaque fois que tout ce qui tourne dessus suit.

Chez un fournisseur, ce rythme a un prix explicite. Chez AWS, par exemple, un cluster géré coûte 0,10 dollar de l’heure en support standard, et 0,60 dollar en support étendu, quand sa version a dépassé la période standard. Les autres fournisseurs ont leurs propres grilles ; le principe reste le même : la maintenance en retard se paie. Ce coût s’ajoute aux machines elles-mêmes, et nous l’avons rangé parmi les cinq postes qui gonflent une facture cloud.

Le coût principal reste humain : il faut quelqu’un qui comprend le fonctionnement du cluster, ses réseaux, ses droits et ses mises à jour, et qui est joignable quand il se comporte mal. Kubernetes ne supprime pas le travail des administrateurs système : il le déplace vers des compétences plus spécialisées.

Les signes qu’on n’en a pas besoin

Le seuil d’une vingtaine de services n’est pas une norme : c’est un ordre de grandeur, à confronter à votre propre situation. Le critère le plus fiable reste le dernier de chaque colonne : la compétence disponible pour l’exploiter.

Ce qui suffit à la place

Pour la plupart des entreprises de taille moyenne, un montage plus simple couvre le besoin :

• des conteneurs décrits dans un fichier, avec Docker Compose, que sa documentation présente comme un outil pour définir et faire tourner des applications à plusieurs conteneurs ; la description des services vit dans un dépôt versionné et se rejoue sur une autre machine ;
• un routeur devant les services, qui gère les adresses et les certificats ;
• des sauvegardes hors du serveur, restaurées pour de vrai, et une liste écrite des services et de leurs volumes ;
• une surveillance extérieure, qui prévient quand un service ne répond plus ;
• un plan de reprise écrit, avec le temps réel de restauration mesuré.

La limite de ce montage est connue : un serveur unique est un point de défaillance unique. Si votre activité ne supporte pas l’arrêt le temps d’une restauration, la première marche n’est pas forcément Kubernetes : un second serveur prêt à prendre le relais, ou des services gérés chez un fournisseur, répondent souvent au besoin avec moins de complexité. Les arbitrages entre serveur et cloud sont détaillés dans serveur dédié, VPS ou cloud : choisir selon l’usage.

Si vous y allez quand même

Il y a de bonnes raisons d’y aller : une équipe qui le maîtrise déjà, une application qui doit monter en charge, un éditeur qui ne livre son logiciel que sous cette forme. Dans ce cas, trois précautions :

1. Préférer un service géré si personne chez vous n’exploite de cluster : le fournisseur prend en charge la partie la plus délicate.
2. Planifier les mises à jour dès le départ, au moins une par an, avec un environnement d’essai.
3. Garder hors du cluster ce qui n’a pas besoin d’y être, une base de données gérée par exemple, plutôt que de tout y faire entrer.

Le cluster vient alors s’ajouter au socle d’infrastructure commun à vos projets : mêmes règles d’accès, de sauvegarde et de budget.

Par où commencer

Comptez vos services, et pour chacun, notez qui l’exploite et quelle interruption est acceptable. Si la liste est courte et que quelques minutes d’arrêt ne mettent pas l’activité en danger, commencez par des conteneurs bien décrits, des sauvegardes qui se restaurent vraiment, une supervision qui prévient avant les clients et un plan de reprise après sinistre écrit. Un exemple concret de ce montage est dans n8n auto-hébergé en production.

Les autres articles de la rubrique traitent des étapes voisines : les outils à sortir du SaaS en premier, le vrai coût d’une sortie du SaaS sur trois ans, la migration cloud sans tout casser, la dépendance de l’Europe au cloud américain et ce que NIS2 demandera aux entreprises françaises.

Si vous voulez ce montage pour vos outils de gestion, notre sortie du SaaS l’installe sur un serveur à vous, jusqu’à cinq services, sauvegardes testées et documentation comprises. Si une équipe vous propose Kubernetes et que vous voulez un second avis, décrivez-nous le projet.

Questions fréquentes

Sources

1. Kubernetes, Overview (nouvel onglet)kubernetes.io
2. Kubernetes, Releases (nouvel onglet)kubernetes.io
3. AWS, tarifs d’Amazon EKS (nouvel onglet)aws.amazon.com
4. Docker, Docker Compose (nouvel onglet)docs.docker.com