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.
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é.
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 :
A
correspondant pour un service. Malheureusement, il n’existe pas d’équivalent pour les clusters 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 :
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.
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."