La création et la gestion d’un environnement Kubernetes robuste exigent une collaboration fluide entre vos équipes Réseau et Applications. Cependant, leurs priorités et leurs méthodes de travail sont généralement très différentes, ce qui peut entraîner des conflits aux conséquences potentiellement graves : ralentissement du développement des applications, retards de déploiement, voire interruptions du réseau.
Seule la réussite des deux équipes, œuvrant à un objectif commun, peut garantir que les applications modernes d’aujourd’hui sont livrées dans les délais, avec un niveau de sécurité et une évolutivité adéquats. Alors, comment tirer parti des compétences et de l’expertise de chaque équipe, tout en les aidant à travailler de concert ?
Dans notre livre blanc « Get Me to the Cluster », nous présentons en détail une solution permettant l’accès externe aux services Kubernetes, afin que les équipes Réseau et Applications puissent conjuguer leurs forces sans conflit.
Comment exposer des applications dans des clusters Kubernetes
La solution fonctionne spécifiquement pour les clusters Kubernetes hébergés sur site, dont les nœuds s’exécutent sur des serveurs physiques ou des machines virtuelles (VM) Linux traditionnelles, et dont les communications au sein du centre de données reposent sur des commutateurs standard de couche 2 et des routeurs de couche 3. Elle ne s’applique pas aux clusters Kubernetes hébergés dans le cloud, car les fournisseurs de cloud ne nous permettent de contrôler ni le réseau principal de leurs centres de données ni celui de leur environnement Kubernetes géré.
Avant d’entrer dans les détails de notre solution, voyons pourquoi les autres méthodes standard permettant d’exposer des applications dans un cluster Kubernetes ne conviennent pas aux déploiements sur site :
- Service – Regroupe les pods exécutant les mêmes applications. Cette solution est idéale pour la communication interne entre pods, mais elle n’est visible qu’au sein du cluster et ne permet donc pas d’exposer les applications à l’extérieur.
- NodePort – Ouvre un port spécifique sur chaque nœud du cluster et redirige le trafic vers l’application correspondante. Bien que cela permette aux utilisateurs externes d’accéder au service, cette solution n’est pas idéale, car la configuration est statique et vous devez utiliser des ports TCP à numéro élevé (au lieu de ports à numéro inférieur bien connus), ainsi que coordonner les numéros de port avec les autres applications. Vous ne pouvez pas non plus partager des ports TCP communs entre différentes applications.
- LoadBalancer – Utilise les définitions NodePort de chaque nœud pour créer un chemin réseau entre le monde extérieur et vos nœuds Kubernetes. Cette solution est idéale pour Kubernetes hébergé dans le cloud, car AWS, Google Cloud Platform, Microsoft Azure et la plupart des autres fournisseurs de cloud la prennent en charge sous la forme d’une fonctionnalité facile à configurer, efficace et fournissant l’adresse IP publique requise ainsi que l’enregistrement DNS
Acorrespondant pour un service. Malheureusement, il n’existe pas d’équivalent pour les clusters sur site.
Activation de l’accès des utilisateurs externes aux clusters Kubernetes sur site
Il nous reste donc l’objet Ingress de Kubernetes, spécialement conçu pour le trafic allant des utilisateurs situés à l’extérieur du cluster vers les pods à l’intérieur de celui-ci (trafic nord-sud). L’Ingress crée un point d’entrée HTTP/HTTPS externe pour le cluster : une adresse IP ou un nom DNS unique permettant aux utilisateurs externes d’accéder à plusieurs services. C’est exactement ce qu’il nous faut ! L’objet Ingress est mis en œuvre par un contrôleur Ingress ; dans notre solution, il s’agit de F5 NGINX Ingress Controller, une solution de niveau entreprise basée sur NGINX Plus.
Vous serez peut-être surpris d’apprendre qu’un autre composant clé de la solution est le protocole Border Gateway Protocol (BGP), un protocole de routage de couche 3. Mais une excellente solution n’a pas besoin d’être complexe !
La solution présentée dans « Get Me to the Cluster » comporte en réalité quatre composants :
- Réseau iBGP – Le protocole BGP interne (iBGP) est utilisé pour échanger des informations de routage au sein d’un système autonome (AS) dans le centre de données et contribue à garantir la fiabilité et l’évolutivité du réseau. iBGP est déjà déployé et pris en charge par l’équipe Réseau dans la plupart des centres de données.
- Mise en réseau CNI avec Project Calico – Project Calico est une solution de mise en réseau open source qui permet de connecter avec souplesse les environnements des centres de données sur site, tout en offrant un contrôle précis des flux de trafic. Nous utilisons le plug-in CNI de Project Calico pour la mise en réseau du cluster Kubernetes, avec BGP activé. Vous pouvez ainsi contrôler les pools d’adresses IP alloués aux pods, ce qui permet d’identifier rapidement les éventuels problèmes de réseau.
- NGINX Ingress Controller basé sur NGINX Plus – Avec NGINX Ingress Controller, vous pouvez surveiller les adresses IP des points de terminaison de service des pods et reconfigurer automatiquement la liste des services en amont sans interrompre le traitement du trafic. Les équipes chargées des applications peuvent également tirer parti des nombreuses autres fonctionnalités HTTP de couche 7 de niveau entreprise de NGINX Plus, notamment les contrôles d’intégrité actifs, le mTLS et l’authentification basée sur JWT.
- NGINX Plus en tant que proxy inverse en périphérie – NGINX Plus fait office de proxy inverse en périphérie du cluster Kubernetes, assurant la liaison entre les commutateurs et les routeurs du centre de données et le réseau interne du cluster Kubernetes. Cette solution remplace l’objet LoadBalancer de Kubernetes et utilise Quagga pour le protocole BGP.
Le schéma illustre l’architecture de la solution et indique les protocoles utilisés par ses composants pour communiquer, et non l’ordre dans lequel les données sont échangées lors du traitement des requêtes.
Téléchargez gratuitement le livre blanc
En collaborant à la mise en œuvre d’une solution composée d’éléments clairement définis, les équipes Réseau et Applications peuvent facilement garantir des performances et une fiabilité optimales.
Notre solution s’appuie sur des outils et protocoles réseau modernes ainsi que sur les architectures existantes. Conçue pour être économique et facile à déployer, à gérer et à prendre en charge, elle simplifie les opérations et favorise la collaboration entre vos équipes.
Pour voir le code en action et découvrir étape par étape comment déployer notre solution, téléchargez gratuitement Get Me to the Cluster for free.
À 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.