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 construite autour d'une API centrale faiblement couplée. L'API fournit un ensemble de définitions de ressources, ainsi que des contrôleurs (qui s'exécutent généralement sous forme de pods au sein de la plateforme) pour surveiller et gérer ces ressources. L'API Kubernetes est extensible et les opérateurs (un type de contrôleur) peuvent être utilisés pour étendre les fonctionnalités de Kubernetes.

• Contrôleurs – Un élément essentiel du système Kubernetes. Ils créent des « surveillances » pour des ressources Kubernetes spécifiques et exécutent les étapes nécessaires pour atteindre l’état souhaité de chaque ressource à mesure qu’elle évolue. Dans les conversations avec les clients, le contrôleur Kubernetes le plus souvent évoqué est le « contrôleur d’entrée ».
• Opérateurs – Contrôleurs personnalisés qui définissent et utilisent des définitions de ressources personnalisées (CRD) pour gérer 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 – Le contrôleur Ingress pris en charge et maintenu par la communauté open source Kubernetes. Pour faciliter son utilisation, nous l'appelons le « contrôleur d'entrée de la communauté ». Sans surprise, il est basé sur NGINX Open Source. Il fournit des fonctionnalités supplémentaires activées par des modules Lua tiers, qui malheureusement ont tendance à nuire aux 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 à l'aide des ressources Ingress Kubernetes standard. Nous prenons également en charge les annotations et les ConfigMaps pour étendre les fonctionnalités limitées fournies par la spécification Ingress, mais étendre les ressources de cette manière n'est pas idéal.

  La version 1.6.0 et les versions ultérieures de nos contrôleurs Ingress incluent une meilleure solution : des ressources Ingress NGINX personnalisées appelées VirtualServer et VirtualServerRoute qui étendent l'API Kubernetes et fournissent des fonctionnalités supplémentaires de manière native Kubernetes. Les ressources NGINX Ingress exposent davantage de fonctionnalités NGINX et vous permettent d'utiliser des fonctionnalités avancées d'équilibrage de charge avec Ingress, d'implémenter des versions bleu-vert et canari et des modèles 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.

En ce qui concerne Kubernetes, NGINX Controller peut gérer les instances NGINX Plus déployées en amont en tant que proxy inverse ou passerelle API. Il n’est toutefois pas logique que NGINX Controller gère lui-même le contrôleur d’entrée NGINX Plus. Étant donné que le contrôleur d’entrée exécute la fonction de boucle de contrôle pour une ressource Kubernetes principale (l’entrée), il doit être géré à l’aide d’outils de la plateforme Kubernetes, soit des ressources d’entrée standard, soit des ressources d’entrée 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 (boîte bleue) – Une ressource Ingress standard et une ressource NGINX VirtualServer sont définies dans l’espace de noms du projet.
• Flèches bleues : les ressources d’entrée sont créées dans l’API Kubernetes et récupérées par le contrôleur d’entrée NGINX Plus qui s’exécute dans un espace de noms différent.
• Ressources personnalisées (case verte) – Les ressources personnalisées, qui sont des instanciations de CRD installés avec NGINX-LB-Operator , sont définies dans l'espace de noms de votre projet et consommées par NGINX-LB-Operator exécuté dans le même espace de noms.
• Flèches vertes – Les ressources sont créées dans l’API puis récupérées par NGINX-LB-Operator . Contrairement au contrôleur Ingress qui configure une instance NGINX Plus locale exécutée dans le même pod, NGINX-LB-Operator effectue un appel API au 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 contiennent l’état souhaité de l’équilibreur de charge externe et définissent le groupe de charge de travail en amont comme étant le contrôleur d’entrée NGINX Plus. NGINX-LB-Operator collecte des informations sur les pods Ingress et fusionne ces informations avec l'état souhaité avant de les envoyer à l'API du contrôleur NGINX.

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

Écrire un opérateur pour Kubernetes peut sembler une tâche ardue au début, mais Red Hat et la communauté open source Kubernetes maintiennent l' Operator Framework , ce qui rend la tâche relativement facile. Le SDK Operator permet à quiconque de créer un opérateur Kubernetes à l'aide de Go, Ansible ou Helm. Chez F5, nous publions déjà des collections Ansible pour plusieurs de nos produits, y compris la collection certifiée pour NGINX Controller . La création d'un opérateur pour gérer les instances NGINX Plus externes et l'interface avec NGINX Controller est donc assez simple.

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 qui sont envoyées à l’API Kubernetes.
2. L'opérateur NGINX-LB voit les ressources nouvellement configurées et collecte l'état souhaité du composant et les informations de déploiement 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 pensé que ConfigMaps et Annotations étaient un peu maladroits. C'est pourquoi vous étiez aux anges lorsque NGINX a annoncé que le contrôleur d'entrée NGINX Plus allait commencer à prendre en charge ses propres CRD. Aujourd'hui, vos développeurs d'applications utilisent les ressources VirtualServer et VirtualServerRoutes pour gérer le déploiement d'applications sur le contrôleur d'entrée NGINX Plus et pour configurer le routage interne et la gestion des erreurs dans OpenShift.

Parfois, vous exposez même des services non HTTP, tout cela grâce aux ressources personnalisées TransportServer également disponibles avec le contrôleur d’entrée NGINX Plus. Les développeurs peuvent définir les ressources personnalisées dans leurs propres espaces de noms de projet qui sont ensuite récupérées par NGINX Plus Ingress Controller et immédiatement appliquées. C'est génial, mais vous aimeriez qu'il soit possible de gérer l'équilibreur de charge réseau externe à la périphérie de votre cluster OpenShift aussi facilement. Les moments où vous devez mettre à l'échelle la couche Ingress provoquent toujours des douleurs dans votre lumbago.

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.

Ignorant votre attitude, Susan continue de vous parler de NGINX-LB-Operator, désormais disponible sur GitHub. Elle explique qu'avec un cluster NGINX Plus à la périphérie d'OpenShift et NGINX Controller pour le gérer d'un point de vue centrée sur l'application, vous pouvez créer des ressources personnalisées qui définissent comment configurer l'équilibreur de charge NGINX Plus.

L' opérateur NGINX-LB surveille ces ressources et les utilise pour envoyer la configuration centrée sur l'application au contrôleur NGINX. À son tour, NGINX Controller génère la configuration NGINX Plus requise et la transmet à 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