Vous êtes un développeur d’applications modernes. Vous utilisez un ensemble d’outils open source, et éventuellement quelques outils commerciaux, pour écrire, tester, déployer et gérer de nouvelles applications et de nouveaux conteneurs. Vous avez choisi Kubernetes pour exécuter ces conteneurs et pods dans des environnements de développement, de test, de préproduction et de production. Vous avez adopté les architectures et les concepts des microservices, de la Cloud Native Computing Foundation, ainsi que d’autres normes modernes du secteur.
Au fil de cette aventure, vous avez découvert que Kubernetes est effectivement puissant. Mais vous avez probablement aussi été surpris de constater à quel point il peut être complexe, rigide et frustrant. La mise en œuvre et la coordination des modifications et des mises à jour apportées aux routeurs, pare-feu, équilibreurs de charge et autres équipements réseau peuvent devenir insurmontables, surtout dans votre propre centre de données ! De quoi faire pleurer un développeur.
La manière dont vous relevez ces défis dépend en grande partie de l’endroit et de la façon dont vous exécutez Kubernetes (en tant que service géré ou sur site). Cet article aborde l’équilibrage de charge TCP, un domaine clé dans lequel les choix de déploiement ont une incidence sur la facilité d’utilisation.
Équilibrage de charge TCP avec Kubernetes managé (autrement dit, l’option la plus simple)
Si vous utilisez un service géré, tel que celui d’un fournisseur de cloud public, pour Kubernetes, une grande partie de ces fastidieuses tâches de mise en réseau est prise en charge pour vous. Une seule commande (kubectl apply -f loadbalancer.yaml) suffit pour que le Service de type LoadBalancer vous fournisse une adresse IP publique, un enregistrement DNS et un équilibreur de charge TCP. Par exemple, vous pouvez configurer Amazon Elastic Load Balancer pour répartir le trafic entre les pods contenant NGINX Ingress Controller et, grâce à cette commande, ne plus avoir à vous soucier des changements de backends. C’est tellement simple que vous n’y prêtez probablement même plus attention !
Équilibrage de charge TCP avec Kubernetes sur site (autrement dit, l’option difficile)
Avec les clusters sur site, la situation est totalement différente. Vous ou vos collègues chargés du réseau devez fournir les composants réseau nécessaires. Vous vous demandez peut-être : « Pourquoi est-il si difficile de permettre aux utilisateurs d’accéder à mes applications Kubernetes ? » La réponse est simple, mais quelque peu surprenante : le Service de type LoadBalancer, qui constitue la porte d’entrée de votre cluster, n’existe pas réellement.
Pour exposer vos applications et vos Services à l’extérieur du cluster, votre équipe réseau exige probablement des tickets, des approbations, des procédures, voire des audits de sécurité, avant même de reconfigurer ses équipements. À moins que vous ne deviez tout faire vous-même, ce qui ralentit considérablement la livraison des applications. Pire encore, vous n’osez modifier aucun Service Kubernetes, car si le NodePort change, le trafic risque d’être bloqué ! Et nous savons tous à quel point les utilisateurs apprécient les erreurs 500. Votre responsable les apprécie probablement encore moins.
Une meilleure solution d’équilibrage de charge TCP sur site : NGINX Loadbalancer pour Kubernetes
Grâce à notre nouveau projet, vous pouvez transformer l’« option difficile » en « option facile » : NGINX Loadbalancer for Kubernetes. Ce projet gratuit est un contrôleur Kubernetes qui surveille NGINX Ingress Controller et met automatiquement à jour une instance externe de NGINX Plus configurée pour l’équilibrage de charge. Sa conception très simple facilite son installation et son exploitation. Cette solution vous permet de mettre en œuvre l’équilibrage de charge TCP dans les environnements sur site, afin que les nouvelles applications et les nouveaux services soient immédiatement détectés et puissent recevoir du trafic, sans aucune intervention manuelle.
Architecture et flux
NGINX Loadbalancer for Kubernetes réside au sein d’un cluster Kubernetes. Il est enregistré auprès de Kubernetes afin de surveiller le service nginx-ingress (NGINX Ingress Controller). Lorsqu’une modification est apportée aux backends, NGINX Loadbalancer for Kubernetes collecte les adresses IP des workers et les numéros de port TCP NodePort, puis envoie les paires IP:port à NGINX Plus via l’API NGINX Plus. Les serveurs upstream NGINX sont mis à jour sans nécessiter de rechargement, et NGINX Plus répartit le trafic entre les serveurs upstream et les NodePorts Kubernetes appropriés. Des instances NGINX Plus supplémentaires peuvent être ajoutées afin d’assurer une haute disponibilité.
Aperçu de NGINX Loadbalancer pour Kubernetes en action
Dans la capture d’écran ci-dessous, deux fenêtres montrent NGINX Loadbalancer for Kubernetes déployé et en fonctionnement :
- Type de service – LoadBalancer (pour «
nginx-ingress») - IP externe – Se connecte aux serveurs NGINX Plus
- Ports – NodePort associe le port 443 au port 30158, avec les serveurs en amont NGINX correspondants (comme indiqué dans le tableau de bord en temps réel)
- Journaux – Indique que l’équilibreur de charge NGINX pour Kubernetes envoie correctement des données à NGINX Plus
Remarque: dans cet exemple, les nœuds de travail Kubernetes sont 10.1.1.8 et 10.1.1.10
Commencez dès aujourd’hui
Si les problèmes de réseau à la périphérie de votre cluster Kubernetes vous agacent, essayez le projet et dites-nous ce que vous en pensez. Le code source de NGINX Loadbalancer for Kubernetes est open source (sous licence Apache 2.0) et toutes les instructions d’installation sont disponibles sur GitHub.
Pour nous faire part de vos commentaires, laissez-nous un message dans le dépôt ou contactez-nous sur le Slack de la communauté NGINX.
À 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.