Kubernetes : « Je n'avais pas besoin de Kubernetes, vous n'en avez probablement pas besoin non plus », affirme Ben Houston.

Faut-il privilégier des solutions plus agiles et rentables comme Google Cloud Run ?

Dans un billet de blog publié récemment, Ben Houston partage ses réflexions sur l'utilisation de Kubernetes et son choix de le remplacer par Google Cloud Run. Connu pour ses contributions majeures à des projets open source comme Three.js, Behave-Graph et Threeify, ainsi que pour son expérience dans l'industrie des jeux vidéo, des effets visuels et de la défense, Houston est une figure respectée dans le domaine du développement logiciel. Il a également co-développé des outils populaires comme Deadline et Krakatoa, ce qui renforce la pertinence de son analyse technique.

Dans son article, Houston remet en question l’engouement pour Kubernetes, qu’il décrit comme complexe, coûteux et inadapté à des projets modestes ou agiles. Il critique notamment les coûts élevés d'infrastructure, les processus fastidieux de mise à l’échelle et la surcharge de complexité, qui nécessitent souvent des équipes DevOps spécialisées. À la place, il recommande Google Cloud Run, une solution plus simple et économique, avec une facturation à l’usage précis, un autoscaling rapide et une gestion rationalisée des conteneurs.


Cette prise de position a suscité des réactions contrastées. Certains professionnels, frustrés par la lourdeur opérationnelle de Kubernetes, soutiennent son analyse et privilégient des alternatives plus directes. D'autres, plus expérimentés, soulignent que Kubernetes peut offrir des bénéfices importants dans des environnements bien maîtrisés ou pour des besoins spécifiques. Ce débat illustre une tension entre puissance technologique et simplicité, un dilemme auquel de nombreuses équipes techniques font face aujourd’hui.

Orchestration et gestion automatisée des conteneurs

Kubernetes (également connu sous le nom de k8s ou « kube ») est une plateforme d'orchestration de conteneurs open source qui automatise une grande partie des processus manuels impliqués dans le déploiement, la gestion et la mise à l'échelle des applications conteneurisées. Développé à l'origine par des ingénieurs de Google dans le cadre du projet Borg, Kubernetes a été remis à la Cloud Native Computing Foundation (CNCF) en 2015.

Un déploiement Kubernetes fonctionnel s'appelle un cluster, c'est-à-dire un groupe d'hôtes exécutant des conteneurs Linux. Un cluster Kubernetes peut être visualisé en deux parties : le plan de contrôle et les machines de calcul, ou nœuds. Chaque nœud est un environnement Linux autonome et peut être une machine physique ou virtuelle. Chaque nœud exécute des pods, qui sont constitués de conteneurs.


Le plan de contrôle est responsable du maintien de l'état souhaité du cluster, en veillant à ce que les applications en cours d'exécution et les images de conteneurs qu'elles utilisent soient conformes à la configuration spécifiée. Les machines de calcul exécutent les applications et les charges de travail. Le plan de contrôle reçoit les commandes d'un administrateur (ou d'une équipe DevOps) et les transmet aux machines de calcul.

Ce transfert fonctionne grâce à une multitude de services qui décident automatiquement quel nœud est le mieux adapté à chaque tâche. Ces services découplent les définitions de travail des pods et transmettent automatiquement les demandes de service au bon pod, quel que soit son emplacement dans le cluster ou même s'il a été remplacé. Kubernetes alloue des ressources et affecte les modules nécessaires pour exécuter le travail demandé sur le nœud sélectionné.

Kubernetes s'exécute au-dessus d'un système d'exploitation et interagit avec les pods de conteneurs qui s'exécutent sur les nœuds. L'état souhaité d'un cluster Kubernetes définit les applications ou autres charges de travail à exécuter, les images qu'elles utilisent, les ressources qui doivent leur être allouées et d'autres détails de configuration.

L'endroit où vous exécutez Kubernetes dépend de vous. Il peut s'agir de serveurs nus, de machines virtuelles (VM), de fournisseurs de cloud publics, de clouds privés ou d'environnements de cloud hybrides. L'un des principaux avantages de Kubernetes est sa capacité à fonctionner sur une grande variété d'infrastructures.

Kubernetes et Docker

Docker peut être utilisé comme moteur d'exécution de conteneurs orchestré par Kubernetes. Lorsque Kubernetes planifie un pod sur un nœud, le kubelet (le service qui assure que chaque conteneur est en cours d'exécution) sur ce nœud demande à Docker de lancer les conteneurs spécifiés. Le kubelet recueille ensuite en permanence l'état de ces conteneurs auprès de Docker et transmet ces informations au plan de contrôle, tandis que Docker tire les conteneurs sur ce nœud et gère leur démarrage et leur arrêt.

La différence entre Kubernetes et Docker réside dans le fait qu'un système automatisé (Kubernetes) demande à Docker d'effectuer ces opérations, au lieu qu'un administrateur le fasse manuellement sur chaque nœud pour tous les conteneurs.

Migrer vers Kubernetes : entre flexibilité, sécurité et complexité

Une étude récente de Venafi, menée en 2023 auprès de 800 responsables de la sécurité et de l'informatique dans de grandes entreprises, met en lumière un dilemme majeur auquel sont confrontées les organisations aujourd'hui : bien que l'adoption du cloud et des technologies comme Kubernetes soit en pleine expansion, des inquiétudes croissantes émergent concernant les coûts, la sécurité et la gestion des infrastructures complexes. En effet, 76 % des professionnels de la sécurité estiment que la remise en question du cloud en termes de coûts et de sécurité est inévitable. Parmi eux, 84 % considèrent que Kubernetes deviendra bientôt la plateforme dominante pour le développement des applications. Cependant, cette évolution s'accompagne de préoccupations majeures, notamment sur la sécurité des environnements cloud natifs, exacerbée par la complexité de Kubernetes et des conteneurs.

