Configuration de NGINX Plus en tant qu'équilibreur de charge externe pour Red Hat OCP et Kubernetes

Mark Boddington

Dans le monde de l’orchestration de conteneurs, deux noms reviennent constamment : RedHat OpenShift Container Platform (OCP) et Kubernetes. Comme vous le savez probablement, OpenShift s’appuie sur Kubernetes, tout comme de nombreuses autres plateformes d’orchestration de conteneurs. L’acheminement du trafic externe vers un environnement Kubernetes ou OpenShift a toujours posé quelques difficultés, à deux égards :

• Exposer au monde extérieur les services déployés dans Kubernetes. La solution consiste à utiliser un contrôleur Ingress tel que le contrôleur Ingress NGINX Plus. Pour en savoir plus, consultez notre article de blog Bien démarrer avec l’opérateur Ingress NGINX sur Red Hat OpenShift.
• Répartition de la charge du trafic entre vos nœuds Kubernetes. Pour résoudre ce problème, les entreprises optent généralement pour un équilibreur de charge externe matériel ou virtuel, ou pour une solution cloud native. Cependant, NGINX Plus peut également être utilisé comme équilibreur de charge externe, afin d’améliorer les performances et de simplifier vos investissements technologiques.

Dans cet article, je me concentre sur la résolution du deuxième problème à l’aide de NGINX Plus, de manière simple et efficace, tout en permettant à vos équipes de développement d’applications de gérer à la fois la configuration Ingress au sein de Kubernetes et celle de l’équilibreur de charge externe. Afin de vous proposer une architecture de référence pour vous aider à démarrer, j’ai créé le projet nginx-lb-operator sur GitHub : le NGINX Load Balancer Operator (NGINX-LB-Operator) est un opérateur basé sur Ansible pour NGINX Controller, créé à l’aide du Red Hat Operator Framework et de son SDK. NGINX-LB-Operator utilise l’API déclarative de NGINX Controller 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 sont mis à l’échelle au sein du cluster Kubernetes.

Veuillez noter que NGINX-LB-Operator n’est pas couvert par votre contrat de support NGINX Plus ou NGINX Controller. Vous pouvez signaler des bogues ou demander de l’aide au dépannage sur GitHub.

Kubernetes et les technologies NGINX – Récapitulatif

NGINX-LB-Operator s’appuie sur plusieurs technologies Kubernetes et NGINX. Je vous propose donc un bref rappel afin que nous partions tous sur les mêmes bases. Si vous les connaissez déjà, vous pouvez passer directement à la section « L’opérateur d’équilibrage de charge NGINX ».

Contrôleurs et opérateurs Kubernetes

Kubernetes est une plateforme d’orchestration reposant sur une API centrale faiblement couplée. Cette 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) chargés de surveiller et de gérer ces ressources. L’API Kubernetes est extensible, et des opérateurs (un type de contrôleur) peuvent être utilisés pour étendre les fonctionnalités de Kubernetes.

• Contrôleurs – Un composant essentiel du système Kubernetes. Ils mettent en place des « mécanismes de surveillance » pour des ressources Kubernetes spécifiques et effectuent les opérations nécessaires pour atteindre l’état souhaité de chaque ressource à mesure qu’elle évolue. Lors des échanges avec les clients, le contrôleur Kubernetes le plus souvent évoqué est le « contrôleur Ingress ».
• 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 Ingress 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 leurs noms sur GitHub sont très similaires. Nous avons abordé ce sujet en détail dans un précédent article de blog, mais voici un bref récapitulatif :

• kubernetes/ingress-nginx – Le contrôleur Ingress pris en charge et maintenu par la communauté open source Kubernetes. Par souci de simplicité, nous l’appelons le « contrôleur Ingress de la communauté ». Sans surprise, il repose sur NGINX Open Source. Il offre des fonctionnalités supplémentaires activées par des modules Lua tiers, qui ont malheureusement tendance à nuire aux performances.
• nginxinc/kubernetes-ingress – Le contrôleur Ingress maintenu par l’équipe NGINX de F5. Il existe deux versions : l’une pour NGINX Open Source (conçue pour la rapidité) et l’autre pour NGINX Plus (également conçue pour la rapidité, mais bénéficiant d’un support commercial et de fonctionnalités supplémentaires adaptées aux entreprises). Nous les appelons les « contrôleurs Ingress NGINX (ou nos contrôleurs Ingress) ». Vous pouvez gérer nos deux contrôleurs Ingress à l’aide de ressources Ingress Kubernetes standard. Nous prenons également en charge les annotations et les ConfigMaps afin d’étendre les fonctionnalités limitées offertes par la spécification Ingress, mais cette méthode d’extension des ressources n’est pas idéale.La version 1.6.0 et les versions ultérieures de nos contrôleurs Ingress proposent une meilleure solution : des ressources Ingress NGINX personnalisées appelées VirtualServer et VirtualServerRoute, qui étendent l’API Kubernetes et offrent des fonctionnalités supplémentaires de manière native dans Kubernetes. Les ressources Ingress NGINX donnent accès à davantage de fonctionnalités NGINX et vous permettent d’utiliser des fonctions avancées d’équilibrage de charge avec Ingress, de mettre en œuvre des déploiements bleu-vert et canary, 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 dépôt GitHub.

