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 l’épuisement professionnel, ce qui contribue à un environnement de travail plus stable et plus agréable.
Ainsi, bien que Kubernetes reste un outil puissant pour les grandes infrastructures nécessitant une mise à l’échelle complexe, il n’est pas nécessairement adapté à toutes les situations. Pour des infrastructures plus petites ou des besoins moins complexes, des solutions plus simples comme ECS, Lambda ou EC2 peuvent offrir des avantages significatifs en termes de flexibilité, de réduction des coûts et de facilité de gestion. L’expérience de nombreuses entreprises montre que parfois, moins de complexité peut entraîner plus de bénéfices, tant en termes de performances qu’en termes de bien-être des équipes.
L’adoption de Kubernetes : une solution efficace ou un coût caché ?
L’adoption de Kubernetes par les entreprises pour orchestrer des conteneurs dans des infrastructures complexes est indéniablement une avancée majeure en matière de gestion des applications et de mise à l’échelle automatique. Cependant, comme tout outil puissant, Kubernetes présente des défis qui ne doivent pas être sous-estimés, notamment lorsque les besoins de l’organisation évoluent.
Tout d'abord, l'un des principaux inconvénients de Kubernetes réside dans la complexité qu’il impose au fil du temps. Si sa courbe d’apprentissage est déjà assez élevée, la gestion de plusieurs clusters dans des environnements grandissants peut rapidement devenir coûteuse et difficile. De plus, la multiplication des outils nécessaires à son bon fonctionnement, combinée à la nécessité d'une gestion fine des ressources, conduit à une surcharge de travail pour les équipes techniques. Au lieu de se concentrer sur l’innovation ou l’amélioration des produits, les équipes se retrouvent souvent à passer une partie significative de leur temps à maintenir la plateforme Kubernetes elle-même.
Un autre point essentiel est celui des coûts cachés liés à l’infrastructure Kubernetes. Si le système peut s’avérer efficace dans les environnements à grande échelle, il engendre des dépenses importantes en termes de ressources et de temps pour gérer les clusters et former des équipes. Les entreprises qui ne prennent pas le temps d'évaluer correctement ces aspects risquent de se retrouver avec des coûts disproportionnés par rapport aux bénéfices réels apportés par la solution. Cela devient d’autant plus problématique lorsque l’infrastructure s’avère surdimensionnée par rapport aux besoins spécifiques de l’entreprise, entraînant un gaspillage de ressources et une gestion inefficace.
Face à cette complexité, des solutions plus simples et plus adaptées à des environnements moins exigeants, telles que des services managés comme AWS ECS ou Fargate, peuvent offrir une alternative intéressante. Ces plateformes permettent de réduire les coûts d’infrastructure tout en simplifiant considérablement la gestion des déploiements. L’approche consistant à migrer progressivement vers ces solutions plus légères permet non seulement de mieux gérer les coûts, mais aussi de concentrer les efforts sur des priorités stratégiques sans sacrifier la performance.
En fin de compte, Kubernetes reste une solution pertinente pour des infrastructures nécessitant une mise à l’échelle complexe, mais pour des besoins moins sophistiqués, des alternatives plus simples semblent offrir de nombreux avantages. Parfois, réduire la complexité technologique permet non seulement d’améliorer les performances, mais aussi de maintenir des équipes plus sereines et plus concentrées sur l’innovation, évitant ainsi les risques d’épuisement professionnel. Adopter une approche pragmatique, en tenant compte des besoins réels de l’entreprise, semble donc être une stratégie plus sage que de s’accrocher systématiquement à des outils qui, bien que puissants, ne correspondent plus aux exigences actuelles.
Sources : Ben Houston's blog post, Stackademic, Red Hat
Et vous ?
Quel est votre avis sur le sujet ? Kubernetes : l’avenir de l’orchestration ou un fardeau technologique à repenser ? Faut-il abandonner Kubernetes pour des solutions plus agiles et rentables comme Google Cloud Run ?Voir aussi :
84 % des responsables informatiques pensent que Kubernetes sera bientôt la principale plate-forme utilisée pour développer toutes les applications, mais avec de grandes inquiétudes sur la sécurité K3s : une distribution Kubernetes légère et facile à installer, avec un binaire de moins de 100 Mo et des dépendances externes réduites au minimum 
Envoyé par Bruno
