Kubernetes n’est plus un bac à sable expérimental réservé aux pionniers. C’est le système d’exploitation des entreprises modernes. Près de 20 millions de développeurs cloud-native s’appuient sur cette plateforme dans le monde entier. Plus de 90 % des organisations dans le monde devraient exécuter des applications conteneurisées en production d’ici 2027. Et deux tiers des organisations ayant adopté l’IA générative exécutent déjà des charges de travail d’inférence sur Kubernetes. L’orchestration des conteneurs est désormais essentielle aux activités des entreprises.
Mais voici une vérité qui dérange : seules 38 % des organisations qui exécutent Kubernetes en production ont atteint un niveau de maturité adapté aux exigences de l’entreprise, selon le rapport État des lieux des stratégies Kubernetes en entreprise en 2026, fondé sur une étude de SlashData financée par F5. Environ la moitié — 51 % — sont « établies », mais restent freinées par des lacunes critiques en matière de gouvernance, d’observabilité, de résilience ou de chaîne d’approvisionnement logicielle. Les 11 % restants sont encore en phase de standardisation.
Pour aider les entreprises à atteindre le niveau de maturité Kubernetes adapté à leurs exigences, la plateforme F5 Application Delivery and Security Platform (ADSP) propose une architecture unifiée qui élimine le cloisonnement opérationnel entre les équilibreurs de charge externes et les contrôleurs d’entrée au sein des clusters, remplaçant les chaînes d’outils multifournisseurs fragiles par une architecture cohérente, adaptée aux exigences des entreprises.
Un socle commun qui rassemble les équipes
Kubernetes remplit remarquablement bien son rôle. Il planifie les charges de travail, ajuste les ressources de calcul de manière élastique, rétablit automatiquement les pods défaillants et fait abstraction du matériel sous-jacent dans les environnements hybrides et multicloud. Mais l’orchestration des conteneurs ne représente que la moitié de l’équation. Le contrôle et la sécurisation du trafic en constituent l’autre moitié.
Kubernetes n’a jamais été conçu pour régir le comportement du trafic des applications et de l’IA dans les environnements d’entreprise distribués. Il ne prend pas de décisions de routage en temps réel en fonction de l’état global du réseau, n’applique pas les politiques de sécurité de l’entreprise de manière cohérente sur les flux entrants et sortants et ne garantit pas une isolation stricte du trafic entre locataires à grande échelle.
Et voici ce qui complique encore le problème : le trafic et la sécurité de Kubernetes ne relèvent pas d’un seul profil métier. Un ingénieur plateforme qui expose des microservices via GitOps, un architecte réseau qui gère l’appairage BGP (Border Gateway Protocol) multicluster et la décharge de traitements vers des DPU, et un RSSI qui se défend contre l’exploitation de vulnérabilités zero-day à l’aide de l’IA ont tous des exigences opérationnelles fondamentalement différentes.
Imposer à toutes les parties prenantes un outil unique censé convenir à tous mène toujours à l’échec : il est soit trop lourd pour les développeurs, soit trop limité pour les équipes chargées de l’infrastructure d’entreprise. F5 ADSP adopte une approche différente en proposant des solutions cloud-native conçues pour des besoins précis et adaptées à la manière dont chaque profil contrôle et sécurise réellement le trafic. Le tout repose sur un socle commun qui rassemble les équipes sans imposer de compromis à quiconque.
Des équipes différentes, des priorités distinctes en matière de trafic et de sécurité
À mesure que Kubernetes monte en charge — notamment lorsque les entreprises passent d’applications web sans état à des charges de travail d’IA avec état et à haut débit — quatre profils distincts se dessinent, chacun confronté à des difficultés très différentes.
- Le responsable plateforme et DevOps privilégie la rapidité, le libre-service et les workflows YAML natifs de Kubernetes. Trop souvent, il commence par utiliser un contrôleur communautaire gratuit, comme le projet communautaire ingress-nginx récemment abandonné, pour finalement se retrouver à maintenir un logiciel qui n’est plus pris en charge sur des dizaines de clusters de production, mobilisant ainsi des ressources d’ingénierie pour des tâches opérationnelles répétitives.
- Le responsable NetOps et infrastructure exige un routage efficace, un déchargement TLS à haute capacité, une isolation stricte entre locataires et une visibilité de bout en bout. Lorsque le trafic entre dans un cluster, les équipes réseau perdent souvent toute visibilité sur ce qui se passe, ce qui entraîne des cellules de crise de quatre heures pour tenter de déterminer si une panne provient du réseau ou du pod.
- Le responsable de l’infrastructure d’IA a investi des millions dans des clusters de GPU souvent sous-exploités, non pas par manque de puissance de calcul, mais parce que les goulets d’étranglement se situent dans l’acheminement efficace des tokens en entrée et en sortie, le routage intelligent des requêtes entre les modèles et l’isolation du trafic GPU entre les différents locataires.
- Le RSSI et le responsable SecOps s’inquiètent de l’exposition aux risques impossible à quantifier dans les clusters éphémères, du manque de cohérence des politiques de pare-feu applicatif web (WAF) et de sécurité des API, ainsi que de la rapidité avec laquelle les vulnérabilités actuelles sont exploitées.
Plutôt que de demander aux équipes DevOps de raisonner comme les équipes NetOps, ou aux équipes NetOps de gérer les fichiers YAML des applications, F5 fournit à chaque équipe un plan de données et un plan de contrôle cloud-native adaptés à ses besoins.
“F5 adopte une approche différente en proposant des solutions cloud-native conçues spécifiquement pour répondre à la manière dont chaque profil contrôle et sécurise réellement le trafic, le tout reposant sur un socle commun qui fédère les équipes sans imposer de compromis à quiconque.”
Pour les équipes DevOps et plateforme : une agilité légère et native de Kubernetes
Les ingénieurs plateforme et les développeurs recherchent une solution légère et agile, qui fonctionne nativement dans Kubernetes et s’intègre sans friction aux pipelines CI/CD et GitOps. C’est précisément le rôle de F5 Ingress Controller for NGINX et de F5 Gateway Fabric for NGINX, qui font tous deux partie de F5 ADSP.
Éprouvé dans des millions de déploiements cloud natifs, F5 NGINX s’impose comme le choix naturel pour standardiser la gestion du trafic des applications et des API au sein des clusters. Que vos équipes utilisent les ressources Kubernetes Ingress ou la norme moderne Kubernetes Gateway API, y compris l’extension Gateway API Inference Extension pour les charges de travail d’IA, les solutions NGINX de F5 offrent des performances ultrarapides et une empreinte légère, adaptée aux besoins des développeurs.
En matière d’efficacité des ressources, les proxys concurrents voient leur empreinte mémoire exploser lorsqu’ils traitent des prompts d’IA à contexte long ou des charges utiles en streaming. À l’inverse, F5 Gateway Fabric for NGINX conserve une empreinte mémoire stable et prévisible, quelle que soit la taille des charges utiles.
Pour les entreprises qui migrent depuis le projet communautaire ingress-nginx désormais abandonné, F5 propose une solution bénéficiant d’un support professionnel et de garanties de niveau de service (SLA), avec une conversion automatisée des configurations, pour une transition sans difficulté.
Et la sécurité n’est pas ajoutée après coup. Les équipes peuvent intégrer les produits WAF de F5, la sécurité des API, l’authentification (OIDC, JWT), la limitation du débit et des garde-fous en temps réel pour les prompts et les réponses de l’IA directement dans leurs manifestes Kubernetes, afin de sécuriser le trafic des applications et des LLM au rythme du code.
Pour les architectes infrastructure et IA : isolation multicluster et trafic sortant
Un proxy léger au sein du cluster est idéal pour les équipes applicatives, mais les environnements d’entreprise à grande échelle, les opérateurs télécoms et les usines d’IA ont besoin d’une capacité de montée en charge de niveau opérateur, d’une isolation stricte des tenants et d’un contrôle bidirectionnel du trafic. C’est là qu’intervient F5 BIG-IP Next for Kubernetes.
Basé sur le micro-noyau de gestion du trafic (TMM) de F5, natif pour les conteneurs, et conçu pour s’exécuter sur des nœuds de travail standard ou être déporté sur des DPU NVIDIA BlueField-3, BIG-IP Next for Kubernetes intègre directement à Kubernetes un contrôle du trafic et une sécurité de niveau infrastructure.
La plupart des outils Kubernetes se concentrent uniquement sur le trafic entrant. BIG-IP Next for Kubernetes contrôle et sécurise à la fois le trafic entrant et le trafic sortant. À mesure que les microservices et les agents d’IA accèdent à des API externes, à des bases de données en amont, à des serveurs Model Context Protocol (MCP) et à des services interclusters, le trafic sortant non contrôlé devient un angle mort majeur en matière d’exfiltration de données. BIG-IP Next for Kubernetes impose un routage déterministe du trafic sortant, la traduction d’adresses réseau sources (SNAT), un filtrage pare-feu fondé sur les espaces de noms et une microsegmentation Zero Trust.
Pour les environnements multiclusters et multilocataires, BIG-IP Next for Kubernetes établit des sessions de peering directement avec les cœurs de réseau via BGP et accélère, sur les DPU, la gestion du trafic L4–L7, le déchargement des opérations cryptographiques mTLS et le routage des jetons tenant compte des préfixes. Résultat : une isolation stricte entre les locataires, des ressources CPU libérées sur les hôtes et une utilisation maximisée des GPU.
Réunir les équipes NetOps et plateforme
Que se passe-t-il donc lorsque l’équipe NetOps gère F5 BIG-IP en périphérie du réseau — assurant une protection contre les attaques DDoS au niveau matériel, la gestion globale du trafic et la conformité — tandis que l’équipe Plateforme exploite F5 Gateway Fabric for NGINX ou F5 Ingress Controller for NGINX au sein du cluster ?
F5 BIG-IP Container Ingress Services (CIS) connecte automatiquement leurs flux de travail.
En tant que connecteur automatisé natif de Kubernetes, BIG-IP CIS surveille les API Kubernetes et OpenShift, notamment les ressources Ingress, Gateway API, Routes et F5 IngressLink/GatewayLink, et programme dynamiquement les systèmes BIG-IP externes en temps réel.
Les développeurs restent dans Kubernetes et définissent le routage du trafic au sein du cluster, les paramètres TLS et les politiques L7 en YAML standard. NetOps conserve la gouvernance du périmètre, tandis que CIS détecte automatiquement les modifications du cluster et met à jour les serveurs virtuels, les membres des pools et le DNS/GTM multicluster sur le système BIG-IP externe, sans qu’il soit nécessaire de créer manuellement des tickets. Les deux équipes restent responsables de leurs domaines respectifs tout en partageant une télémétrie de bout en bout, de la VIP en périphérie jusqu’au pod, avec la possibilité de migrer vers BIG-IP Next for Kubernetes à mesure que les besoins évoluent.
Pour les équipes SecOps et les RSSI : des versions renforcées pour l’open source et les solutions d’entreprise
Il est essentiel de proposer à chaque profil une architecture de trafic adaptée, mais votre logiciel de plan de données doit également résister à des menaces qui évoluent à un rythme accéléré par l’IA.
Les chiffres parlent d’eux-mêmes. En 2018, les équipes de défense disposaient en moyenne de 771 jours après la divulgation d’une CVE avant qu’un exploit ne soit opérationnel. Aujourd’hui, les agents d’IA offensive peuvent rendre des vulnérabilités exploitables en quelques minutes, alors qu’une entreprise met encore en moyenne plusieurs semaines à déployer un correctif. Dans les dépôts open source publics, chaque commit de sécurité constitue en quelque sorte une feuille de route pour les attaquants ; les outils d’IA peuvent comparer les versions du code et générer des exploits plusieurs semaines avant que les distributions en aval ne reconstruisent les paquets.
F5 fournit des versions renforcées pour vous permettre de déployer vos solutions en toute confiance, tout en protégeant ses clients commerciaux et la communauté open source. F5 utilise en continu un dispositif interne de tests de sécurité fondé sur l’IA sur les bases de code de BIG-IP, BIG_IP Next for Kubernetes et NGINX afin de détecter et de corriger les vulnérabilités de manière proactive.
Des versions renforcées confidentielles sont distribuées aux clients commerciaux de NGINX Enterprise, BIG-IP et BIG-IP Next for Kubernetes sous forme de mises à jour ciblées, exclusivement consacrées à la sécurité, sans aucune modification fonctionnelle ni dépréciation d’API. Puis, environ six semaines plus tard — laissant ainsi aux entreprises une longueur d’avance pour appliquer les correctifs à leur infrastructure en toute sécurité — F5 publie son avis de sécurité et met simultanément à disposition les détails des CVE et les correctifs pour NGINX Open Source.
Comment tout s’articule : faire évoluer une plateforme GPU-as-a-service mutualisée
Pour comprendre comment ces éléments s’articulent concrètement, prenons l’exemple d’un récent déploiement réalisé par l’un des géants du commerce en ligne et de la logistique en Asie-Pacifique.
Après avoir exécuté pendant des années des charges de travail d’IA internes massives, l’entreprise a entrepris de lancer une offre cloud commerciale de GPU à la demande (GPU-as-a-Service, ou GPUaaS), reposant sur des clusters Kubernetes à grande échelle déployés sur site et équipés de systèmes NVIDIA DGX. La transformation de ces clusters internes en un cloud mutualisé a immédiatement posé trois défis.
Premièrement, les entreprises clientes externes devaient pouvoir accéder simultanément aux clusters partagés sans fuite de trafic entre les locataires. Deuxièmement, l’équipe en charge de la plateforme avait besoin d’un routage L7 cloud natif, de la terminaison TLS et de l’isolation des espaces de noms sur plus de 100 nœuds, sans avoir à soumettre manuellement des tickets réseau. Troisièmement, les contrôleurs open source communautaires n’offraient tout simplement pas la gestion robuste du trafic ni l’assistance 24 h/24 et 7 j/7 nécessaires pour garantir un accord de niveau de service (SLA) commercial.
L’entreprise a déployé une architecture de gestion du trafic Kubernetes à deux niveaux combinant F5 BIG-IP rSeries LTM, BIG-IP CIS et F5 Ingress Controller for NGINX sur 100 nœuds Kubernetes. En périphérie, les appliances BIG-IP rSeries assurent un équilibrage de charge L4 à haut débit et une isolation stricte des équilibreurs de charge virtuels — avec des vCPU, de la mémoire et des partitions de routage dédiés — en associant chaque domaine de locataire à une adresse IP virtuelle isolée selon une correspondance un à un.
Grâce à F5 IngressLink, BIG-IP CIS surveille l’API Kubernetes et associe automatiquement les serveurs virtuels BIG-IP externes aux pods NGINX du cluster, sans aucun ticket d’intervention manuelle. Au sein du cluster, les pods NGINX Ingress Controller dédiés à chaque locataire assurent la terminaison TLS, effectuent le déchiffrement et appliquent les règles de routage et d’authentification L7, en dirigeant le trafic vers l’espace de noms isolé et les ressources GPU de chaque locataire.
En offrant aux équipes NetOps une isolation matérielle BIG-IP en périphérie, en permettant à ses ingénieurs plateforme de bénéficier de l’agilité cloud-native de NGINX au sein du cluster et en reliant ces deux environnements avec BIG-IP CIS, l’entreprise a lancé sa plateforme GPUaaS dans les délais, tout en préparant une transition vers BIG-IP Next for Kubernetes à mesure que son usine d’IA monte en puissance.
Un contrôle du trafic et une sécurité adaptés aux méthodes de travail de vos équipes
Selon L’état des stratégies Kubernetes en entreprise en 2026, 24 % des entreprises sont freinées dans leur progression vers la maturité Kubernetes par une seule lacune, le plus souvent en matière d’observabilité ou de contrôle d’admission. L’écart entre un niveau « établi » et un niveau « adapté aux exigences de l’entreprise » ne tient pas à la plateforme. Il tient au contrôle du trafic, à la sécurité et à l’alignement des équipes.
F5 comble cette lacune pour tous les profils. Abandonnez le projet communautaire ingress-nginx, désormais retiré, en suivant un parcours de migration bénéficiant d’un support professionnel. Reliez automatiquement les workflows NetOps et ceux des équipes plateforme avec BIG-IP CIS. Contrôlez le trafic entrant et sortant des clusters d’IA mutualisés avec BIG-IP Next for Kubernetes. Et renforcez la sécurité de l’ensemble grâce à des versions exclusivement consacrées à la sécurité, disponibles plusieurs semaines avant la divulgation publique des CVE. Avec une architecture unifiée qui répond aux besoins des différentes équipes, F5 ADSP apporte aux entreprises la maturité opérationnelle nécessaire pour exploiter Kubernetes de manière sécurisée et efficace à grande échelle.
Envie d’aller plus loin ? Rendez-vous sur le stand F5 n° 100 à la KubeCon de Salt Lake City, du 9 au 12 novembre, pour échanger directement avec nos ingénieurs et résoudre vos problèmes de réseau Kubernetes, découvrir des démonstrations interactives, assister à des présentations pratiques et lever les obstacles qui freinent votre utilisation de Kubernetes.
Lisez notre article de blog « Pourquoi la plupart des entreprises n’ont pas encore atteint un niveau de sécurité adapté à leurs besoins ».
Pensez également à vous inscrire à notre webinaire intitulé « Ce qui distingue une stratégie Kubernetes de niveau entreprise des autres ».
À propos des auteurs
Articles de blog associés
F5 rejoint le projet PQC du NIST pour contribuer à l’élaboration de normes résistantes aux attaques quantiques
En rejoignant le consortium du projet « Migration to PQC » du NIST, F5 contribue à élaborer des recommandations pratiques pour un monde résistant aux menaces quantiques.
La dernière version de F5 Distributed Cloud Bot Defense offre des fonctionnalités et des améliorations de nouvelle génération
Les mises à jour de la console de F5 Distributed Cloud Bot Defense améliorent la gestion des menaces automatisées et l’intégration dans des cadres de sécurité plus larges.
La nouvelle surface de risque liée à l’IA : invisible, autonome et déjà à l’intérieur
James White, vice-président de l’ingénierie chez F5 À mi-parcours de l’année 2025, le moment est bien choisi pour dresser un état des lieux de l’adoption de l’IA en entreprise et de la sécurité de l’IA. L’utilisation de l’IA générative est désormais la norme dans les entreprises De manière générale, les entreprises possèdent au moins une compréhension élémentaire de l’IA générative. Elles savent ce qu’elle est et où elle peut […]
Évaluation des LLM : renforcer la confiance grâce à la notation de sécurité
À mesure que l’adoption de l’IA s’accélère dans les entreprises, l’évaluation des LLM ne porte plus uniquement sur leurs performances, mais aussi sur la confiance qu’ils inspirent. Les équipes de sécurité doivent évaluer non seulement les performances d’un modèle, mais aussi la sûreté de son comportement. Pourtant, la plupart des cadres d’évaluation se concentrent sur des critères de précision, laissant les facteurs de sécurité et de risque dans le flou ou sans mesure.
Évaluer le niveau de préparation de votre organisation à la sécurité de l’IA
Dans un paysage de l’intelligence artificielle (IA) en constante évolution, il est non seulement important, mais impératif de savoir si votre organisation est prête à instaurer et à soutenir une culture de la sécurité de l’IA. À mesure que les technologies d’IA progressent, elles font émerger une multitude de nouveaux défis de sécurité qui, pour être gérés efficacement, exigent une approche réfléchie, globale et proactive […]
Déployer des LLM en entreprise : via une API dans un cloud privé
Pris isolément, sans mesures de protection spécialisées ni protocoles de sécurité en place, le déploiement de modèles d’IA générative (GenAI), en particulier de grands modèles de langage (LLM), à l’échelle de l’entreprise représente pour toute organisation une opportunité à haut risque, mais potentiellement très rentable. La manière précise dont votre organisation doit franchir ce grand pas dans l’univers de la GenAI nécessite une planification mûrement réfléchie. Peut-être serait-il […]