Contrôleur NGINX

NGINX Controller est notre plan de contrôle indépendant du cloud qui permet de gérer vos instances NGINX Plus dans plusieurs environnements et d’exploiter des informations essentielles sur les performances et les états d’erreur. Ses modules assurent une gestion centralisée de la configuration pour la distribution d’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 repose sur une API déclarative à cohérence à terme et offre une vue centrée sur vos applications et leurs composants. Il est conçu pour s’intégrer facilement à vos pipelines CI/CD, dissocier l’infrastructure du code et permettre aux développeurs de se concentrer sur leur travail.

En ce qui concerne Kubernetes, NGINX Controller peut gérer les instances NGINX Plus déployées en frontal en tant que proxy inverse ou passerelle d’API. Toutefois, il n’est pas pertinent que NGINX Controller gère le contrôleur Ingress NGINX Plus lui-même. En effet, comme le contrôleur Ingress assure la fonction de boucle de contrôle pour une ressource Kubernetes essentielle (Ingress), il doit être géré à l’aide des outils de la plateforme Kubernetes, soit des ressources Ingress standard, soit des ressources Ingress NGINX.

Équilibreurs de charge externes

Le contrôleur Ingress NGINX Plus pour Kubernetes est un excellent moyen d’exposer au monde extérieur les services exécutés dans Kubernetes, mais une couche d’équilibrage de charge externe est souvent nécessaire pour gérer le trafic entrant 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, mais je n’y crois pas 😉 .

Pour gérer vos équilibreurs de charge externes, vous pouvez administrer directement les instances NGINX Plus externes à l’aide de NGINX Controller. Son API déclarative a été conçue pour s’interfacer avec votre pipeline CI/CD et vous permettre de déployer chacun des composants de votre application. Mais que se passe-t-il si votre couche Ingress est évolutive, si vous utilisez des NodePorts Kubernetes attribués dynamiquement ou si vos routes OpenShift sont susceptibles de changer ?

Dans de tels cas, vous souhaiterez probablement combiner la configuration de l’équilibreur de charge externe avec l’état de Kubernetes et piloter l’API de NGINX Controller par l’intermédiaire d’un opérateur Kubernetes. Le schéma présente un exemple de déploiement qui inclut précisément un tel opérateur (NGINX-LB-Operator) pour gérer l’équilibreur de charge externe, et met en évidence les différences entre NGINX Plus Ingress Controller et NGINX Controller.

où :

• Ressources Ingress (encadré bleu) – Une ressource Ingress standard et une ressource VirtualServer NGINX sont définies dans l’espace de noms du projet.
• Flèches bleues – Les ressources Ingress sont créées dans l’API Kubernetes, puis prises en charge par le contrôleur Ingress NGINX Plus, qui s’exécute dans un autre espace de noms.
• Ressources personnalisées (encadré vert) – Les ressources personnalisées, qui sont des instances de CRD installées avec NGINX-LB-Operator, sont définies dans l’espace de noms de votre projet et utilisées par NGINX-LB-Operator, qui s’exécute dans le même espace de noms.
• Flèches vertes – Les ressources sont créées dans l’API, puis prises en charge par NGINX-LB-Operator. Contrairement à l’Ingress Controller, qui configure une instance locale de NGINX Plus s’exécutant dans le même pod, NGINX-LB-Operator effectue un appel d’API à NGINX Controller.
• Flèches orange – NGINX Controller configure l’instance externe de NGINX Plus afin de répartir la charge vers le contrôleur Ingress NGINX Plus.

Dans cette topologie, les ressources personnalisées contiennent l’état souhaité de l’équilibreur de charge externe et définissent le NGINX Plus Ingress Controller comme serveur en amont (groupe de charges de travail). NGINX-LB-Operator recueille des informations sur les pods Ingress et les fusionne avec l’état souhaité avant de les envoyer à l’API NGINX Controller.

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

Écrire un opérateur pour Kubernetes peut sembler une tâche ardue au premier abord, mais Red Hat et la communauté open source de Kubernetes assurent la maintenance de l’Operator Framework, qui facilite grandement cette tâche. L’Operator SDK permet à quiconque de créer un opérateur Kubernetes à l’aide de Go, d’Ansible ou de Helm. Chez F5, nous publions déjà des collections Ansible pour bon nombre de nos produits, notamment la collection certifiée pour NGINX Controller. Il est donc assez simple de créer un opérateur pour gérer des instances NGINX Plus externes et interagir avec NGINX Controller.

