Configuration de NGINX Plus comme équilibreur de charge externe pour Red Hat OCP et Kubernetes

Dans le monde de l’orchestration de conteneurs, il y a deux noms que nous rencontrons tout le temps : Plateforme de conteneurs RedHat OpenShift (OCP) et Kubernetes. OpenShift, comme vous le savez probablement, utilise Kubernetes en dessous, comme le font de nombreuses autres plateformes d'orchestration de conteneurs. Le routage du trafic externe vers un environnement Kubernetes ou OpenShift a toujours été un peu difficile, de deux manières :

• Exposer les services déployés dans Kubernetes au monde extérieur. La solution est un contrôleur Ingress comme NGINX Plus Ingress Controller . Vous pouvez en savoir plus à ce sujet dans notre blog Premiers pas avec NGINX Ingress Operator sur Red Hat OpenShift .
• Équilibrage de la charge du trafic sur vos nœuds Kubernetes. Pour résoudre ce problème, les organisations choisissent généralement un équilibreur de charge matériel ou virtuel externe ou une solution cloud native. Cependant, NGINX Plus peut également être utilisé comme équilibreur de charge externe, améliorant ainsi les performances et simplifiant votre investissement technologique.

Dans ce blog, je me concentre sur la façon de résoudre le deuxième problème en utilisant NGINX Plus d'une manière simple, efficace et qui permet à vos équipes de développement d'applications de gérer à la fois la configuration d'Ingress dans Kubernetes et la configuration de l'équilibreur de charge externe à l'extérieur. En tant qu'architecture de référence pour vous aider à démarrer, j'ai créé le projet nginx-lb-operator sur GitHub : l'opérateur d'équilibrage de charge NGINX ( NGINX-LB-Operator ) est un opérateur basé sur Ansible pour le contrôleur NGINX créé à l'aide de Red Hat Operator Framework et du SDK. NGINX-LB-Operator pilote l'API déclarative du contrôleur NGINX pour mettre à jour la configuration de l'équilibreur de charge externe NGINX Plus lorsque de nouveaux services sont ajoutés, que les pods changent ou que les déploiements évoluent au sein du cluster Kubernetes.

Veuillez noter que NGINX-LB-Operator n'est pas couvert par votre contrat d'assistance NGINX Plus ou NGINX Controller. Vous pouvez signaler des bugs ou demander une assistance de dépannage sur GitHub .

Technologies Kubernetes et NGINX – Un aperçu

NGINX-LB-Operator s'appuie sur un certain nombre de technologies Kubernetes et NGINX, je propose donc un aperçu rapide pour que nous soyons tous sur la même longueur d'onde. Si vous les connaissez déjà, n'hésitez pas à passer à L'opérateur d'équilibrage de charge NGINX .

Contrôleurs et opérateurs Kubernetes

Kubernetes est une plateforme d’orchestration conçue autour d’une API centrale faiblement couplée. Vous y trouverez un ensemble de définitions de ressources, ainsi que des contrôleurs (généralement exécutés sous forme de Pods dans la plateforme) pour superviser et gérer ces ressources. L’API Kubernetes est extensible : vous pouvez utiliser des opérateurs, un type de contrôleur, pour enrichir ses fonctionnalités.

• Contrôleurs – Un élément central du système Kubernetes. Ils créent des « observateurs » pour des ressources Kubernetes spécifiques et exécutent les actions nécessaires pour garantir l’état souhaité de chaque ressource au fil de ses changements. Lors des échanges avec vous, le contrôleur Kubernetes le plus fréquemment abordé est le « contrôleur Ingress ».
• Opérateurs – Contrôleurs personnalisés qui définissent et exploitent des définitions de ressources personnalisées (CRD) pour piloter les applications et leurs composants.

Contrôleurs d'entrée NGINX pour Kubernetes

Il existe deux principales options de contrôleur Ingress pour NGINX, et il peut être un peu difficile de les distinguer car les noms dans GitHub sont très similaires. Nous avons discuté de ce sujet en détail dans un blog précédent , mais voici un bref aperçu :

• kubernetes/ingress-nginx – Contrôleur Ingress soutenu et entretenu par la communauté Kubernetes du logiciel libre. Pour simplifier son usage, nous l’appelons le « contrôleur Ingress de la communauté ». Sans surprise, il repose sur NGINX Open Source. Il inclut des fonctionnalités supplémentaires activées par des modules Lua tiers, qui réduisent hélas souvent les performances.

