Kubernetes en production : ce que personne ne vous dit avant de migrer

La plupart des équipes qui migrent vers Kubernetes y arrivent convaincues de résoudre un problème d'infrastructure. Ce qu’ils découvrent, généralement six mois plus tard, c’est qu’ils ont remplacé un ensemble de problèmes par un autre beaucoup plus sophistiqué – et que la complexité opérationnelle qu’ils pensaient avoir éliminée a tout simplement disparu.

Ce que Kubernetes fait vraiment bien

Kubernetes est né pour résoudre un problème concret : orchestrer des conteneurs à grande échelle, avec résilience et capacité de récupération automatique. Il fait ça très bien. Si votre organisation exploite des dizaines de services avec des modèles de trafic variables, a besoin de déploiements sans temps d'arrêt et dispose d'une équipe mature pour exploiter la plate-forme, Kubernetes offre une réelle valeur ajoutée.

La planification de la charge de travail, la gestion des ressources, la prise en charge des stratégies de déploiement progressif et l'intégration avec les outils d'observabilité sont vraiment bonnes. Ces avantages ne relèvent pas du marketing : ils existent, fonctionnent et font la différence dans la production.

Le problème ne vient pas de ce que promet Kubernetes. C'est ce qu'il exige en retour.

La complexité qui apparaît après la migration

La mise en réseau dans Kubernetes n'est pas une configuration simple. Il s'agit d'une couche entière d'abstraction (plugins CNI, maillages de services, politiques réseau, DNS interne, contrôleurs d'entrée) que vous devez comprendre, maintenir et déboguer en cas de panne. Et quelque chose va se briser.

Le stockage est un autre point de friction que la plupart sous-estiment. Volumes persistants, StorageClasses, modes d'accès, instantanés, PVC de sauvegarde : tout cela doit être conçu avec soin. Les applications avec état sur Kubernetes sont nettement plus complexes que les mêmes applications exécutées sur des machines virtuelles conventionnelles.

Le RBAC, quant à lui, est le genre de chose que personne ne documente bien pendant la migration et qui se transforme en dette technique en quelques semaines. La définition d'autorisations granulaires pour des espaces de noms, des comptes de service et des charges de travail distincts nécessite une discipline que les équipes sous pression peuvent rarement maintenir.

Les mises à niveau de cluster constituent un autre chapitre. Kubernetes a un cycle de vie agressif : les versions deviennent rapidement obsolètes et chaque mise à niveau nécessite une validation de compatibilité des API, des manifestes, des graphiques Helm et des opérateurs. Ignorez cela pendant quelques mois et vous exécuterez une version non prise en charge en production.

Le paradoxe du SRE

Il existe une ironie bien connue dans le fait que les équipes adoptent Kubernetes sans planification adéquate : vous avez besoin d’ingénieurs en fiabilité expérimentés pour faire fonctionner l’outil censé réduire le besoin d’opérations manuelles. Kubernetes a été conçu pour l'échelle de Google. Il porte cet héritage.

Les petites équipes constatent souvent qu'elles passent plus de temps à exploiter la plateforme qu'à développer le produit. Chaque incident implique des journaux de plusieurs pods, le suivi des événements de planification, l'analyse des limites de ressources et le débogage du réseau qui n'ont de sens que pour ceux qui comprennent profondément les abstractions internes.

Il ne s'agit pas d'un défaut de conception. C’est une conséquence directe de la généralité de la plateforme. Kubernetes résout des problèmes complexes de manière complexe – et cette complexité ne disparaît pas simplement parce que les conteneurs sont en cours d'exécution.

Lorsque Kubernetes géré modifie le calcul

EKS, GKE et AKS n'éliminent pas la complexité opérationnelle, mais ils en distribuent une partie au fournisseur de cloud. Le plan de contrôle — etcd, serveur API, planificateur, gestionnaire de contrôleur — relève de la responsabilité du fournisseur. Les mises à niveau de version deviennent moins traumatisantes. L'intégration avec les services d'identité, de stockage et de réseau du fournisseur est préconfigurée.

Pour les équipes opérant déjà au sein d’un fournisseur de cloud spécifique, Kubernetes géré réduit considérablement le coût d’entrée. Ce n'est pas nul, mais c'est nettement moins que l'exploitation d'un cluster autogéré.

Le calcul change encore lorsque l’on considère le verrouillage. GKE Autopilot, par exemple, fait tellement abstraction que vous perdez le contrôle de la planification et de la configuration des nœuds. C'est un échange valable pour certaines équipes et inacceptable pour d'autres. Le choix dépend de l'endroit où vous souhaitez la souveraineté et de l'endroit où vous acceptez la délégation.

Quand une stratégie plus simple est la décision intelligente

Kubernetes n'est pas la bonne réponse pour chaque charge de travail. Si vous exploitez un monolithe bien structuré avec un trafic prévisible, une instance EC2 bien configurée avec un processus de déploiement automatisé peut être plus fiable, moins chère et beaucoup plus facile à exploiter.

Des outils tels que Fly.io, Railway, Render ou même AWS App Runner offrent la plupart des avantages opérationnels de Kubernetes (zéro temps d'arrêt, mise à l'échelle automatique, restaurations) sans la couche d'abstractions qui nécessitent la maintenance d'experts.

La question que les équipes se posent rarement avant de migrer est simple : quel problème spécifique Kubernetes va-t-il résoudre que l'infrastructure actuelle ne peut pas résoudre ? Si la réponse est vague – « évolutivité », « modernisation », « meilleure gestion des conteneurs » – l’investissement opérationnel n’est probablement pas justifié.

Kubernetes est logique lorsque vous disposez de plusieurs services avec des cycles de déploiement indépendants, de la nécessité d'isoler les charges de travail, de modèles de trafic très variables et d'une équipe dotée d'une réelle capacité à exploiter la plateforme. Ces quatre critères réunis apparaissent rarement avant qu’une organisation ne dispose de dizaines d’ingénieurs et d’années de maturité en matière de conteneurs.

La décision qui arrive au mauvais moment

La migration vers Kubernetes se produit presque toujours au moment où la préparation est la plus faible. L'équipe s'agrandit, la pression d'évoluer est apparue, quelqu'un a vu une conférence à la KubeCon - et la décision est prise avant que l'équipe n'ait suffisamment d'expérience pour comprendre ce qu'elle entreprend.

Le résultat typique : six mois d’efforts pour migrer, suivis de six autres mois pour tenter de stabiliser l’environnement. Les problèmes qui ont motivé la migration – déploiements fragiles, manque d’isolement, difficulté de mise à l’échelle – continuent d’exister, avec désormais un niveau supplémentaire de diagnostic.

Cela ne veut pas dire que la migration était une erreur. Cela signifie qu’elle avait besoin de plus de planification, d’un calendrier réaliste et d’une formation avant l’exécution. Kubernetes est une plateforme puissante. Mais puissance et simplicité coexistent rarement – et ceux qui ne comprennent pas cette distinction apprennent après que la décision a déjà été prise.