Prendre de meilleures décisions grâce à Deep Service Insight de NGINX Ingress Controller

Nous avons publié la version 3.0 de NGINX Ingress Controller en janvier 2023 avec une multitude de nouvelles fonctionnalités importantes et de fonctionnalités améliorées. Une nouvelle fonctionnalité que nous pensons que vous trouverez particulièrement utile est Deep Service Insight, disponible avec l'édition NGINX Plus de NGINX Ingress Controller.

Deep Service Insight répond à une limitation qui entrave le fonctionnement optimal lorsqu'un système de décision de routage tel qu'un équilibreur de charge se trouve devant un ou plusieurs clusters Kubernetes, à savoir que le système n'a pas accès aux informations sur l'état des services individuels exécutés dans les clusters derrière le contrôleur Ingress. Cela l'empêche d'acheminer le trafic uniquement vers des clusters avec des services sains, ce qui expose potentiellement vos utilisateurs à des pannes et des erreurs telles que404 et500 .

Deep Service Insight élimine ce problème en exposant l’état de santé des pods de service back-end (tel que collecté par NGINX Ingress Controller) à un point de terminaison dédié où vos systèmes peuvent y accéder et l’utiliser pour de meilleures décisions de routage.

Dans cet article, nous examinons en profondeur le problème résolu par Deep Service Insight, expliquons son fonctionnement dans certains cas d’utilisation courants et montrons comment le configurer.

Pourquoi Deep Service Insight ?

Les sondes standard de vivacité, de préparation et de démarrage de Kubernetes vous donnent des informations sur les services back-end exécutés dans vos clusters, mais pas suffisamment pour obtenir le type d'informations dont vous avez besoin pour prendre de meilleures décisions de routage tout au long de votre pile. Le manque d’informations appropriées devient encore plus problématique à mesure que vos déploiements Kubernetes deviennent plus complexes et que vos besoins commerciaux en matière de disponibilité ininterrompue deviennent plus pressants.

Une approche courante pour améliorer la disponibilité à mesure que vous faites évoluer votre environnement Kubernetes consiste à déployer des équilibreurs de charge, des gestionnaires DNS et d’autres systèmes de décision automatisés devant vos clusters. Cependant, en raison du fonctionnement des contrôleurs Ingress, un équilibreur de charge placé devant un cluster Kubernetes n'a normalement pas accès aux informations d'état sur les services derrière le contrôleur Ingress dans le cluster ; il peut uniquement vérifier que les pods du contrôleur Ingress eux-mêmes sont sains et acceptent le trafic.

NGINX Ingress Controller, en revanche, dispose d'informations sur l'état du service. Il surveille déjà l'état de santé des pods en amont d'un cluster en envoyant des contrôles de santé passifs périodiques pour les services HTTP , TCP , UDP et gRPC , en surveillant la réactivité des requêtes et en suivant les codes de réponse réussis et d'autres mesures. Il utilise ces informations pour décider comment répartir le trafic sur les pods de vos services afin de fournir une expérience utilisateur cohérente et prévisible. Normalement, NGINX Ingress Controller exécute toute cette magie en silence en arrière-plan, et vous ne réfléchirez peut-être jamais à deux fois à ce qui se passe sous le capot. Deep Service Insight « fait apparaître » ces informations précieuses afin que vous puissiez les utiliser plus efficacement à d’autres niveaux de votre pile.

Comment fonctionne Deep Service Insight ?

Deep Service Insight est disponible pour les services que vous déployez à l'aide des ressources personnalisées NGINX VirtualServer et TransportServer (respectivement pour HTTP et TCP/UDP). Deep Service Insight utilise l' API NGINX Plus pour partager la vue du contrôleur d'entrée NGINX sur les pods individuels d'un service back-end sur un point de terminaison dédié unique à Deep Service Insight :

• Pour VirtualServer – <adresse_IP> :<port> /sonde/<nom d'hôte>
• Pour TransportServer – <adresse_IP> :<port> /sonde/ts/<nom_service>

où

• <adresse_IP> appartient au contrôleur d'entrée NGINX
• <port> est le numéro de port de Deep Service Insight (9114 par défaut)
• <nom d'hôte> est le nom de domaine du service tel que défini dans le spec.hôte champ de la ressource VirtualServer
• <nom_service> est le nom du service tel que défini dans le spec.en amont.service champ dans la ressource TransportServer

La sortie comprend deux types d’informations :

1. Un code d'état HTTP pour le nom d'hôte ou le nom du service :

   • 200 OK – Au moins une gousse est en bonne santé
   • 418 Je suis une théière – aucune dosette n’est saine
   • 404 Introuvable – Aucun pod ne correspond au nom d’hôte ou au nom de service spécifié

2. Trois compteurs pour le nom d’hôte ou le nom de service spécifié :

   • Nombre total d'instances de service (pods)
   • Nombre de pods dans l'état Up (sain)
   • Nombre de pods dans l'état Malsain

Voici un exemple où les trois pods d’un service sont sains :

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8 Date: Jour , JJ Lun AAAA hh : mm : ss TZ Longueur du contenu : 32 {"Total":3,"En hausse":3,"Mauvais pour la santé":0}

Pour plus de détails, consultez la documentation du contrôleur d'entrée NGINX.

Vous pouvez personnaliser davantage les critères utilisés par NGINX Ingress Controller pour déterminer si un pod est sain en configurant des contrôles de santé actifs. Vous pouvez configurer le chemin et le port vers lesquels le contrôle d'intégrité est envoyé, le nombre de contrôles échoués qui doivent se produire dans une période spécifiée pour qu'un pod soit considéré comme défectueux, le code d'état attendu, les délais d'attente pour la connexion ou la réception d'une réponse, et bien plus encore. Incluez le champ Upstream.Healthcheck dans la ressource VirtualServer ou TransportServer .