• nginxinc/kubernetes-ingress – Le contrôleur Ingress maintenu par l'équipe NGINX chez F5. Il existe deux versions : une pour NGINX Open Source (conçue pour la vitesse) et une autre pour NGINX Plus (également conçue pour la vitesse, mais prise en charge commerciale et avec des fonctionnalités supplémentaires de niveau entreprise). Nous les appelons « contrôleurs d’entrée NGINX (ou nos) ».

  Vous pouvez gérer nos deux contrôleurs Ingress avec les ressources Ingress Kubernetes standard. Nous prenons aussi en charge les annotations et les ConfigMaps pour compléter la fonctionnalité limitée définie par la spécification Ingress, mais cette extension n’est pas idéale.

  Les versions 1.6.0 et suivantes de nos contrôleurs Ingress intègrent une meilleure solution : des ressources NGINX Ingress personnalisées appelées VirtualServer et VirtualServerRoute, qui étendent l’API Kubernetes tout en offrant des fonctionnalités supplémentaires, de manière native. Les ressources NGINX Ingress ouvrent l’accès à davantage de fonctionnalités NGINX et vous permettent d’utiliser des options avancées de répartition de charge avec Ingress, de déployer des mises à jour blue-green et canari, de mettre en place des patterns de disjoncteur, et bien plus encore.

Pour un résumé des principales différences entre ces trois options de contrôleur Ingress, consultez notre référentiel GitHub .

Contrôleur NGINX

NGINX Controller est notre plan de contrôle indépendant du cloud pour gérer vos instances NGINX Plus dans plusieurs environnements et exploiter des informations critiques sur les performances et les états d'erreur. Ses modules fournissent une gestion centralisée de la configuration pour la livraison des applications (équilibrage de charge) et la gestion des API . NGINX Controller peut gérer la configuration des instances NGINX Plus dans une multitude d'environnements : physiques, virtuels et cloud. Il est construit autour d’une API déclarative finalement cohérente et fournit une vue centrée sur l’application de vos applications et de leurs composants. Il est conçu pour s'interfacer facilement avec vos pipelines CI/CD, abstraire l'infrastructure du code et permettre aux développeurs de poursuivre leur travail.

Avec Kubernetes, NGINX Controller vous permet de gérer les instances NGINX Plus déployées en amont comme proxy inverse ou passerelle API. NGINX Controller ne gère pas directement le contrôleur Ingress NGINX Plus ; puisque ce contrôleur exécute la boucle de contrôle d’une ressource clé de Kubernetes (l’Ingress), vous devez le gérer via les outils de la plateforme Kubernetes – avec les ressources Ingress standard ou les ressources Ingress NGINX.

Équilibreurs de charge externes

Le contrôleur d'entrée NGINX Plus pour Kubernetes est un excellent moyen d'exposer les services de Kubernetes au monde extérieur, mais vous avez souvent besoin d'une couche d'équilibrage de charge externe pour gérer le trafic vers les nœuds ou les clusters Kubernetes. Si vous utilisez un cloud public, l'équilibreur de charge externe peut être NGINX Plus, F5 BIG-IP LTM Virtual Edition ou une solution cloud native. Si vous effectuez un déploiement sur site ou dans un cloud privé, vous pouvez utiliser NGINX Plus ou une appliance BIG-IP LTM (physique ou virtuelle). On me dit qu'il existe d'autres équilibreurs de charge disponibles, mais je n'y crois pas 😉 .

Lorsqu'il s'agit de gérer vos équilibreurs de charge externes, vous pouvez gérer les instances NGINX Plus externes à l'aide du contrôleur NGINX directement. Son API déclarative a été conçue dans le but de s'interfacer avec votre pipeline CI/CD, et vous pouvez déployer chacun des composants de votre application en l'utilisant. Mais que se passe-t-il si votre couche Ingress est évolutive, que vous utilisez des Kubernetes NodePorts attribués dynamiquement ou que vos routes OpenShift peuvent changer ?