Les résultats de l’étude révèlent également que 59 % des responsables ayant migré leurs applications vers le cloud admettent n’avoir pas suffisamment pris en compte les risques de sécurité inhérents à cette transition. Malgré une large adoption du cloud, 87 % des répondants ont commencé à migrer leurs applications, mais plus de la moitié d’entre eux ont échoué à les adapter efficacement aux technologies natives du cloud. Cette difficulté est liée à la complexité croissante des outils, comme Kubernetes, qui peuvent générer de nouveaux angles morts en matière de sécurité, rendant les infrastructures difficiles à sécuriser, surtout en raison du manque de maîtrise des environnements cloud natifs.

Kubernetes, bien que reconnu pour sa capacité à automatiser l’orchestration des conteneurs et à faciliter l’évolutivité des applications, représente un défi pour les entreprises. Les trois quarts des responsables de la sécurité craignent que sa rapidité de déploiement et sa complexité n'entraînent des vulnérabilités, particulièrement si la gestion des risques n'est pas abordée avec une attention adéquate. Cette inquiétude est renforcée par le constat que les équipes de sécurité ne maîtrisent pas encore pleinement les spécificités des environnements cloud natifs, bien que 90 % des professionnels estiment qu'une meilleure compréhension de ces environnements est essentielle pour sécuriser les applications.

Dans ce contexte, le lien entre l’adoption de Kubernetes et les préoccupations en matière de sécurité devient particulièrement pertinent. Si Kubernetes reste un atout pour les infrastructures complexes, son efficacité peut être compromise si les entreprises ne prennent pas en compte les implications en termes de sécurité et de gestion. Les entreprises doivent donc réévaluer leur approche en matière de migration vers le cloud et de gestion de Kubernetes, en s'assurant de combler les lacunes de sécurité pour éviter des violations ou des pannes coûteuses à l'avenir.

Ainsi, bien que le cloud natif et Kubernetes représentent l'avenir des infrastructures modernes, leur adoption nécessite une réflexion approfondie. Selon Matt Barker de Venafi, bien que le cloud natif offre une flexibilité et une résilience exceptionnelles, les entreprises doivent être conscientes des efforts nécessaires pour assurer la sécurité et l’efficacité de ces environnements. À défaut, la précipitation vers ces technologies pourrait conduire à des conséquences graves, notamment en termes de sécurité, si les entreprises ne prennent pas le temps d’intégrer des pratiques de sécurité robustes dès le départ.

Repenser l’orchestration des conteneurs : vers des solutions simples et rentables au-delà de Kubernetes

De nombreuses entreprises qui ont adopté Kubernetes dans leurs infrastructures se retrouvent confrontées à une réalité complexe à mesure que leurs besoins évoluent. Bien que Kubernetes offre des avantages significatifs en matière d’orchestration de conteneurs, d’automatisation de la mise à l’échelle et d’architecture cloud native, il peut également entraîner des défis importants à mesure que les systèmes se complexifient et que les équipes grandissent. L’une des difficultés majeures réside dans la gestion de multiples clusters, ce qui peut rapidement devenir coûteux et difficile à maintenir.

En effet, de nombreuses organisations constatent que les coûts cachés liés à Kubernetes peuvent être considérables. Ceux-ci incluent non seulement les frais d’infrastructure pour maintenir les clusters, mais aussi le temps et les ressources nécessaires pour former et gérer les équipes. La complexité opérationnelle croissante, la multiplication des outils et la nécessité d’une gestion fine des ressources rendent le système de plus en plus difficile à gérer. Lorsque l’on cumule ces défis à des périodes de forte charge ou des événements critiques, le résultat peut être une surcharge des équipes et des défaillances importantes des systèmes.

Le véritable point de rupture intervient souvent lorsqu’une analyse approfondie des coûts et des performances révèle que les avantages de Kubernetes ne compensent plus ses inconvénients. Les entreprises peuvent réaliser que les ressources sont mal utilisées, avec des clusters qui consomment beaucoup d’énergie pour gérer des composants ou des services qui n’en ont pas besoin. Les équipes se retrouvent alors à consacrer une grande partie de leur temps à gérer la plateforme plutôt qu’à se concentrer sur l’innovation ou sur les besoins réels de l’entreprise.

Face à cette situation, certaines entreprises choisissent de réévaluer leur approche et d’adopter des solutions plus simples et plus adaptées à leurs besoins spécifiques. Par exemple, l’utilisation de services managés comme AWS ECS ou Fargate peut offrir une solution plus souple et moins coûteuse pour l’orchestration des conteneurs. Ces alternatives permettent de réduire considérablement les coûts tout en simplifiant la gestion des déploiements. En migrer vers ces solutions peut être un choix stratégique, car elles offrent une meilleure adéquation avec des architectures plus petites et moins complexes.

Pour réussir cette transition, les entreprises commencent généralement par un audit complet de leurs services et de leurs besoins en infrastructure. Elles peuvent opter pour une migration progressive, en commençant par les services les moins critiques avant de passer aux services plus complexes. Cette approche permet de tester les nouvelles solutions tout en garantissant une transition fluide. Le suivi des performances, l’évaluation continue des résultats et la réorganisation des équipes pour mieux gérer les rotations de garde sont essentiels pour garantir le succès de la migration.

Les résultats de cette démarche peuvent être spectaculaires. De nombreuses entreprises rapportent une réduction significative des coûts d’infrastructure, des gains de productivité avec des déploiements plus rapides, et une diminution des incidents de production. En outre, la simplification de l’infrastructure et des processus permet de réduire le stress des équipes et de prévenir...