Cela fait près d’un an et demi que la communauté Kubernetes a officiellement annoncé la disponibilité générale de la Gateway API, une étape majeure qui a redéfini la gestion du réseau et du trafic dans les clusters Kubernetes. Il ne s’agissait pas d’une simple mise à jour incrémentielle, mais d’un changement fondamental dans la mise en réseau des environnements cloud natifs, avec un cadre puissant, extensible et expressif pour gérer la connectivité.
La Gateway API remplace les fonctionnalités limitées de l’Ingress API par une conception axée sur les rôles, des ressources standardisées et une architecture extensible. Du routage avancé et de la répartition du trafic à la prise en charge de plusieurs locataires grâce à sa conception axée sur les rôles, la Gateway API permet de répondre à des cas d’usage complexes qui étaient auparavant difficiles à gérer. Il n’est donc pas surprenant que cette évolution ait suscité une vague d’innovation dans l’ensemble du secteur, les fournisseurs — dont F5 — ayant reconnu son potentiel pour façonner l’avenir de la mise en réseau dans Kubernetes.
Pour autant, l’adoption d’une nouvelle norme comme celle-ci ne se fait pas du jour au lendemain. Bien que l’API Gateway offre des avantages évidents, de nombreuses organisations restent prudentes. Elles évaluent soigneusement la complexité de la migration et les outils Ingress existants au regard de la configuration du routage standardisée, mais néanmoins flexible, proposée par l’API Gateway. Leur décision de l’adopter n’est pas uniquement motivée par des contraintes techniques : elle repose sur un arbitrage. Le temps, les efforts et les risques liés à la transition doivent être compensés par des améliorations significatives et concrètes de leurs capacités réseau.
Le rythme plus lent de l’adoption dans l’ensemble du secteur témoigne de cette approche prudente. Bien que la Gateway API soit largement considérée comme l’avenir de la mise en réseau dans Kubernetes, de nombreuses organisations continuent d’en explorer les capacités ou d’en évaluer les compromis avant de s’engager dans un déploiement à grande échelle. Les retours de la communauté Kubernetes indiquent que les expérimentations autour de la Gateway API progressent régulièrement. Les premiers utilisateurs l’exploitent pour des cas d’usage variés, allant du simple routage HTTP aux architectures mutualisées avancées. Cela témoigne d’un intérêt croissant pour les possibilités offertes par la Gateway API, même si de nombreuses équipes préfèrent encore attendre de voir comment elle évolue.
Chez F5, nous avons observé une dynamique similaire. Nombre de nos clients préfèrent ne pas franchir le pas immédiatement. Ce n’est pas par manque d’intérêt, mais parce qu’ils cherchent à concilier l’innovation avec la fiabilité opérationnelle qu’offrent les solutions Ingress éprouvées. C’est pourquoi nous estimons que la transition vers la Gateway API ne doit pas nécessairement se faire dans la précipitation. Elle doit simplement être menée de manière stratégique.
Examinons cela plus en détail. La migration vers la Gateway API présente notamment les défis suivants :
- Refonte complexe de l’infrastructure : La migration peut nécessiter de réécrire les processus d’automatisation et de modifier les pipelines applicatifs existants.
- Lacunes dans la prise en charge de l’écosystème : La prise en charge complète des outils et des contrôleurs est encore en cours d’évolution.
- Manque de temps et d’expertise : La courbe d’apprentissage et la refactorisation nécessitent d’y consacrer du temps.
- Aversion au risque : Les équipes hésitent à perturber ce qui fonctionne déjà.
Pourtant, les avantages sont également considérables :
- Conception axée sur les rôles : Les ressources de l’API Gateway sont réparties selon les rôles au sein de l’organisation. Les développeurs peuvent ainsi apporter des modifications sans perturber les autres équipes.
- Politiques de trafic standardisées : De nombreuses politiques de trafic courantes sont étroitement intégrées à l’API elle-même, ce qui permet d’uniformiser la configuration entre les différentes implémentations et de la gérer bien plus facilement qu’avec les annotations Ingress.
- Extensibilité : Les points d’extension permettent aux implémentations d’étendre la Gateway API afin de proposer des fonctionnalités personnalisées dans le cadre défini par l’API.
S’il y a bien une chose que nous savons sur la livraison d’applications et l’infrastructure, c’est que le changement prend du temps et nécessite de convaincre l’ensemble de l’entreprise. Un accompagnement, des conseils et une innovation continus sont indispensables ne serait-ce que pour amorcer la transition.
Relever les défis liés à l’adoption de Gateway API : les enseignements de F5
Chez F5, nous participons activement au développement et à l’évolution de la mise en réseau Kubernetes. Nous avons été directement confrontés aux défis qu’elle présente et avons aidé les équipes à les surmonter.
Notre expérience confirme une vérité fondamentale : réussir l’adoption de la Gateway API ne consiste pas seulement à mettre en œuvre une nouvelle norme. Il s’agit de poser les bases d’une réussite future. Pour y parvenir, les organisations ont besoin de solutions qui privilégient la simplicité, les performances, la flexibilité et un support solide. Voici comment ces principes facilitent les transitions et créent les conditions d’une valeur durable :
- La simplicité grâce à une approche entièrement repensée : La migration vers la Gateway API ne se limite pas à des changements techniques. Elle implique une transformation culturelle et opérationnelle. En repartant de zéro, nous pouvons résoudre tous les problèmes rencontrés avec Ingress et offrir une expérience réseau supérieure au moyen d’une interface unique : la Gateway API. Bien que cette approche puisse nécessiter davantage d’efforts au départ, les avantages à long terme — processus rationalisés, réduction des coûts opérationnels et résultats plus rapides — compensent largement les difficultés.
- La performance comme fondement : Les performances réseau sont essentielles, en particulier dans les environnements Kubernetes à grande échelle. Les implémentations légères de la Gateway API doivent s’appuyer sur un plan de données conçu pour réduire au minimum la surcharge architecturale, améliorant ainsi la latence, l’efficacité des ressources et l’évolutivité. Les solutions doivent allier la flexibilité de la Gateway API à des performances élevées par défaut afin que les équipes puissent effectuer la transition sans compromettre la rapidité ni la fiabilité.
- Flexibilité grâce à une conception modulaire : Les environnements Kubernetes sont très variés, allant de simples besoins de routage à des architectures complexes. Les solutions modulaires basées sur la Gateway API permettent aux équipes d’adopter certaines fonctionnalités en complément d’autres solutions, telles que les maillages de services, afin de répondre aux besoins de leur environnement sans ajouter de complexité. Cette approche favorise l’expérimentation et garantit que les solutions restent évolutives et adaptables.
- L’accompagnement comme catalyseur de réussite : Les conseils d’experts peuvent vous être très utiles lors de l’adoption de la Gateway API. Une documentation complète, des ressources fiables et un accompagnement pratique facilitent la transition depuis Ingress. Le recours à des partenaires de confiance et l’implication de la communauté simplifient considérablement la migration, transformant un changement intimidant en un processus fluide et efficace.
L’avenir, c’est la Gateway API… à votre rythme
Nous savons que 18 mois, ce n’est pas très long et que, même si la Gateway API a ouvert tout un champ de possibilités, cela ne signifie pas que toutes les organisations sont déjà prêtes à l’adopter.
Pour de nombreuses équipes, l’API Ingress est non seulement une solution performante, mais aussi un composant essentiel de leur infrastructure existante. Depuis des années, elle constitue la pierre angulaire de la mise en réseau de Kubernetes. Les organisations disposant d’environnements bien établis ne doivent pas se sentir contraintes d’abandonner une solution stable et éprouvée.
Chez F5, nous sommes pleinement conscients de cette réalité, c’est pourquoi nous n’abandonnons pas l’API Ingress. Nous continuons à investir dans le développement de F5 NGINX Ingress Controller, en proposant des innovations et des fonctionnalités qui lui permettent de rester robuste, sécurisé et adapté aux cas d’usage modernes.
Pour les organisations qui souhaitent continuer à utiliser Ingress, nous nous engageons à faire en sorte qu’il reste une solution à forte valeur ajoutée permettant d’exécuter en toute confiance les charges de travail Kubernetes actuelles. Pour les équipes qui explorent la Gateway API, notre solution spécialement conçue F5 NGINX Gateway Fabric allie simplicité moderne, performances et flexibilité afin d’aider les organisations à adopter cette norme en toute confiance.
La décision de passer à l’API Gateway constitue un changement majeur qui ne doit pas nécessairement s’opérer du jour au lendemain. À terme, les organisations qui franchiront le pas se donneront toutefois les moyens de croître et d’innover, tout en jetant les bases de leur réussite future grâce à un système moderne, évolutif et interopérable qui façonnera l’avenir de la mise en réseau Kubernetes. Que ce soit aujourd’hui ou plus tard, chez F5, nous serons prêts quand vous le serez. Pour en savoir plus, contactez-nous chez F5.
À propos des auteurs
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.