Kubernetes a une réputation à deux vitesses : indispensable pour les uns, surdimensionné pour les autres. Les deux ont raison, selon où vous en êtes. La question n'est pas si Kubernetes est un bon outil, il l'est. La question est si votre produit, à son stade actuel, a besoin de ce que cet outil résout, et si quelqu'un dans votre équipe peut l'exploiter dans la durée.
Cette page répond à cette question avec les critères que nous utilisons réellement en mission, pas avec un argumentaire commercial en faveur de Kubernetes. Une partie non négligeable de nos audits conclut qu'il est encore trop tôt, et nous le disons.
Qu'est-ce que Kubernetes résout vraiment ?
Kubernetes orchestre des conteneurs : il les démarre, les redémarre s'ils tombent, répartit la charge entre eux et les déplace d'une machine à l'autre selon les ressources disponibles. C'est un outil d'exploitation, pas un outil de développement.
Il devient utile quand vous avez plusieurs services qui doivent tourner en continu, à l'échelle, avec des déploiements fréquents et une tolérance aux pannes matérielles. En dessous de ce seuil, il ajoute de la complexité sans ajouter de valeur.
Concrètement, Kubernetes prend en charge trois choses que vous feriez sinon à la main ou avec des scripts maison : redémarrer un service qui plante, répartir les nouvelles instances sur les machines qui ont de la place, et basculer le trafic vers les instances saines pendant qu'une mise à jour se déroule ailleurs. Ce sont des problèmes réels, mais qui n'apparaissent qu'à partir d'un certain nombre de services en production.
Les signes qu'il est temps d'y passer
Plusieurs signaux, pris ensemble, indiquent que Kubernetes a du sens pour vous :
- Vous recherchez de la haute disponibilité.
- Vous exploitez déjà plusieurs services qui communiquent entre eux, et leur nombre augmente.
- Votre charge varie fortement selon l'heure ou la saison, et vous devez absorber les pics sans surprovisionner en permanence.
- Un client exige un déploiement chez lui, sur ses propres serveurs, sans que vous ayez un accès direct à la machine.
- Votre équipe a déjà de l'expérience Kubernetes, en interne ou via un prestataire, et peut l'exploiter au quotidien.
- Vous migrez vers un cloud qualifié SecNumCloud et le fournisseur cible s'appuie lui-même sur Kubernetes.
Si deux ou trois de ces signaux sont déjà vrais chez vous, l'audit a plus de chances de conclure que c'est le bon moment.
Les signes qu'il est encore trop tôt
À l'inverse, plusieurs situations indiquent qu'un service managé de conteneurs reste l'option la plus adaptée, pour l'instant :
- Une seule application, ou deux, sans besoin réel de répartir la charge entre plusieurs machines.
- Une équipe de développeurs qui gère l'infrastructure "à côté", sans personne dédié à l'exploitation.
- Un stade de vie où chaque semaine compte pour le produit, pas pour l'infrastructure.
Dans ce cas, AWS ECS / Fargate, Google Cloud Run ou Scaleway Serverless Containers font le travail avec beaucoup moins de surface à maintenir. Vous pourrez toujours migrer vers Kubernetes plus tard, une fois le besoin réel installé.
Ce que coûte un cluster mal maintenu
Un cluster Kubernetes n'est pas un risque en soi. Un cluster sans personne pour le maintenir, si. Les mises à jour de version, les correctifs de sécurité, le suivi des coûts et l'observabilité (savoir ce qui se passe réellement dans le cluster) demandent un temps régulier.
Sans ce temps, deux choses arrivent : les versions prennent du retard jusqu'à devenir risquées à mettre à jour, et les coûts dérivent sans que personne ne s'en aperçoive à temps. C'est la situation la plus fréquente que nous rencontrons sur une reprise de cluster : pas un cluster cassé, un cluster abandonné.
Dans ce cas, nous ne repartons jamais de zéro. Nous commençons par un audit du cluster existant : versions en place, charge réelle par rapport aux ressources réservées, failles de sécurité connues, coûts par service. Ce diagnostic détermine l'ordre des corrections, pour fiabiliser le cluster sans interrompre ce qui tourne déjà en production.
Comment nous tranchons la question avec vous
Nous commençons par un audit : combien de services, quelle charge réelle, quelle compétence disponible dans l'équipe, quelles contraintes client. À l'issue de cet audit, nous vous disons honnêtement si Kubernetes a du sens maintenant, plus tard, ou pas du tout pour votre cas.
Si la réponse est oui, nous mettons en place un cluster managé (EKS, GKE, AKS, Kapsule, OVHcloud MKS, S3NS selon votre cloud cible) ou k3s pour l'on-premise et l'edge, avec le cluster décrit en Infrastructure as Code (Terraform, Helm) dans vos propres dépôts Git, un déploiement GitOps avec ArgoCD, et un tableau de bord de supervision.
Si la réponse est "pas encore", nous vous orientons vers un service managé de conteneurs, et nous documentons les conditions qui justifieraient de revenir sur la question plus tard.
GitOps et Infrastructure as Code : ce que cela change concrètement
Un cluster Kubernetes mis en place sans méthode devient vite un cluster que plus personne ne comprend. Nous décrivons chaque cluster en Infrastructure as Code : la configuration vit dans des fichiers Terraform et Helm versionnés, pas dans des commandes tapées une à une sur un terminal au moment où le besoin se présente.
Le déploiement suit une logique GitOps avec ArgoCD : l'état voulu du cluster est décrit dans un dépôt Git, et un contrôleur applique en continu ce qui est écrit dans ce dépôt. Concrètement, un changement de configuration passe par une revue de code comme n'importe quel changement de logiciel, et un retour arrière se fait en revenant à un commit précédent, pas en se souvenant de ce qui a été tapé la dernière fois.
Cette méthode a un coût d'installation, et c'est pour cela qu'elle ne se justifie pas sur un cluster d'une seule application. Elle se rentabilise à partir du moment où plusieurs services évoluent en parallèle et où une erreur de configuration manuelle finirait par coûter plus cher que la rigueur qui l'évite.
À cela s'ajoute la supervision : des tableaux de bord Grafana construits sur Prometheus pour les métriques et Loki pour les journaux, pour savoir ce qui se passe réellement dans le cluster avant qu'un client ne vous le signale.
Retour d'expérience
Chez Webmecanik, j'ai géré pendant deux ans 8 clusters Kubernetes en production, 70 nœuds et plus de 4 000 pods, en GitOps avec ArgoCD. Ce volume n'est pas la norme pour une startup : il montre surtout qu'un cluster bien tenu se gère à l'échelle sans drame, à condition d'avoir le temps et la méthode pour le faire.
À l'inverse, chez TKM, le sujet n'était pas Kubernetes mais un cluster Solr de 7 To et plus de 400 millions de documents, sans personne dédié à l'infrastructure. Le réimport complet n'était pas envisageable en l'état : plusieurs mois, de l'ordre de 6 mois avec tout le process d'analyse. Après reprise et optimisation de l'infrastructure, il prend environ 5 heures.
Les deux situations se ressemblent plus qu'il n'y paraît : ce qui coûte cher n'est jamais la technologie choisie, c'est l'absence de quelqu'un pour l'exploiter dans la durée. C'est exactement la question que nous posons avant de vous recommander Kubernetes : qui va le faire tourner, et à partir de quand.
« Kubernetes vaut le coup si vous avez la compétence en interne ou si vous êtes prêts à la payer à l'extérieur. Sans expérience, c'est compliqué. Et pour une startup qui démarre, c'est souvent trop tôt : un service managé de conteneurs fera très bien l'affaire. » (Alexis Thomé)