J’ai utilisé l’Operator SDK pour créer l’opérateur d’équilibrage de charge NGINX, NGINX-LB-Operator, qui peut être déployé à l’échelle d’un espace de noms ou d’un cluster et surveille plusieurs ressources personnalisées. Celles-ci correspondent directement aux objets NGINX Controller (certificat, passerelle, application et composant) et représentent donc le modèle centré sur les applications de NGINX Controller directement dans Kubernetes. Les ressources personnalisées configurées dans Kubernetes sont détecté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. Comme NGINX Controller gère l’instance externe, vous bénéficiez également de fonctionnalités de surveillance et d’alerte, ainsi que des informations détaillées sur les applications fournies par NGINX Controller.

Ce schéma 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. NGINX-LB-Operator détecte les ressources nouvellement configurées et collecte 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 à NGINX Controller.
4. La configuration est transmise 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 ainsi qu’un exemple d’application sont disponibles sur GitHub. Si vous n’aimez pas les jeux de rôle ou si vous êtes venu directement chercher la version courte, rendez-vous-y dès maintenant.

Exemple de déploiement

Alors, faisons un jeu de rôle. Je serai Susan et vous pourrez être Dave.

Dans le rôle de Dave, vous dirigez une branche d’activité au sein de votre conglomérat fictif préféré. Vous êtes à la page et au fait des dernières tendances, entre autres, si bien que vous déployez toutes vos applications et tous vos microservices sur OpenShift et que, pour le trafic entrant, vous utilisez le contrôleur Ingress NGINX Plus pour Kubernetes. Toutes vos applications sont déployées sous forme de projets OpenShift (espaces de noms), tandis que le contrôleur Ingress NGINX Plus s’exécute dans son propre espace de noms Ingress.

Vous n’avez jamais été satisfait des fonctionnalités proposées par la spécification Ingress par défaut et avez toujours trouvé les ConfigMaps et les annotations quelque peu laborieuses. Vous avez donc été ravi lorsque NGINX a annoncé que le contrôleur Ingress NGINX Plus allait prendre en charge ses propres CRD. Aujourd’hui, les développeurs de vos applications utilisent les ressources VirtualServer et VirtualServerRoutes pour gérer le déploiement des applications sur le contrôleur Ingress NGINX Plus, ainsi que pour configurer le routage interne et la gestion des erreurs dans OpenShift.

Parfois, vous exposez même des services non-HTTP, grâce aux ressources personnalisées TransportServer également disponibles avec NGINX Plus Ingress Controller. Les développeurs peuvent définir ces ressources personnalisées dans les espaces de noms de leurs propres projets. Elles sont ensuite détectées par NGINX Plus Ingress Controller et immédiatement appliquées. C’est formidable, mais vous aimeriez pouvoir gérer tout aussi facilement l’équilibreur de charge réseau externe situé à la périphérie de votre cluster OpenShift. Chaque fois que vous devez faire évoluer la couche Ingress, votre lumbago se réveille.

Nous sommes samedi soir et vous devriez être en boîte de nuit, mais hier, vous avez encore dû mettre à l’échelle la couche Ingress et vous avez maintenant mal au bas du dos. Ping ! Dans un nuage de fumée apparaît Susan, votre marraine la bonne fée.

« Bonjour, Dave, » dit-elle.

« Qui êtes-vous ? Regardez ce que vous avez fait à mon tapis persan », répondez-vous.

Faisant fi de votre attitude, Susan poursuit en vous parlant de NGINX-LB-Operator, désormais disponible sur GitHub. Elle explique qu’avec un cluster NGINX Plus en périphérie d’OpenShift et NGINX Controller pour le gérer selon une approche centrée sur les applications, vous pouvez créer des ressources personnalisées qui définissent la configuration de l’équilibreur de charge NGINX Plus.

Le NGINX-LB-Operator surveille ces ressources et les utilise pour envoyer la configuration centrée sur l’application à NGINX Controller. À 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, tandis que vous gardez le contrôle sur les changements nécessitant une modification de l’équilibreur de charge NGINX Plus externe !

NGINX Controller collecte les métriques de l’équilibreur de charge NGINX Plus externe et vous les présente selon 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 Ingress NGINX Plus, NGINX-LB-Operator mettra automatiquement à jour NGINX Controller et l’équilibreur de charge NGINX Plus externe pour vous. Fini le mal de dos !

Conclusion

Kubernetes est une plateforme conçue pour gérer des applications conteneurisées. NGINX Controller fournit un modèle centré sur les applications pour concevoir et gérer la répartition de charge des applications. NGINX-LB-Operator combine les deux et vous permet de gérer l’ensemble de la pile de bout en bout sans avoir à vous soucier de l’infrastructure sous-jacente. Rendez-vous sur GitHub pour obtenir davantage d’informations techniques sur NGINX-LB-Operator ainsi qu’un exemple complet détaillé étape par étape.

En savoir plus sur nos solutions :

• Demandez un essai gratuit de NGINX Controller
• Contactez-nous pour discuter de vos cas d’usage
• Obtenez l’opérateur NGINX Ingress pour OpenShift
• Inscrivez-vous à une formation animée par un formateur

À propos de l’auteur

Mark Boddington

Autres articles de Mark Boddington