Comment améliorer la résilience dans Kubernetes grâce à la gestion avancée du trafic

Rédacteur – Ce billet fait partie d’ une série en 10 parties :

1. Réduisez la complexité avec Kubernetes de niveau production
2. Comment améliorer la résilience dans Kubernetes avec la gestion avancée du trafic (cet article)
3. Comment améliorer la visibilité dans Kubernetes
4. Six façons de sécuriser Kubernetes à l'aide d'outils de gestion du trafic
5. Guide pour choisir un contrôleur d'entrée, partie 1 : Identifiez vos besoins
6. Guide pour choisir un contrôleur d'entrée, partie 2 : Risques et pérennité
7. Guide pour choisir un contrôleur d'entrée, partie 3 : Open Source contre Par défaut vs. Commercial
8. Guide pour choisir un contrôleur d'entrée, partie 4 : Options du contrôleur d'entrée NGINX
9. Comment choisir un maillage de services
10. Test des performances des contrôleurs d'entrée NGINX dans un environnement cloud Kubernetes dynamique

Vous pouvez également télécharger l’ensemble complet des blogs sous forme d’eBook gratuit – Taking Kubernetes from Test to Production .

Il existe un moyen très simple de savoir qu’une entreprise n’utilise pas avec succès les technologies modernes de développement d’applications : ses clients sont prompts à se plaindre sur les réseaux sociaux. Ils se plaignent de ne pas pouvoir regarder en streaming le dernier film à succès. Ou accédez aux services bancaires en ligne. Ou effectuez un achat, car le délai du panier expire.

Même si les clients ne se plaignent pas publiquement, cela ne signifie pas que leur mauvaise expérience n’a pas de conséquences. L'un de nos clients, une grande compagnie d'assurance, nous a dit qu'il perdait des clients lorsque sa page d'accueil ne se chargeait pas dans les 3 secondes .

Toutes ces plaintes d’utilisateurs concernant de mauvaises performances ou des pannes pointent vers un coupable commun : la résilience… ou son absence. La beauté des technologies de microservices – y compris les conteneurs et Kubernetes – est qu’elles peuvent améliorer considérablement l’expérience client en améliorant la résilience de vos applications. Comment? Tout est question d’architecture.

J’aime expliquer la différence fondamentale entre les architectures monolithiques et les microservices en utilisant l’analogie d’une guirlande de lumières de Noël. Lorsqu'une ampoule s'éteint sur un filament ancien, le filament entier devient noir. Si vous ne pouvez pas remplacer l’ampoule, la seule chose qui mérite d’être décorée avec ce fil est l’intérieur de votre poubelle. Ce style ancien d'éclairage ressemble à une application monolithique, qui possède également des composants étroitement couplés et qui échoue si l'un des composants tombe en panne.

Mais l’industrie de l’éclairage, comme l’industrie du logiciel, a détecté ce problème. Lorsqu’une ampoule se brise sur une guirlande lumineuse moderne, les autres continuent de briller, tout comme une application de microservices bien conçue continue de fonctionner même lorsqu’une instance de service échoue.

Gestion du trafic Kubernetes

Les conteneurs sont un choix populaire dans les architectures de microservices, car ils sont parfaitement adaptés à la création d’une application à l’aide de composants plus petits et discrets : ils sont légers, portables et faciles à mettre à l’échelle. Kubernetes est la norme de facto pour l’orchestration des conteneurs, mais de nombreux défis se posent pour rendre Kubernetes prêt pour la production . Un élément qui améliore à la fois votre contrôle sur les applications Kubernetes et leur résilience est une stratégie de gestion du trafic mature qui vous permet de contrôler les services plutôt que les paquets et d'adapter les règles de gestion du trafic de manière dynamique ou avec l'API Kubernetes. Si la gestion du trafic est importante dans toute architecture, pour les applications hautes performances, deux outils de gestion du trafic sont essentiels : le contrôle du trafic et la répartition du trafic .

Contrôle de la circulation

Le contrôle du trafic (parfois appelé routage du trafic ou régulation du trafic ) fait référence à l'acte de contrôler où va le trafic et comment il y arrive. C'est une nécessité lors de l'exécution de Kubernetes en production, car cela vous permet de protéger votre infrastructure et vos applications contre les attaques et les pics de trafic. Deux techniques à intégrer dans le cycle de développement de votre application sont la limitation du débit et la coupure de circuit .

• Cas d'utilisation : Je souhaite protéger les services contre un nombre trop important de demandes
  Solution: Limitation de débit

  Qu'elles soient malveillantes (par exemple, devinettes de mots de passe par force brute et attaques DDoS) ou bénignes (comme des clients se précipitant vers une vente), un volume élevé de requêtes HTTP peut surcharger vos services et provoquer le blocage de vos applications. La limitation du débit restreint le nombre de requêtes qu'un utilisateur peut effectuer sur une période donnée. Les requêtes peuvent inclure quelque chose d'aussi simple qu'une requête GET pour la page d'accueil d'un site Web ou une requête POST sur un formulaire de connexion. En cas d'attaque DDoS, par exemple, vous pouvez utiliser la limitation de débit pour limiter le débit des requêtes entrantes à une valeur typique pour les utilisateurs réels.

• Cas d'utilisation : Je veux éviter les échecs en cascade
  Solution: Coupure de circuit

  Lorsqu'un service n'est pas disponible ou connaît une latence élevée, il peut s'écouler beaucoup de temps avant que les demandes entrantes expirent et que les clients reçoivent une réponse d'erreur. Les longs délais d'attente peuvent potentiellement provoquer une défaillance en cascade, dans laquelle la panne d'un service entraîne des délais d'attente sur d'autres services et la défaillance ultime de l'application dans son ensemble.

  Les disjoncteurs empêchent les défaillances en cascade en surveillant les pannes de service. Lorsque le nombre de requêtes échouées adressées à un service dépasse un seuil prédéfini, le disjoncteur se déclenche et commence à renvoyer une réponse d'erreur aux clients dès l'arrivée des requêtes, limitant ainsi efficacement le trafic hors du service.

  Le disjoncteur continue d'intercepter et de rejeter les demandes pendant une durée définie avant d'autoriser le passage d'un nombre limité de demandes à titre de test. Si ces demandes aboutissent, le disjoncteur arrête de limiter le trafic. Dans le cas contraire, l'horloge se réinitialise et le disjoncteur rejette à nouveau les demandes pendant le temps défini.

Répartition du trafic

La répartition du trafic (parfois appelée test du trafic ) est une sous-catégorie du contrôle du trafic et fait référence à l'acte de contrôler la proportion du trafic entrant dirigé vers différentes versions d'une application backend exécutée simultanément dans un environnement (généralement la version de production actuelle et une version mise à jour). Il s’agit d’un élément essentiel du cycle de développement d’applications, car il permet aux équipes de tester la fonctionnalité et la stabilité des nouvelles fonctionnalités et versions sans impacter négativement les clients. Les scénarios de déploiement utiles incluent le routage de débogage , les déploiements Canary , les tests A/B et les déploiements bleu-vert . Il existe un certain nombre d’incohérences dans l’utilisation de ces quatre termes dans l’ensemble du secteur. Nous les utilisons ici selon notre compréhension de leurs définitions.)

• Cas d'utilisation : Je suis prêt à tester une nouvelle version en production
  Solution: Routage de débogage

  Disons que vous avez une application bancaire et que vous allez ajouter une fonctionnalité de score de crédit. Avant de tester avec les clients, vous souhaitez probablement voir comment cela fonctionne en production. Le routage de débogage vous permet de le déployer publiquement tout en le « masquant » aux utilisateurs réels en autorisant uniquement certains utilisateurs à y accéder, en fonction des attributs de la couche 7 tels qu'un cookie de session, un ID de session ou un ID de groupe. Par exemple, vous pouvez autoriser l'accès uniquement aux utilisateurs qui disposent d'un cookie de session d'administrateur ; leurs demandes sont acheminées vers la nouvelle version avec la fonctionnalité de score de crédit tandis que tous les autres continuent sur la version stable.

  