Dans des cas comme ceux-ci, vous souhaiterez probablement fusionner la configuration de l'équilibreur de charge externe avec l'état de Kubernetes et piloter l'API du contrôleur NGINX via un opérateur Kubernetes. Le diagramme montre un exemple de déploiement qui inclut un tel opérateur ( NGINX-LB-Operator ) pour gérer l'équilibreur de charge externe et met en évidence les différences entre le contrôleur d'entrée NGINX Plus et le contrôleur NGINX.

où:

• Ressources Ingress (encadré bleu) – Nous définissons une ressource Ingress standard et une ressource NGINX VirtualServer dans l’espace de noms du projet.
• Flèches bleues – Vous créez des ressources Ingress dans l’API Kubernetes, que le contrôleur Ingress NGINX Plus détecte dans un namespace distinct.
• Ressources personnalisées (encadré vert) – Les ressources personnalisées, instanciations des CRD installées avec NGINX-LB-Operator, se définissent dans l’espace de noms de votre projet et sont exploitées par NGINX-LB-Operator qui s’exécute dans ce même espace.
• Flèches vertes – Vous créez les ressources dans l’API, puis NGINX-LB-Operator les récupère. À la différence du contrôleur Ingress qui configure une instance locale de NGINX Plus tournant dans le même Pod, NGINX-LB-Operator contacte directement via API le contrôleur NGINX.
• Flèches orange – Le contrôleur NGINX configure l’instance externe NGINX Plus pour équilibrer la charge sur le contrôleur d’entrée NGINX Plus.

Dans cette topologie, les ressources personnalisées définissent l’état souhaité de l’équilibreur de charge externe et désignent le contrôleur d’entrée NGINX Plus comme groupe de charge de travail en amont. NGINX-LB-Operator recueille les informations sur les pods Ingress, les combine avec l’état souhaité, puis les transmet à l’API du contrôleur NGINX.

L'opérateur d'équilibrage de charge NGINX

Écrire un opérateur pour Kubernetes peut vous sembler complexe au départ, mais Red Hat et la communauté open source de Kubernetes assurent la maintenance du Operator Framework, ce qui facilite grandement cette tâche. Le SDK Operator vous permet de créer un opérateur Kubernetes en utilisant Go, Ansible ou Helm. Chez F5, nous publions déjà des collections Ansible pour plusieurs de nos produits, notamment la collection certifiée pour NGINX Controller. Construire un opérateur pour gérer les instances externes de NGINX Plus et interagir avec NGINX Controller est donc simple et direct.

J'ai utilisé le SDK Operator pour créer l'opérateur d'équilibrage de charge NGINX, NGINX-LB-Operator , qui peut être déployé avec un espace de noms ou une portée de cluster et surveille une poignée de ressources personnalisées. Les ressources personnalisées sont directement mappées sur les objets NGINX Controller (Certificat, Passerelle, Application et Composant) et représentent ainsi le modèle centré sur l'application de NGINX Controller directement dans Kubernetes. Les ressources personnalisées configurées dans Kubernetes sont récupérées par NGINX-LB-Operator , qui crée ensuite des ressources équivalentes dans NGINX Controller.

NGINX-LB-Operator vous permet de gérer la configuration d'une instance NGINX Plus externe à l'aide de l'API déclarative de NGINX Controller. Étant donné que NGINX Controller gère l'instance externe, vous bénéficiez des avantages supplémentaires de la surveillance et des alertes, ainsi que des informations détaillées sur les applications fournies par NGINX Controller.

Ce diagramme illustre comment :

1. Vous créez des ressources personnalisées dans l'espace de noms du projet que vous envoyez à l'API Kubernetes.
2. NGINX-LB-Operator détecte les ressources nouvellement configurées et recueille l’état souhaité du composant ainsi que les informations de déploiement auprès du contrôleur Ingress dans l’espace de noms Ingress.
3. Une configuration fusionnée à partir de votre définition et de l’état actuel du contrôleur Ingress est envoyée au contrôleur NGINX.
4. La configuration est livrée aux instances NGINX Plus demandées et NGINX Controller commence à collecter des métriques pour la nouvelle application.

Des instructions de déploiement détaillées et un exemple d'application sont fournis sur GitHub . Si vous n'aimez pas le jeu de rôle ou si vous êtes venu ici pour la version TL;DR, rendez-vous-y maintenant.

Un exemple de déploiement

