Exécuter et gérer à grande échelle des applications de microservices dans des conteneurs sur un cluster de machines est une tâche complexe. Kubernetes vous aide à relever ce défi en vous offrant une solution puissante d’orchestration de conteneurs. Cette solution comprend plusieurs fonctionnalités importantes, telles que la tolérance aux pannes, la mise à l’échelle automatique, les mises à jour progressives, le stockage, la découverte de services et l’équilibrage de charge.
Dans cet article de blog, nous expliquons comment utiliser NGINX Open Source ou NGINX Plus avec Ingress, le framework d’équilibrage de charge intégré à Kubernetes pour le trafic HTTP. Ingress vous permet de configurer des règles qui contrôlent le routage du trafic externe vers les services de votre cluster Kubernetes. Vous pouvez choisir n’importe quel équilibreur de charge proposant un contrôleur Ingress, c’est-à-dire un logiciel que vous déployez dans votre cluster afin d’intégrer Kubernetes à l’équilibreur de charge. Nous vous montrons ici comment configurer l’équilibrage de charge d’une application de microservices avec Ingress et les contrôleurs Ingress que nous fournissons pour NGINX Plus et NGINX.
[Note de la rédaction – Les contrôleurs auparavant distincts pour NGINX et NGINX Plus ont été fusionnés en un seul contrôleur Ingress commun aux deux.]
Dans cet article de blog, nous examinons uniquement l’équilibrage de charge HTTP pour Kubernetes avec Ingress. Pour en savoir plus sur les autres options d’équilibrage de charge, consultez l’article « Équilibrage de charge des services Kubernetes avec NGINX Plus » sur notre blog.
Remarque : Les instructions complètes relatives aux procédures abordées dans cet article de blog sont disponibles dans notre dépôt GitHub. Cet article ne détaille pas toutes les étapes nécessaires, mais fournit des liens vers ces instructions.
Contrôleurs Ingress pour NGINX et NGINX Plus
Avant de déployer l’application exemple et de configurer la répartition de charge pour celle-ci, nous devons choisir un répartiteur de charge et déployer le contrôleur Ingress correspondant.
Un contrôleur Ingress est un logiciel qui intègre un équilibreur de charge spécifique à Kubernetes. Nous avons développé un contrôleur Ingress pour NGINX Open Source et NGINX Plus, désormais disponible dans notre dépôt GitHub. Il existe également d’autres implémentations créées par des tiers. Pour en savoir plus, consultez la page Contrôleurs Ingress du dépôt GitHub de Kubernetes.
Pour obtenir des instructions complètes sur le déploiement du contrôleur Ingress NGINX ou NGINX Plus dans votre cluster, consultez notre dépôt GitHub.
L’application de microservices d’exemple
Notre exemple d’application est une application web classique basée sur des microservices, qui se compose de plusieurs services déployés séparément. Cette application, appelée cafe, vous permet de commander soit du thé via le service tea, soit du café via le service coffee. Vous indiquez votre choix de boisson dans l’URI de votre requête HTTP : les URI se terminant par /tea vous permettent d’obtenir du thé, tandis que celles se terminant par /coffee vous permettent d’obtenir du café. Les connexions à l’application doivent être sécurisées avec SSL/TLS.
Le schéma ci-dessous illustre de manière conceptuelle l’application, dans laquelle l’équilibreur de charge NGINX Plus joue un rôle essentiel en acheminant les requêtes des clients vers le service approprié et en sécurisant les connexions clientes avec SSL/TLS.
Pour déployer l’application dans votre cluster, suivez les instructions disponibles dans notre dépôt GitHub.
Configuration de l’équilibrage de charge Kubernetes via Ingress
Notre application « cafe » nécessite que l’équilibreur de charge assure deux fonctions :
- Routage basé sur l’URI de la requête (également appelé « routage basé sur le chemin »)
- Terminaison SSL/TLS
Pour configurer l’équilibrage de charge avec Ingress, définissez des règles dans une ressource Ingress. Ces règles indiquent comment acheminer le trafic externe vers les services de votre cluster.
Dans la ressource, vous pouvez définir plusieurs serveurs virtuels, chacun associé à un nom de domaine différent. Un serveur virtuel correspond généralement à une application de microservices unique déployée dans le cluster. Pour chaque serveur, vous pouvez :
- Spécifiez plusieurs règles basées sur le chemin d’accès. Le trafic est envoyé vers différents services d’une application en fonction de l’URI de la requête.
- Configurez la terminaison SSL/TLS en référençant un certificat SSL/TLS et une clé.
Vous trouverez une explication plus détaillée d’Ingress, accompagnée d’exemples, sur la page de documentation d’Ingress.
Voici la ressource Ingress (cafe‑ingress.yaml) pour l’application cafe :
Chargement de l’exemple de code…
En l’examinant ligne par ligne, nous constatons :
- À la ligne 4, nous nommons la ressource « cafe‑ingress ».
- Aux lignes 6 à 9, nous configurons la terminaison SSL/TLS :
- À la ligne 9, nous référençons une ressource Secret par son nom cafe‑secret. Cette ressource contient le certificat SSL/TLS et la clé associée et doit être déployée avant la ressource Ingress.
- À la ligne 8, nous appliquons le certificat et la clé à notre serveur virtuel cafe.example.com.
- À la ligne 11, nous définissons un serveur virtuel avec le nom de domaine « cafe.example.com ».
- Aux lignes 13 à 21, nous définissons deux règles basées sur le chemin d’accès :
- La règle définie aux lignes 14 à 17 demande à l’équilibreur de charge de répartir les requêtes dont l’URI est /tea entre les conteneurs du service tea, déployé sous le nom tea‑svc dans le cluster.
- La règle définie aux lignes 18 à 21 indique à l’équilibreur de charge de répartir les requêtes dont l’URI est /coffee entre les conteneurs du service coffee, déployé sous le nom coffee‑svc dans le cluster.
- Les deux règles demandent à l’équilibreur de charge de distribuer les requêtes vers le port 80 du service correspondant.
Pour obtenir des instructions complètes sur le déploiement des ressources Ingress et Secret dans le cluster, consultez notre dépôt GitHub.
Tester l’application
Une fois le contrôleur Ingress NGINX Plus, notre application, la ressource Ingress et la ressource Secret déployés, nous pouvons tester l’application.
Lorsque nous envoyons une requête pour le thé avec l’URI « /tea », le navigateur affiche une page générée par le service tea.
Nous espérons que vous ne serez pas trop déçu que les services tea et coffee ne vous servent pas réellement de boissons, mais vous fournissent plutôt des informations sur les conteneurs dans lesquels ils s’exécutent ainsi que les détails de votre requête. Ces informations comprennent le nom d’hôte et l’adresse IP du conteneur, l’URI de la requête et l’adresse IP du client. Chaque fois que nous actualisons la page, nous obtenons une réponse provenant d’un conteneur différent.
Nous pouvons également nous connecter au tableau de bord de surveillance de l’activité en direct de NGINX Plus et consulter en temps réel les métriques d’équilibrage de charge de NGINX Plus et de chaque conteneur de notre application.
Extensions du contrôleur Ingress
Ingress fournit des fonctionnalités de base pour l’équilibrage de charge HTTP. Cependant, les besoins de vos applications en matière d’équilibrage de charge sont souvent plus complexes et ne sont donc pas pris en charge par Ingress. Pour répondre à certains de ces besoins, nous avons ajouté plusieurs extensions au contrôleur Ingress. Vous pouvez ainsi continuer à profiter des ressources Kubernetes pour configurer l’équilibrage de charge (plutôt que de devoir configurer directement l’équilibreur de charge), tout en bénéficiant de fonctionnalités avancées d’équilibrage de charge.
Pour obtenir la liste complète des extensions disponibles, consultez notre dépôt GitHub.
En outre, nous proposons un mécanisme permettant de personnaliser la configuration de NGINX à l’aide de ressources Kubernetes, par l’intermédiaire de ressources ConfigMap ou d’annotations. Par exemple, vous pouvez personnaliser les valeurs des directives proxy_connect_timeout ou proxy_read_timeout.
Lorsque vos besoins en matière de répartition de charge dépassent les fonctionnalités prises en charge par Ingress et nos extensions, nous vous recommandons une autre approche pour déployer et configurer NGINX Plus sans utiliser le contrôleur Ingress. Consultez l’article « Répartition de charge des services Kubernetes avec NGINX Plus » sur notre blog pour en savoir plus.
Avantages de NGINX Plus avec le contrôleur
Avec NGINX Plus, le contrôleur Ingress offre les avantages suivants en plus de ceux dont vous bénéficiez avec NGINX :
- Stabilité dans un environnement hautement dynamique – Chaque fois que le nombre de pods des services exposés via Ingress change, le contrôleur Ingress doit mettre à jour la configuration de NGINX ou NGINX Plus pour tenir compte de ces changements. Avec NGINX Open Source, vous devez modifier manuellement le fichier de configuration et recharger la configuration. Avec NGINX Plus, vous pouvez utiliser l’API de reconfiguration dynamique pour mettre à jour la configuration sans recharger le fichier de configuration. Cela évite l’augmentation potentielle de l’utilisation de la mémoire et la surcharge globale du système qui peuvent survenir lorsque les rechargements de configuration sont très fréquents.
- Statistiques en temps réel – NGINX Plus fournit des statistiques avancées en temps réel, auxquelles vous pouvez accéder via une API ou depuis le tableau de bord intégré. Elles vous permettent de mieux comprendre les performances de NGINX Plus et de vos applications.
- Persistance de session – Lorsque vous activez la persistance de session, NGINX Plus veille à ce que toutes les requêtes provenant d’un même client soient toujours transmises au même conteneur backend à l’aide de la méthode du « cookie persistant ».
Résumé
Kubernetes fournit un équilibrage de charge HTTP intégré permettant d’acheminer le trafic externe vers les services du cluster à l’aide d’Ingress. NGINX et NGINX Plus s’intègrent à l’équilibrage de charge de Kubernetes, prennent entièrement en charge les fonctionnalités d’Ingress et proposent également des extensions pour répondre à des besoins avancés en matière d’équilibrage de charge.
Pour essayer NGINX Plus et le contrôleur Ingress, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.
À 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.