Exemples de cas d'utilisation pour Deep Service Insight

Un cas d’utilisation dans lequel Deep Service Insight est particulièrement utile est lorsqu’un équilibreur de charge achemine le trafic vers un service exécuté dans deux clusters, par exemple pour une haute disponibilité. Au sein de chaque cluster, NGINX Ingress Controller suit l’état des pods en amont comme décrit ci-dessus. Lorsque vous activez Deep Service Insight, les informations sur le nombre de pods en amont sains et non sains sont également exposées sur un point de terminaison dédié. Votre système de décision de routage peut accéder au point de terminaison et utiliser les informations pour détourner le trafic d'application des pods non sains au profit des pods sains.

Le diagramme illustre le fonctionnement de Deep Service Insight dans ce scénario.

Vous pouvez également tirer parti de Deep Service Insight lors de la maintenance d’un cluster dans un scénario de haute disponibilité. Réduisez simplement le nombre de pods d’un service à zéro dans le cluster sur lequel vous effectuez la maintenance. L'absence de pods sains s'affiche automatiquement au point de terminaison Deep Service Insight et votre système de décision de routage utilise ces informations pour envoyer du trafic vers les pods sains de l'autre cluster. Vous obtenez un basculement automatique efficace sans avoir à modifier la configuration sur NGINX Ingress Controller ou sur le système, et vos clients ne subissent jamais d'interruption de service.

Activation d'une connaissance approfondie des services

Pour activer Deep Service Insight, incluez l’argument de ligne de commande -enable-service-insight dans le manifeste Kubernetes ou définissez le paramètre serviceInsight.create sur true si vous utilisez Helm.

Il existe deux arguments facultatifs que vous pouvez inclure pour ajuster le point de terminaison à votre environnement :

• -service-insight-port-d'écoute <port> – Modifiez le numéro de port par défaut de Deep Service Insight, 9114 (<port> est un entier compris entre 1 024 et 65 535). L'équivalent de Helm est le paramètre serviceInsight.port .
• -service-insight-tls-chaîne <secret> – Un secret Kubernetes (certificat et clé TLS) pour la terminaison TLS du point de terminaison Deep Service Insight (<secret> est une chaîne de caractères avec le format <espace_de_nom>/<nom_secret>). L'équivalent de Helm est le paramètre serviceInsight.secret .

Exemple: Activer Deep Service Insight pour l'application Café

Pour voir Deep Service Insight en action, vous pouvez l'activer pour l' application Cafe souvent utilisée comme exemple dans la documentation de NGINX Ingress Controller.

1. Installez l'édition NGINX Plus de NGINX Ingress Controller avec prise en charge des ressources personnalisées NGINX et activation de Deep Service Insight :

   • Si vous utilisez Helm , définissez le paramètre serviceInsight.create sur true .
   • Si vous utilisez un manifeste Kubernetes (Deployment ou DaemonSet), incluez l’argument -enable-service-insight dans le fichier manifeste.

2. Vérifiez que NGINX Ingress Controller est en cours d'exécution :

   $ kubectl get pods -n nginx-ingress NOM PRÊT ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ...  LE STATUT REPREND L'ÂGE...  Course 0 9j

3. Déployez l'application Café selon les instructions du fichier README .

4. Vérifiez que la ressource personnalisée NGINX VirtualServer est déployée pour l'application Cafe (l'adresse IP est omise pour plus de lisibilité) :

   $ kubectl get vs NOM ÉTAT HÔTE IP PORTS ÂGE café Valide cafe.example.com ... [80,443] 7h1m

5. Vérifiez qu'il existe trois pods en amont pour le service Cafe exécuté sur cafe.example.com :

   $ kubectl get pods NOM PRÊT STATUT RESTARTS AGE coffee-87cf76b96-5b85h 1/1 En cours d'exécution 0 7h39m coffee-87cf76b96-lqjrp 1/1 En cours d'exécution 0 7h39m tea-55bc9d5586-9z26v 1/1 En cours d'exécution 0 111m

6. Accédez au point de terminaison Deep Service Insight :

   $ boucle -i <adresse_IP_NIC>:9114/probe/cafe.exemple.com

   Le 200 D'ACCORD le code de réponse indique que le service est prêt à accepter le trafic (au moins un pod est sain). Dans ce cas, les trois pods sont dans l’état Up.

   HTTP/1.1 200 OK Type de contenu : application/json ; jeu de caractères = utf-8 Date : Jour , JJ Lun AAAA hh : mm : ss TZ Contenu-Longueur : 32 {"Total":3,"En hausse":3,"Mauvais pour la santé":0}

   Le 418 Je suis un théière le code d'état indique que le service n'est pas disponible (tous les pods ne sont pas sains).

   HTTP/1.1 418 Je suis une théièreContenu-Type : application/json ; charset=utf-8 Date : Jour , JJ Lun AAAA hh : mm : ss TZ Longueur du contenu : 32 {"Total":3,"En hausse":0,"Mauvais pour la santé":3}

   Le 404 Pas Trouvé le code d'état indique qu'aucun service n'est en cours d'exécution sur le nom d'hôte spécifié.

   HTTP/1.1 404 non trouvéDate : Jour , JJ Lun AAAA hh : mm : ss TZ Longueur du contenu : 0

Ressources

Pour obtenir le journal des modifications complet de la version 3.0.0 de NGINX Ingress Controller, consultez les Notes de version .

Pour essayer NGINX Ingress Controller avec NGINX Plus et NGINX App Protect, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .