Rédaction – Cet article fait partie d’une série en 10 volets :
- Réduire la complexité grâce à Kubernetes prêt pour la production (cet article)
- Comment améliorer la résilience dans Kubernetes grâce à une gestion avancée du trafic
- Comment améliorer la visibilité dans Kubernetes
- Six façons de sécuriser Kubernetes à l’aide d’outils de gestion du trafic
- Guide pour choisir un contrôleur Ingress, 1re partie : identifiez vos besoins
- Guide pour choisir un contrôleur Ingress, 2e partie : risques et pérennisation
- Guide pour choisir un contrôleur Ingress, 3e partie : open source, par défaut ou commercial
- Guide pour choisir un contrôleur Ingress, 4e partie : les options du contrôleur Ingress NGINX
- Comment choisir un maillage de services
- Tests de performance des contrôleurs Ingress NGINX dans un environnement cloud Kubernetes dynamique
Vous pouvez également télécharger l’intégralité de cette série d’articles sous la forme d’un e-book gratuit : « Faire passer Kubernetes des tests à la production ».
2020 a été une année que peu d’entre nous oublieront un jour. La fermeture soudaine des écoles, des entreprises et des services publics nous a brutalement isolés de nos communautés et plongés dans l’incertitude quant à notre sécurité et à notre stabilité financière. Imaginez maintenant un instant que cela se soit produit en 2000, voire en 2010. Qu’est-ce qui aurait été différent ? La technologie. Sans les services numériques de haute qualité que nous tenons pour acquis – soins de santé, vidéo en streaming, outils de collaboration à distance –, une pandémie aurait été une expérience très différente. Qu’est-ce qui distinguait autant la technologie de 2020 de celle des décennies précédentes ? Les conteneurs et les microservices.
Les microservices reposent généralement sur des conteneurs et Kubernetes. Ces architectures stimulent la croissance et l’innovation des entreprises en réduisant le délai de mise sur le marché des expériences numériques. Qu’elles soient utilisées en complément d’architectures traditionnelles ou de manière autonome, ces technologies applicatives modernes offrent une évolutivité et une flexibilité accrues, des déploiements plus rapides, voire des économies de coûts.
Avant 2020, nous avions constaté que la plupart de nos clients avaient déjà commencé à adopter les microservices dans le cadre de leur stratégie de transformation numérique, mais la pandémie a véritablement accéléré la modernisation des applications. Notre enquête de 2020 menée auprès des utilisateurs de NGINX a révélé que 60 % des personnes interrogées utilisent des microservices en production, contre 40 % en 2019, et que les conteneurs sont plus de deux fois plus populaires que les autres technologies d’applications modernes.

Kubernetes est la norme de facto pour la gestion des applications conteneurisées, comme le montre l’enquête 2020 de la Cloud Native Computing Foundation (CNCF), qui révèle que 91 % des personnes interrogées utilisent Kubernetes, dont 83 % en production. Lorsqu’elles adoptent Kubernetes, de nombreuses organisations sont préparées à d’importants changements architecturaux, mais sont surprises par les répercussions organisationnelles liées à l’exploitation à grande échelle des technologies d’applications modernes. Si vous utilisez Kubernetes, vous avez probablement rencontré ces trois obstacles critiques pour votre activité :
- Culture
Même lorsque les équipes applicatives adoptent des approches modernes telles que le développement agile et le DevOps, elles restent généralement soumises à la loi de Conway, selon laquelle « les organisations conçoivent des systèmes qui reflètent leur propre structure de communication ». Autrement dit, les applications distribuées sont développées par des équipes distribuées qui travaillent de manière indépendante tout en partageant des ressources. Si cette structure est idéale pour permettre aux équipes d’avancer rapidement, elle favorise également la création de silos. Il en résulte notamment une mauvaise communication (qui entraîne elle-même d’autres conséquences), des failles de sécurité, une prolifération des outils, des pratiques d’automatisation incohérentes et des conflits entre les équipes. - Complexité
Pour mettre en œuvre des technologies de microservices adaptées aux entreprises, les organisations doivent assembler un ensemble de composants essentiels assurant l’observabilité, la sécurité et la gestion du trafic. En règle générale, les équipes ont recours à des plateformes d’infrastructure, à des services cloud natifs et à des outils open source pour répondre à ce besoin. Si chacune de ces stratégies a sa place, elle présente également des inconvénients susceptibles d’accroître la complexité. Trop souvent, différentes équipes au sein d’une même organisation choisissent des stratégies différentes pour répondre aux mêmes exigences, ce qui entraîne une « dette opérationnelle ». En outre, les équipes choisissent des processus et des outils à un moment donné, puis continuent à les utiliser sans tenir compte de l’évolution des exigences liées au déploiement et à l’exploitation d’applications modernes basées sur des microservices et utilisant des conteneurs. Le panorama interactif du cloud natif de la CNCF illustre bien la complexité de l’infrastructure nécessaire à la prise en charge des applications basées sur des microservices. Les organisations doivent maîtriser un large éventail de technologies disparates, avec pour conséquences une dépendance vis-à-vis de l’infrastructure, une informatique parallèle, une prolifération des outils et une courbe d’apprentissage abrupte pour les personnes chargées de la maintenance de l’infrastructure. - Sécurité
Les exigences de sécurité diffèrent considérablement entre les applications cloud natives et les applications traditionnelles, car les stratégies telles que la sécurité périmétrique ne sont pas adaptées à Kubernetes. Le vaste écosystème et la nature distribuée des applications conteneurisées élargissent considérablement la surface d’attaque, tandis que le recours à des applications SaaS externes multiplie les possibilités, pour les employés comme pour les personnes extérieures, d’injecter du code malveillant ou d’exfiltrer des informations. En outre, les conséquences évoquées dans les sections consacrées à la culture et à la complexité — notamment la prolifération des outils — ont une incidence directe sur la sécurité et la résilience de vos applications modernes. Utiliser différents outils au sein de votre écosystème pour résoudre un même problème n’est pas seulement inefficace : cela représente également un défi majeur pour les équipes SecOps, qui doivent apprendre à configurer correctement chaque composant.
La solution : Kubernetes prêt pour la production
Comme pour la plupart des problèmes organisationnels, la solution pour surmonter les défis liés à Kubernetes repose sur une combinaison de technologies et de processus. Dans la suite de cet article, nous allons nous concentrer sur l’aspect technologique, mais restez à l’affût de nos prochains articles consacrés aux processus et à d’autres sujets.
Kubernetes étant une technologie open source, il existe de nombreuses façons de la mettre en œuvre. Si certaines organisations préfèrent déployer elles-mêmes une version standard de Kubernetes, beaucoup apprécient la flexibilité, le cadre structurant et l’assistance qu’offrent des services tels qu’Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Microsoft Azure Kubernetes Service (AKS), Red Hat OpenShift Container Platform et Rancher.
Les plateformes Kubernetes peuvent faciliter la mise en route. Cependant, elles privilégient l’étendue des services plutôt que leur richesse fonctionnelle. Ainsi, même si vous pouvez disposer de tous les services dont vous avez besoin au même endroit, il est peu probable qu’ils offrent les fonctionnalités nécessaires pour être véritablement prêts pour une mise en production à grande échelle. En particulier, ils ne mettent pas l’accent sur les fonctions avancées de réseau et de sécurité, et c’est précisément sur ces aspects que Kubernetes déçoit de nombreux clients.
Pour rendre Kubernetes adapté à la production, vous devez ajouter trois composants supplémentaires dans cet ordre :
- Une couche d’entrée-sortie évolutive pour acheminer le trafic vers et depuis le cluster
Cette fonction est assurée par un contrôleur Ingress, un équilibreur de charge spécialisé qui masque la complexité de la mise en réseau Kubernetes et fait le lien entre les services d’un cluster Kubernetes et ceux qui lui sont externes. Ce composant devient adapté à la production lorsqu’il intègre des fonctionnalités qui renforcent la résilience (par exemple, des contrôles d’intégrité avancés et des métriques Prometheus), permettent une mise à l’échelle rapide (reconfiguration dynamique) et prennent en charge le libre-service (contrôle d’accès basé sur les rôles [RBAC]).
- Sécurité intégrée pour se protéger contre les menaces dans l’ensemble du cluster
Si une sécurité « à gros grain » peut suffire à l’extérieur du cluster, une sécurité « à grain fin » est nécessaire à l’intérieur. Selon la complexité de votre cluster, vous devrez peut-être déployer un pare-feu d’applications web (WAF) flexible à trois emplacements : sur le contrôleur Ingress, en tant que proxy pour chaque service et en tant que proxy pour chaque pod. Cette flexibilité vous permet d’appliquer des contrôles plus stricts aux applications sensibles, telles que la facturation, et des contrôles plus souples lorsque le risque est moindre.
- Une couche de trafic est-ouest évolutive pour optimiser le trafic au sein du cluster
Ce troisième composant devient nécessaire lorsque vos applications Kubernetes atteignent un niveau de complexité et une échelle que les outils de base ne peuvent plus gérer. À ce stade, vous avez besoin d’un maillage de services, un outil d’orchestration qui assure une gestion du trafic et une sécurité encore plus granulaires pour les services applicatifs au sein du cluster. Un maillage de services est généralement chargé de gérer le routage entre les applications conteneurisées, de fournir et d’appliquer de manière autonome des politiques de chiffrement TLS mutuel (mTLS) entre services, et d’offrir une visibilité sur la disponibilité et la sécurité des applications.
Lors de la sélection de ces composants, privilégiez la portabilité et la visibilité. Les composants indépendants de la plateforme réduisent la complexité et améliorent la sécurité : vos équipes ont moins d’outils à maîtriser et à sécuriser, et les charges de travail peuvent être déplacées plus facilement en fonction des besoins de votre entreprise. On ne saurait trop insister sur l’importance de la visibilité et de la supervision. Les intégrations avec des outils populaires tels que Grafana et Prometheus offrent une vue unifiée de votre infrastructure depuis une « interface unique », permettant à votre équipe de détecter les problèmes avant que vos clients ne les découvrent. Il existe également d’autres technologies complémentaires qui, sans être nécessairement indispensables à un environnement Kubernetes de niveau production, font partie intégrante du développement d’applications modernes. Par exemple, lorsque les entreprises sont prêtes à moderniser leurs applications traditionnelles, l’une des premières étapes consiste à créer des microservices avec une passerelle API.
Comment NGINX peut vous aider
Nos solutions Kubernetes sont indépendantes de la plateforme et comprennent les trois composants nécessaires pour déployer Kubernetes en production : NGINX Ingress Controller pour la couche de trafic entrant et sortant, NGINX App Protect comme pare-feu applicatif web (WAF), et NGINX Service Mesh pour la couche de trafic est-ouest.

