Avez-vous vraiment besoin de Kubernetes ?

Kubernetes est devenu la réponse par défaut à la question « comment déployer nos applications ». C'est un excellent outil, et c'est aussi la source la plus fréquente de complexité non nécessaire que nous rencontrons chez nos clients.

Ce que Kubernetes résout réellement

Il résout quatre problèmes précis : l'orchestration de nombreux services hétérogènes, la mise à l'échelle automatique fine, la portabilité entre environnements, et la standardisation du déploiement dans une organisation où plusieurs équipes livrent indépendamment.

Si vous avez ces quatre problèmes, Kubernetes est probablement le bon choix.

Ce qu'il coûte

Il coûte une compétence permanente. Pas une formation initiale : une compétence disponible en continu, capable de diagnostiquer un problème réseau entre pods, de comprendre pourquoi un pod est expulsé, de gérer les montées de version du cluster tous les quelques mois.

Cette compétence est rare et chère. Quand elle repose sur une seule personne dans l'équipe, vous avez remplacé un problème de déploiement par un problème de continuité, souvent sans vous en apercevoir.

Il coûte aussi une surface de configuration considérable. Politiques réseau, contrôle d'accès, quotas de ressources, sondes de disponibilité, gestion des secrets : chacun de ces éléments est une occasion de mauvaise configuration, et les mauvaises configurations en environnement conteneurisé sont une cause fréquente d'incident de sécurité.

Le test à trois questions

Combien de services distincts déployez-vous ? En dessous de dix, l'orchestration n'est pas votre problème.

Combien de personnes savent diagnostiquer un incident sur le cluster, aujourd'hui, dans votre organisation ? Si la réponse est zéro ou un, vous n'êtes pas prêt, quel que soit le nombre de services.

Votre charge varie-t-elle d'un facteur significatif dans la journée ? Si elle est stable, la mise à l'échelle automatique fine n'apporte rien qu'un dimensionnement correct ne donne déjà.

Si les trois réponses ne plaident pas clairement en faveur de Kubernetes, un service applicatif managé — App Service, Cloud Run, ECS, App Runner selon votre fournisseur — répond au besoin avec une fraction de la surface d'exploitation.

L'objection du verrouillage fournisseur

L'argument classique en faveur de Kubernetes est la portabilité : ne pas dépendre d'un fournisseur.

C'est vrai en théorie et partiel en pratique. Un cluster réel utilise l'équilibreur de charge, le stockage, le fournisseur d'identité et le registre d'images de son hôte. La migration reste possible mais elle n'est pas gratuite, et le coût d'exploitation payé chaque mois pour préserver cette option dépasse souvent le coût d'une migration qui n'arrivera peut-être jamais.

Ce que nous recommandons le plus souvent

Commencer par un service applicatif managé, avec une conteneurisation propre. La conteneurisation est le vrai investissement de portabilité : elle est peu coûteuse, elle rend le passage ultérieur à Kubernetes simple, et elle ne demande aucune compétence d'exploitation supplémentaire.

Passer à Kubernetes quand le nombre de services et la taille de l'équipe le justifient, pas avant. C'est un conseil qui raccourcit nos missions, et c'est celui qui laisse les clients les plus satisfaits deux ans plus tard.