• Cas d'utilisation : Je dois m'assurer que ma nouvelle version est stable
  Solution: Déploiement de Canary

  Le concept de déploiement de canari est tiré d'une pratique minière historique, où les mineurs emmenaient un canari en cage dans une mine de charbon pour servir d'alerte précoce en cas de gaz toxiques. Le gaz a tué le canari avant de tuer les mineurs, leur permettant d'échapper rapidement au danger. Dans le monde des applications, aucun oiseau n’est blessé ! Les déploiements Canary offrent un moyen sûr et agile de tester la stabilité d'une nouvelle fonctionnalité ou version. Un déploiement Canary typique commence avec une part élevée (disons 99 %) de vos utilisateurs sur la version stable et déplace un petit groupe (l'autre 1 %) vers la nouvelle version. Si la nouvelle version échoue, par exemple en plantant ou en renvoyant des erreurs aux clients, vous pouvez immédiatement déplacer le groupe de test vers la version stable. Si cela réussit, vous pouvez faire passer les utilisateurs de la version stable à la nouvelle, soit tous en même temps, soit (comme c'est plus courant) dans le cadre d'une migration progressive et contrôlée.

  

• Cas d'utilisation : Je dois savoir si les clients préfèrent une nouvelle version à la version actuelle
  Solution: Tests A/B

  Maintenant que vous avez confirmé que votre nouvelle fonctionnalité fonctionne en production, vous souhaiterez peut-être recueillir les commentaires des clients sur le succès de la fonctionnalité, en fonction d'indicateurs de performance clés (KPI) tels que le nombre de clics, les utilisateurs récurrents ou les notes explicites. Les tests A/B sont un processus utilisé dans de nombreux secteurs pour mesurer et comparer le comportement des utilisateurs dans le but de déterminer le succès relatif de différentes versions de produits ou d'applications au sein de la clientèle. Dans un test A/B classique, 50 % des utilisateurs obtiennent la version A (la version actuelle de l'application) tandis que les 50 % restants obtiennent la version B (la version avec la nouvelle fonctionnalité, mais stable). Le gagnant est celui qui possède le meilleur ensemble global d’indicateurs clés de performance.

  

• Cas d'utilisation : Je souhaite déplacer mes utilisateurs vers une nouvelle version sans temps d'arrêt
  Solution: Déploiement bleu-vert

  Supposons maintenant que votre application bancaire doive subir un changement de version majeur… félicitations ! Par le passé, la mise à niveau des versions impliquait généralement des temps d'arrêt pour les utilisateurs, car il fallait supprimer l'ancienne version avant de mettre la nouvelle version en production. Mais dans l’environnement concurrentiel actuel, les temps d’arrêt pour les mises à niveau sont inacceptables pour la plupart des utilisateurs. Les déploiements bleu-vert réduisent considérablement, voire éliminent, les temps d’arrêt liés aux mises à niveau. Conservez simplement l’ancienne version (bleue) en production tout en déployant simultanément la nouvelle version (verte) dans le même environnement de production.

  La plupart des organisations ne souhaitent pas faire passer 100 % des utilisateurs du bleu au vert en une seule fois. Après tout, que se passera-t-il si la version verte échoue ?! La solution consiste à utiliser un déploiement Canary pour déplacer les utilisateurs selon les incréments qui correspondent le mieux à votre stratégie d’atténuation des risques. Si la nouvelle version est un désastre, vous pouvez facilement ramener tout le monde à la version stable en quelques frappes de touches.

  

Comment NGINX peut vous aider

Vous pouvez réaliser un contrôle et une répartition avancés du trafic avec la plupart des contrôleurs Ingress et des maillages de services . La technologie à utiliser dépend de l’architecture de votre application et de vos cas d’utilisation. Par exemple, l’utilisation d’un contrôleur Ingress est judicieuse dans ces trois scénarios :

• Vos applications n'ont qu'un seul point de terminaison, comme dans le cas d'applications simples ou d'applications monolithiques que vous avez « soulevées et déplacées » dans Kubernetes.
• Il n'y a aucune communication de service à service dans votre cluster.
• Il existe une communication de service à service, mais vous n'utilisez pas encore de maillage de services.

Si votre déploiement est suffisamment complexe pour nécessiter un maillage de services, un cas d'utilisation courant consiste à répartir le trafic entre les services pour tester ou mettre à niveau des microservices individuels. Par exemple, vous souhaiterez peut-être effectuer un déploiement Canary derrière votre front-end mobile, entre deux versions différentes de votre API de microservice de géolocalisation.

Cependant, la configuration de la répartition du trafic avec certains contrôleurs d’entrée et maillages de services peut prendre du temps et être sujette aux erreurs, pour diverses raisons :

• Les contrôleurs d'entrée et les maillages de services de divers fournisseurs implémentent les fonctionnalités Kubernetes de différentes manières.
• Kubernetes n’est pas vraiment conçu pour gérer et comprendre le trafic de couche 7.
• Certains contrôleurs Ingress et maillages de services ne prennent pas en charge la gestion sophistiquée du trafic.

Avec NGINX Ingress Controller et NGINX Service Mesh , vous pouvez facilement configurer des politiques de routage et de répartition du trafic robustes en quelques secondes. Découvrez cette démo en direct avec nos experts et lisez la suite pour découvrir comment nous vous faisons gagner du temps avec des configurations plus simples, des personnalisations avancées et une visibilité améliorée.

Configuration simplifiée avec les ressources d'entrée NGINX et la spécification SMI

Ces fonctionnalités NGINX facilitent la configuration :

• Ressources NGINX Ingress pour NGINX Ingress Controller – Bien que la ressource Kubernetes Ingress standard facilite la configuration de la terminaison SSL/TLS, de l'équilibrage de charge HTTP et du routage de couche 7, elle n'inclut pas le type de fonctionnalités de personnalisation requises pour la rupture de circuit, les tests A/B et le déploiement bleu-vert. Au lieu de cela, les utilisateurs non-NGINX doivent utiliser des annotations, des ConfigMaps et des modèles personnalisés qui manquent tous de contrôle précis, ne sont pas sécurisés, sont sujets aux erreurs et difficiles à utiliser.

  Le contrôleur NGINX Ingress est fourni avec des ressources NGINX Ingress comme alternative à la ressource Ingress standard (qu'il prend également en charge). Ils fournissent un style de configuration natif, sécurisé et indenté qui simplifie la mise en œuvre de l’équilibrage de charge Ingress. Les ressources NGINX Ingress présentent un avantage supplémentaire pour les utilisateurs NGINX existants : elles facilitent la réutilisation des configurations d’équilibrage de charge à partir d’environnements non Kubernetes, de sorte que tous vos équilibreurs de charge NGINX peuvent utiliser les mêmes configurations.

• NGINX Service Mesh avec SMI – NGINX Service Mesh implémente l'interface Service Mesh (SMI), une spécification qui définit une interface standard pour les maillages de services sur Kubernetes, avec des ressources typées telles que TrafficSplit , TrafficTarget et HTTPRouteGroup . À l’aide des méthodes de configuration Kubernetes standard, NGINX Service Mesh et les extensions NGINX SMI simplifient le déploiement des stratégies de répartition du trafic, comme le déploiement Canary, avec une interruption minimale du trafic de production. Par exemple, voici comment définir un déploiement Canary avec NGINX Service Mesh :

  Version de l'API : split.smi-spec.io/v1alpha2kind : TrafficSplit
  métadonnées :
  nom : target-ts
  spécification :
  service : target-svc
  backends :
  - service : target-v1-0
  poids : 90
  - service : target-v2-0
  poids : 10

  Notre didacticiel, Déploiements à l'aide de la répartition du trafic , présente des exemples de modèles de déploiement qui exploitent la répartition du trafic, notamment les déploiements Canary et Blue-Green.

Contrôle et répartition du trafic plus sophistiqués avec des personnalisations avancées

Ces fonctionnalités NGINX facilitent le contrôle et la répartition du trafic de manière sophistiquée :

• Le magasin clé-valeur pour les déploiements Canary – Lorsque vous effectuez des tests A/B ou des déploiements bleu-vert, vous souhaiterez peut-être transférer le trafic vers la nouvelle version à des incréments spécifiques, par exemple 0 %, 5 %, 10 %, 25 %, 50 % et 100 %. Avec la plupart des outils, il s’agit d’un processus très manuel car vous devez modifier le pourcentage et recharger le fichier de configuration pour chaque incrément. Avec un tel montant de frais généraux, vous pourriez décider de prendre le risque de passer directement de 5 % à 100 %. Cependant, avec la version de NGINX Ingress Controller basée sur NGINX Plus , vous pouvez exploiter le magasin clé-valeur pour modifier les pourcentages sans avoir besoin de recharger .

• Disjoncteurs avec NGINX Ingress Controller – Les disjoncteurs sophistiqués permettent de gagner du temps et d'améliorer la résilience en détectant plus rapidement les pannes et les basculements, et même en activant des pages d'erreur personnalisées et formatées pour les flux en amont qui ne sont pas sains. Par exemple, un disjoncteur pour un service de recherche peut être configuré pour renvoyer un ensemble de résultats de recherche correctement formaté mais vide. Pour obtenir ce niveau de sophistication, la version de NGINX Ingress Controller basée sur NGINX Plus utilise des contrôles de santé actifs qui surveillent de manière proactive la santé de vos serveurs TCP et UDP en amont. Parce que la surveillance est effectuée en temps réel, vos clients seront moins susceptibles de rencontrer des applications qui renvoient des erreurs.

• Disjoncteur avec NGINX Service Mesh – La spécification du disjoncteur NGINX Service Mesh comporte trois champs personnalisés :

  • erreurs – Le nombre d’erreurs avant que le circuit ne se déclenche
  • timeoutSeconds – La fenêtre pendant laquelle les erreurs peuvent se produire avant de déclencher le circuit, ainsi que le temps d'attente avant de fermer le circuit
  • fallback – Le nom et le port du service Kubernetes vers lequel le trafic est redirigé après le déclenchement du circuit

  Bien que les erreurs et les timeoutSeconds soient des fonctionnalités de disjoncteur standard, le repli renforce encore davantage la résilience en vous permettant de définir un serveur de sauvegarde. Si les réponses de votre serveur de sauvegarde sont uniques, elles peuvent être un indicateur précoce d’un problème dans votre cluster, vous permettant de commencer le dépannage immédiatement.

Interpréter les résultats de la répartition du trafic avec les tableaux de bord

Vous avez mis en œuvre votre répartition du trafic… et maintenant ? Il est temps d'analyser le résultat. Cela peut être la partie la plus difficile, car de nombreuses organisations manquent d’informations clés sur les performances de leur trafic et de leurs applications Kubernetes. NGINX facilite l'obtention d'informations grâce au tableau de bord NGINX Plus et aux tableaux de bord Grafana prédéfinis qui visualisent les métriques exposées par Prometheus Exporter. Pour en savoir plus sur l’amélioration de la visibilité afin d’obtenir des informations plus pertinentes, lisez Comment améliorer la visibilité dans Kubernetes sur notre blog.

Maîtriser les microservices avec NGINX

Le contrôleur d'entrée NGINX basé sur NGINX Plus est disponible pour un essai gratuit de 30 jours qui inclut NGINX App Protect pour sécuriser vos applications conteneurisées.

Pour essayer NGINX Ingress Controller avec NGINX Open Source, vous pouvez obtenir le code source de la version ou télécharger un conteneur prédéfini depuis DockerHub .

Le service mesh NGINX toujours gratuit est disponible en téléchargement sur f5.com .