Alors jouons un rôle. Je serai Susan et tu pourras être Dave.

En tant que Dave, vous dirigez une branche d'activité dans votre conglomérat imaginaire préféré. Vous êtes à l’écoute des enfants, vous êtes à l’écoute des dernières nouvelles, etc. Vous déployez donc toutes vos applications et microservices sur OpenShift et, pour Ingress, vous utilisez le contrôleur Ingress NGINX Plus pour Kubernetes. Toutes vos applications sont déployées en tant que projets OpenShift (espaces de noms) et le contrôleur d’entrée NGINX Plus s’exécute dans son propre espace de noms d’entrée.

Vous n'avez jamais été satisfait des fonctionnalités disponibles dans la spécification Ingress par défaut et avez toujours trouvé ConfigMaps et Annotations un peu lourds. C’est pourquoi vous avez été ravi quand NGINX a annoncé que le contrôleur Ingress NGINX Plus prendrait en charge ses propres CRD. Aujourd’hui, vos développeurs d’application utilisent les ressources VirtualServer et VirtualServerRoutes pour déployer les applications sur le contrôleur Ingress NGINX Plus et configurer le routage interne ainsi que la gestion des erreurs dans OpenShift.

Parfois, vous exposez même des services non HTTP, grâce aux ressources personnalisées TransportServer accessibles avec le contrôleur Ingress NGINX Plus. Vous pouvez définir ces ressources personnalisées dans vos propres espaces de noms de projet ; le contrôleur Ingress NGINX Plus les détecte et les applique immédiatement. C’est impressionnant, mais vous aimeriez pouvoir gérer l’équilibreur de charge réseau externe au bord de votre cluster OpenShift avec autant de simplicité. À chaque fois que vous devez faire évoluer la couche Ingress, votre mal de dos revient systématiquement.

C'est samedi soir et tu devrais être en discothèque, mais hier tu as dû escalader à nouveau la couche Ingress et maintenant tu as mal au bas du dos. Ping! Dans un nuage de fumée, votre bonne fée marraine Susan apparaît.

« Bonjour, Dave », dit-elle.

"Qui es-tu? « Regarde ce que tu as fait à mon tapis persan », répondez-vous.

Sans se soucier de votre réaction, Susan vous parle de NGINX-LB-Operator, désormais accessible sur GitHub. Elle vous explique qu'avec un cluster NGINX Plus en edge computing OpenShift et le contrôleur NGINX pour le piloter selon la perspective centrée sur l’application, vous pouvez créer des ressources personnalisées qui définissent comment configurer l’équilibreur de charge NGINX Plus.

NGINX-LB-Operator surveille ces ressources et s'en sert pour envoyer la configuration centrée sur l’application vers NGINX Controller. NGINX Controller génère ensuite la configuration NGINX Plus nécessaire et la diffuse vers l’équilibreur de charge NGINX Plus externe.

Vos utilisateurs finaux bénéficient d’un accès immédiat à vos applications et vous avez le contrôle sur les modifications qui nécessitent une modification de l’équilibreur de charge externe NGINX Plus !

NGINX Controller collecte les métriques de l'équilibreur de charge externe NGINX Plus et vous les présente depuis la même perspective centrée sur les applications dont vous bénéficiez déjà. Et la prochaine fois que vous mettrez à l'échelle la couche d'entrée NGINX Plus, NGINX-LB-Operator mettra automatiquement à jour le contrôleur NGINX et l'équilibreur de charge NGINX Plus externe pour vous. Plus de mal de dos !

Conclusion

Kubernetes est une plateforme conçue pour gérer les applications conteneurisées. NGINX Controller fournit un modèle centré sur l’application pour réfléchir et gérer l’équilibrage de la charge des applications. NGINX-LB-Operator combine les deux et vous permet de gérer la pile complète de bout en bout sans avoir à vous soucier d'une quelconque infrastructure sous-jacente. Rendez-vous sur GitHub pour plus d’informations techniques sur NGINX-LB-Operator et une présentation complète d’un exemple.

En savoir plus sur nos solutions :

• Demandez un essai gratuit de NGINX Controller
• Contactez-nous pour discuter de vos cas d'utilisation
• Obtenez l' opérateur d'entrée NGINX pour OpenShift
• Inscrivez-vous à un cours dirigé par un instructeur