BLOG | NGINX

Emmenez-moi au cluster… avec BGP ?

NGINX-Partie-de-F5-horiz-black-type-RGB
Miniature de Chris Akker
Chris Akker
Publié le 28 février 2023

La création et la gestion d’un environnement Kubernetes robuste exigent une collaboration fluide entre vos équipes réseau et application. Mais leurs priorités et leurs styles de travail sont généralement très différents, ce qui entraîne des conflits aux conséquences potentiellement graves : développement lent des applications, déploiement retardé et même temps d’arrêt du réseau.

Seul le succès des deux équipes, travaillant vers un objectif commun, peut garantir que les applications modernes d'aujourd'hui soient livrées à temps avec une sécurité et une évolutivité appropriées. Alors, comment tirer parti des compétences et de l’expertise de chaque équipe, tout en les aidant à travailler en tandem ?

Dans notre livre blanc Get Me to the Cluster , nous détaillons une solution permettant l'accès externe aux services Kubernetes qui permet aux équipes réseau et application de combiner 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 , avec des nœuds exécutés sur des machines virtuelles Linux (VM) bare metal ou traditionnelles et des commutateurs de couche 2 standard et des routeurs de couche 3 fournissant la mise en réseau pour la communication dans le centre de données. Cela ne s’étend pas aux clusters Kubernetes hébergés dans le cloud, car les fournisseurs de cloud ne nous permettent pas de contrôler le réseau principal de leurs centres de données ni le réseau de leur environnement Kubernetes géré.

Diagramme des clusters Kubernetes hébergés sur site, avec des nœuds et des commutateurs de couche 2 standard et des routeurs de couche 3 fournissant la mise en réseau pour la communication dans le centre de données.

Avant d’examiner les spécificités de notre solution, examinons pourquoi d’autres méthodes standard pour exposer des applications dans un cluster Kubernetes ne fonctionnent pas pour les déploiements sur site :

  • Service – Regroupe les pods exécutant les mêmes applications. Ceci est idéal pour la communication interne de pod à pod , mais n'est visible qu'à l'intérieur du cluster, donc cela n'aide pas à exposer les applications en externe.
  • NodePort – Ouvre un port spécifique sur chaque nœud du cluster et transfère le trafic vers l'application correspondante. Bien que cela permette aux utilisateurs externes d'accéder au service, ce n'est pas idéal car la configuration est statique et vous devez utiliser des ports TCP à numéro élevé (au lieu de numéros de port inférieurs bien connus) et coordonner les numéros de port avec d'autres applications. Vous ne pouvez pas non plus partager des ports TCP communs entre différentes applications.
  • LoadBalancer – Utilise les définitions NodePort sur chaque nœud pour créer un chemin réseau depuis le monde extérieur vers vos nœuds Kubernetes. Il est idéal pour Kubernetes hébergé dans le cloud, car AWS, Google Cloud Platform, Microsoft Azure et la plupart des autres fournisseurs de cloud le prennent en charge en tant que fonctionnalité facile à configurer qui fonctionne bien et fournit l'adresse IP publique requise et l'enregistrement DNS A correspondant 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

Cela nous laisse avec l’ objet Kubernetes Ingress , qui est spécifiquement conçu pour le trafic qui circule des utilisateurs extérieurs au cluster vers les pods à l’intérieur du cluster (trafic nord-sud). L'entrée crée un point d'entrée HTTP/HTTPS externe pour le cluster : une adresse IP unique ou un nom DNS auquel les utilisateurs externes peuvent accéder à plusieurs services. C'est exactement ce qu'il faut ! L'objet Ingress est implémenté par un contrôleur Ingress : dans notre solution, le contrôleur Ingress F5 NGINX de niveau entreprise basé sur NGINX Plus .

Vous serez peut-être surpris d’apprendre qu’un autre composant clé de la solution est le Border Gateway Protocol (BGP), un protocole de routage de couche 3. Mais une bonne solution n’a pas besoin d’être complexe !

La solution décrite dans Get Me to the Cluster comporte en fait quatre composants :

  1. 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à en place et pris en charge par l'équipe réseau dans la plupart des centres de données.
  2. Mise en réseau Project Calico CNIProject Calico est une solution de mise en réseau open source qui connecte de manière flexible les environnements dans les centres de données sur site tout en offrant un contrôle précis sur le flux de trafic. Nous utilisons le plug-in CNI de Project Calico pour la mise en réseau dans le cluster Kubernetes, avec BGP activé. Cela vous permet de contrôler les pools d'adresses IP alloués aux pods, ce qui permet d'identifier rapidement tout problème de réseau.
  3. 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 interruption du traitement du trafic. Les équipes d’application peuvent également profiter des nombreuses autres fonctionnalités HTTP de couche 7 de niveau entreprise de NGINX Plus, notamment les contrôles de santé actifs, mTLS et l’authentification basée sur JWT.
  4. NGINX Plus comme proxy inverse en périphérie – NGINX Plus se place comme un proxy inverse en périphérie du cluster Kubernetes, fournissant un chemin entre les commutateurs et les routeurs du centre de données et le réseau interne du cluster Kubernetes. Cela fonctionne comme remplacement de l'objet Kubernetes LoadBalancer et utilise Quagga pour BGP.

Le diagramme illustre l'architecture de la solution, indiquant les protocoles utilisés par les composants de la solution pour communiquer, et non l'ordre dans lequel les données sont échangées pendant le traitement des demandes.

Diagramme illustrant l'architecture de la solution, indiquant les protocoles utilisés par les composants de la solution pour communiquer

Téléchargez le livre blanc gratuitement

En travaillant ensemble pour mettre en œuvre une solution avec des composants bien définis, les équipes réseau et application peuvent facilement fournir des performances et une fiabilité optimales.

Notre solution utilise des outils de mise en réseau, des protocoles et des architectures existantes modernes. Parce qu'il est conçu pour être peu coûteux et facile à mettre en œuvre, à gérer et à prendre en charge, il ajoute de la simplicité et construit des ponts entre vos équipes.

Pour voir le code en action et apprendre étape par étape comment déployer notre solution, téléchargez gratuitement Get Me to the Cluster .


« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."