Ces solutions peuvent faire de Kubernetes votre meilleur allié en vous permettant d’agir dans quatre domaines clés :
- Automatisation – Commercialisez vos applications plus rapidement et en toute sécurité
Déployez, faites évoluer, sécurisez et mettez à jour vos applications grâce aux fonctionnalités de routage du trafic et d’intégration des applications de NGINX Ingress Controller, associées au déploiement automatique des side-cars NGINX Plus par NGINX Service Mesh. - Sécurité – Protégez vos clients et votre entreprise contre les menaces existantes et émergentes
Réduisez les points de défaillance potentiels en déployant NGINX App Protect n’importe où dans le cluster, tout en utilisant NGINX Service Mesh et NGINX Ingress Controller pour gérer et imposer le chiffrement de bout en bout entre les services. - Performances – Offrez les expériences numériques auxquelles vos clients et utilisateurs s’attendent
Gérez sans effort les pics de trafic et les menaces de sécurité sans compromettre les performances grâce aux solutions NGINX, plus performantes que les autres WAF, contrôleurs Ingress et équilibreurs de charge. - Visibilité – Faites évoluer votre entreprise et répondez mieux aux besoins de vos clients
Obtenez des informations ciblées sur les performances et la disponibilité des applications grâce à NGINX Ingress Controller et NGINX Service Mesh, ainsi que des traces détaillées pour comprendre comment les requêtes sont traitées dans vos applications basées sur des microservices.
Préparer la mise en production avec NGINX
NGINX Ingress Controller est disponible sous la forme d’un essai gratuit de 30 jours, qui inclut NGINX App Protect pour sécuriser vos applications conteneurisées. Nous vous recommandons d’ajouter NGINX Service Mesh, toujours gratuit (disponible en téléchargement sur f5.com) afin de profiter pleinement de votre essai. Vous pouvez désormais utiliser votre propre licence (BYOL) dans le cloud de votre choix.
À propos de l’auteur

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.