Tous les quelques mois, une équipe de trois à cinq ingénieurs nous demande si elle devrait passer à Kubernetes. L'application, c'est un front-end web, une API, deux ou trois workers et une base de données. Elle tourne sur un ou deux serveurs, ou sur une plateforme-en-tant-que-service qui devient chère. Quelqu'un a lu que Kubernetes, c'est ce que font les vraies entreprises, et ils aimeraient être une vraie entreprise.
La réponse que nous donnons, presque à chaque fois, c'est non. Pas « pas encore ». Non. Et comme cette réponse sonne comme de la paresse ou de l'esprit de contradiction, cet article est le raisonnement derrière, l'alternative que nous construirions à la place, ce qu'elle coûte, et les conditions précises dans lesquelles la réponse change.
À quoi sert Kubernetes
Kubernetes résout l'ordonnancement : étant donné une flotte de machines et un ensemble de charges avec des besoins en ressources, placer les charges sur les machines, les maintenir en marche, les remplacer quand elles meurent, et les exposer les unes aux autres et au monde. Il résout ça extrêmement bien, à toute échelle, pour tout type de charge, avec un écosystème pour tout ce qu'on pourrait vouloir.
Remarquez ce que l'énoncé du problème exige : une flotte de machines. Si vous n'avez pas de flotte, vous n'avez pas le problème d'ordonnancement, et Kubernetes devient une réponse très sophistiquée à une question que vous n'avez pas posée. Une équipe avec trois services n'a pas besoin de bin-packing. Elle a besoin que ses conteneurs tournent, redémarrent, passent de deux à six quand il y a du trafic, et obtiennent une URL HTTPS.
Ce que vous obtenez quand même avec un cluster managé
« Kubernetes managé » (EKS, GKE, AKS) gère le plan de contrôle. Il ne gère pas le reste, et le reste est là où va le temps. Pour un cluster de production, vous posséderez :
- Les groupes de nœuds, leurs types d'instances, leurs mises à jour d'AMI, leur autoscaling.
- Le réseau : un CNI, un contrôleur d'ingress, un équilibreur par ingress ou un partagé, cert-manager pour le TLS, external-dns pour les enregistrements.
- L'observabilité : metrics-server, un agent de logs, et tout ce dont vous auriez eu besoin de toute façon.
- La sécurité : pod security standards, network policies, IRSA ou workload identity pour l'accès AWS, l'analyse d'images, un admission controller si vous êtes sérieux.
- Les mises à jour : Kubernetes sort trois fois par an et les fournisseurs managés cessent de supporter les anciennes versions environ un an après leur sortie. Chaque mise à jour touche l'API server, les nœuds et, parfois, les manifestes, parce que quelque chose a été déprécié.
- L'outillage de déploiement : Helm ou Kustomize, une stratégie d'environnements, et probablement ArgoCD ou Flux une fois que « kubectl apply depuis un portable » vous a mordu une fois.
Rien de tout ça n'est difficile pour ceux qui l'ont déjà fait. Tout ça est une taxe permanente pour une équipe qui ne l'a pas fait, et pour une équipe de trois, c'est une personne. Nous l'avons vu se produire : l'ingénieur le plus fort devient l'ingénieur du cluster, la vélocité produit est divisée par deux, et dix-huit mois plus tard ils ont une belle plateforme sous un produit qui a cessé de grandir.
Ce que nous construisons à la place
Un bon Dockerfile, et un runtime managé qui prend une image et rend une URL. Sur AWS, c'est App Runner pour le cas simple et ECS Fargate quand vous avez besoin d'un service interne au VPC ou de plus de contrôle ; les équivalents sur les autres clouds sont Cloud Run et Container Apps, et l'argument est identique.
Le Dockerfile est là où va l'effort d'ingénierie, et c'est un effort qui aurait été dépensé pour Kubernetes aussi : build multi-étapes, un utilisateur non root, une image de base épinglée, un HEALTHCHECK, pas de secrets intégrés, une image de moins de 200 Mo pour que les démarrages à froid soient rapides. Nous avons écrit sur la version Node de ceci. Faites-le bien une fois et c'est le même fichier sur n'importe quel runtime, y compris Kubernetes si vous migrez un jour.
Le runtime fait ce que le cluster aurait fait : tire l'image, en fait tourner N copies, vérifie leur santé, remplace les mortes, ajuste entre min et max, termine le TLS, route le trafic. Il le fait avec une définition de service d'environ vingt lignes de CDK, et il le fait sans OS de nœud à patcher.
Le reste de la pile ne change pas. Aurora ou DynamoDB pour les données, SQS pour les files, Lambda pour les choses vraiment événementielles, le collecteur OpenTelemetry pour l'observabilité. Rien dans cette liste n'a jamais eu besoin d'un cluster.
Le coût, honnêtement
La défense habituelle de Kubernetes sur le coût, c'est que Fargate et App Runner facturent une prime par vCPU-heure par rapport à EC2 brut. C'est vrai. Voici ce que cette prime achète à l'échelle en question, pour trois services avec deux instances chaudes chacun en production :
| Kubernetes managé (EKS) | Conteneurs sur App Runner / Fargate | |
|---|---|---|
| Plan de contrôle | 73 $ / mois | 0 $ |
| Nœuds / calcul | 3 × m6i.large ≈ 210 $, surtout inactifs pour la marge | 6 × 1 vCPU / 2 Go ≈ 250 $ aux tarifs App Runner |
| Équilibreur | 1 ALB ≈ 25 $ + LCU | inclus (App Runner) ou le même ALB (Fargate) |
| Add-ons qui consomment de la capacité de nœud | ingress, cert-manager, DNS, métriques, logs ≈ l'équivalent d'un nœud | aucun |
| Mises à jour et correctifs | 3 mises à jour de cluster / an, rotation d'AMI mensuelle | monter le tag de l'image de base |
| Temps d'ingénierie | ≈ 0,5–1 ETP | ≈ 0,05 ETP |
| Mensuel, tout compris | ~310 $ + 5 000–10 000 $ d'ingénieur | ~275 $ + ~500 $ d'ingénieur |
Les lignes d'infrastructure sont à 50 $ l'une de l'autre. La ligne d'ingénierie est toute la comparaison. À trois services, Kubernetes n'est pas plus cher à faire tourner ; il est plus cher à posséder, d'un ordre de grandeur, et la prime par vCPU-heure est du bruit face à ça.
Quand la réponse change
Nous ne sommes pas contre Kubernetes. Nous l'exploitons, pour les clients qui en ont besoin. La réponse bascule quand l'une de ces conditions est vraie, et il en faut généralement deux :
- Beaucoup de services, beaucoup d'équipes. Au-delà d'environ quinze à vingt services avec plusieurs équipes qui déploient indépendamment, la configuration par service des runtimes managés devient sa propre prolifération, et un cluster avec des namespaces, des quotas et un contrôleur GitOps est vraiment plus simple.
- Des charges qui ne rentrent pas dans la forme du runtime. Des requêtes plus longues que le délai du runtime, des GPU, des stateful sets, des démons qui ont besoin d'accéder à l'hôte, du réseau personnalisé. La limite de 120 secondes d'App Runner est réelle ; si votre charge a besoin de 20 minutes de websocket, vous l'avez dépassé.
- Du calcul stable et important. À des centaines de vCPU en continu, la prime par vCPU n'est plus du bruit et les nœuds réservés dans un cluster sont nettement moins chers. C'est le point de croisement des coûts, et il est bien plus haut que les gens ne le supposent.
- La portabilité comme exigence. Si un contrat dit « doit être déployable dans le cluster du client », le runtime est Kubernetes parce que celui du client l'est. C'est la situation de notre plateforme d'agents, et c'est pourquoi elle est livrée en charts Helm et pourquoi nous connaissons la taxe de première main.
- Vous avez déjà la personne. Si quelqu'un dans l'équipe a exploité des clusters de production et veut continuer, le coût de possession baisse et le calcul change. Assurez-vous qu'il le veut, et de ce qui se passe quand il part.
L'objection : « mais il faudra migrer plus tard »
Peut-être. Voici ce qu'implique réellement une migration ultérieure d'un runtime managé vers Kubernetes, pour une équipe qui a construit comme décrit : les Dockerfiles sont inchangés ; les routes de santé sont inchangées ; les variables d'environnement et les références aux secrets deviennent un ConfigMap et un ExternalSecret ; les vingt lignes de CDK par service deviennent quarante lignes de values Helm. L'agent d'observabilité passe d'un sidecar à un DaemonSet avec la même configuration. C'est un projet de deux semaines pour quelqu'un qui l'a déjà fait, et le jour où vous en aurez besoin, vous aurez la personne, parce qu'en avoir besoin est ce qui justifie de l'embaucher.
Ce qui n'est pas récupérable, ce sont les dix-huit mois d'attention d'une petite équipe dépensés sur un cluster dont elle n'avait pas besoin. C'est le coût dont nous discutons réellement.
La version courte
Kubernetes est un ordonnanceur pour des flottes. Si vous n'avez pas de flotte, faites tourner vos conteneurs sur quelque chose qui vous donne une URL, mettez votre effort dans le Dockerfile et le health check, et reposez-vous la question quand vous aurez quinze services, un GPU, ou un client qui insiste. D'ici là, l'ingénieur le plus senior de votre équipe devrait construire le produit.
Si vous décidez ça en ce moment et voulez un second avis qui ne vend aucune des deux réponses, parlons-en.