Réduction des coûts de Kubernetes de 70 % dans le Cloud avec NGINX, Opsani et Prometheus

« C’est une tempête parfaite » est peut-être une expression courante, mais elle s’avère utile dans le cas des coûts incontrôlables du cloud computing. Plusieurs facteurs se combinent pour engendrer cette tempête parfaite :

1. Les personnes qui déploient des charges de travail ne sont pas celles qui les paient
2. Il est facile de consommer l’infrastructure à la demande et par programmation
3. Les référentiels de code facilement accessibles permettent « d’emprunter » des fonctionnalités à partir de code existant écrit par quelqu’un d’autre
4. Les pipelines CI/CD et les pratiques SRE aident les développeurs à intégrer et à déployer rapidement du code

En mettant tout cela ensemble, nous nous trouvons dans une situation où les développeurs sont incités à déployer rapidement de nouvelles fonctionnalités en exploitant des blocs de code existants qui ne sont généralement ni rationalisés ni optimisés pour l'usage qu'ils servent dans la nouvelle application. Le délai de mise sur le marché étant primordial, l'optimisation passe au second plan (très loin). Si le code non optimisé nuit aux performances, il suffit d’un appel d’API pour mettre en place une infrastructure plus puissante. Problème résolu !

Le problème est aggravé par le fossé – en termes de mentalité et de structure organisationnelle – entre les personnes qui écrivent le code et celles qui paient les factures. À mesure que les coûts du cloud d’entreprise augmentent, les directeurs financiers transpirent. Mais les développeurs qui sont à l’origine des factures cloud plus élevées sont récompensés pour la rapidité de livraison de leurs produits tout en ignorant parfaitement les problèmes financiers en aval qu’ils ont été incités à créer.

Pour résoudre le problème, F5 NGINX et Opsani se sont associés pour fournir une solution d'optimisation qui offre aux abonnés de F5 NGINX Ingress Controller des avantages supplémentaires à partir de leurs déploiements existants. NGINX Ingress Controller devient une solution optimisée lorsque le conteneur Opsani Servo est déployé dans les charges de travail KubeNest , où il exploite Prometheus pour collecter les métriques de taux, d'erreurs et de durée (RED). Opsani utilise ses capacités d’optimisation autonomes – alimentées par l’apprentissage automatique – pour optimiser en permanence l’infrastructure afin de garantir que la bonne quantité de ressources est consommée pour des performances supérieures et un coût inférieur.

Utiliser l'optimisation du cloud pour réduire les coûts

Les utilisateurs de NGINX connaissent déjà la méthode la plus basique pour réduire les coûts du cloud : utiliser des outils légers qui ajoutent une latence minimale tout en offrant des performances ultra-rapides. Et bien sûr, dans le monde de Kubernetes, des outils simples mais puissants sont une condition préalable à un déploiement réussi. Dans ce blog, nous expliquons comment vous pouvez réduire les coûts et améliorer les performances en même temps en tirant parti de trois outils :

• Contrôleur d'entrée NGINX : un contrôleur d'entrée basé sur F5 NGINX Plus qui surpasse considérablement les autres contrôleurs d'entrée basés sur NGINX, car il s'ajuste dynamiquement aux modifications des points de terminaison back-end sans gestionnaires d'événements ni rechargements de configuration.
• Opsani – Une solution unique d'optimisation continue en tant que service (COaaS) qui permet d'ajouter du CO à votre pipeline CI/CD, vous permettant de livrer du code rapidement et d'optimiser ce code pour des performances optimales au coût le plus bas possible.
• Prometheus – Un projet open source populaire pour la surveillance et l’alerte. Avec le module NGINX Plus Prometheus , le contrôleur d'entrée NGINX basé sur NGINXnbsp;Plus exporte des centaines de métriques vers un serveur Prometheus.

L’un des cas d’utilisation les plus puissants de la version NGINX Plus de NGINX Ingress Controller basée sur NGINX est sa capacité à améliorer la visibilité dans Kubernetes avec une surveillance en direct (via le tableau de bord NGINX Plus ) et des données historiques (via Prometheus). De plus, dans son rôle de front-end pour les charges de travail, NGINX Ingress Controller peut collecter des mesures de taux, d'erreurs et de durée (RED) et les transmettre (via Prometheus) à Opsani. Opsani utilise l'apprentissage automatique pour corréler les métriques avec l'infrastructure actuellement déployée et recommander des modifications qui optimisent NGINX Ingress Controller, vos applications ou la pile technologique dans son ensemble. Vous pouvez même configurer Opsani pour vous alerter des seuils de latence et de performances définis pour NGINX Ingress Controller.

Un regard sur les chiffres – Les résultats de nos tests d’optimisation

Voyons un exemple des résultats que vous pouvez attendre du déploiement du contrôleur d’entrée NGINX basé sur NGINX Plus avec Opsani et Prometheus. Comme le montre la capture d'écran, la page de résumé d'Opsani indique le volume de trafic (requêtes par seconde ou RPS) au fil du temps et met en évidence les avantages de ses optimisations par rapport aux paramètres de base : ici, une économie de 70 % sur le coût horaire de l'instance et un temps de réponse P50 amélioré de 5 %.

Nous nous sommes demandés comment ces résultats pourraient se comparer à l’un des contrôleurs Ingress les plus connus : le contrôleur Ingress Open Source basé sur NGINX maintenu par la communauté Kubernetes dans le référentiel GitHub kubernetes/ingress-nginx . (Conformément à la convention NGINX établie, nous l'appellerons le « contrôleur d'entrée communautaire » pour le reste de ce blog. La version de NGINX Ingress Controller basée sur NGINX Plus est maintenue par l'équipe d'ingénierie NGINX dans le référentiel GitHub nginxinc/kubernetes-ingress , avec son contrôleur sœur NGINX Ingress basé sur NGINX Open Source.)

Nous avons testé les performances des deux contrôleurs Ingress dans trois topologies :

• Topologie 1 – Contrôleur d’entrée communautaire, déployé à l’aide du processus standard . Les métriques ont été collectées en ajoutant un proxy Envoy en ligne avec l' application testée, dans un conteneur sidecar dans le pod application .

  

• Topologie 2 – Contrôleur d’entrée NGINX basé sur NGINX Plus, déployé à l’aide de Helm . Les métriques ont été collectées avec le même déploiement et la même configuration Envoy que pour le contrôleur d'entrée de la communauté, afin de garantir que la collecte des métriques n'a pas d'impact sur le processus de performances d'optimisation.

  

• Topologie 3 – Contrôleur d’entrée NGINX basé sur NGINX Plus, également déployé à l’aide de Helm. Les mesures ont été collectées à l'aide de Prometheus.

  

Le tableau résume les résultats des tests. Comme vous pouvez le constater, le contrôleur d’entrée NGINX permet une meilleure réduction des coûts, une meilleure optimisation du processeur et une meilleure optimisation de la mémoire que le contrôleur d’entrée communautaire. Nous attribuons cela à l’équilibrage de charge plus efficace du contrôleur d’entrée NGINX.

Les résultats du temps de réponse P50 indiquent que Prometheus est le moyen idéal pour collecter des métriques, car il élimine le saut supplémentaire requis par le mécanisme side-car Envoy. Envoy n'a aucun effet sur le temps de réponse P50 pour le contrôleur Community Ingress, mais aggrave en réalité la latence de 4 % avec NGINX Ingress Controller. En revanche, Prometheus améliore le temps de réponse du P50 avec NGINX Ingress Controller de 5 %.

Pour plus d’informations sur la manière dont nous avons exécuté les tests, voir l’ annexe .

Comment Opsani optimise le contrôleur d'entrée NGINX

Opsani peut optimiser les applications même si elles sont mal équilibrées dans des environnements dynamiques. Il peut également exploiter tout type d’entrée de métriques, mais l’optimisation des services connectés est considérablement améliorée lorsque l’entrée provient d’un outil existant qui collecte les métriques du réseau. À cette fin, nous utilisons un processus de déploiement simple pour intégrer Opsani avec NGINX Ingress Controller.

Dans les environnements où NGINX est le contrôleur d'entrée (ce qui s'applique à de nombreuses applications aujourd'hui), le passage simple à l'utilisation du contrôleur d'entrée NGINX basé sur NGINX Plus fournit un algorithme d'équilibrage de charge plus efficace sans affecter le fonctionnement de application . Un deuxième avantage est que les mesures pour la charge des applications équilibrée par NGINX Ingress Controller deviennent également disponibles.

La seule exigence supplémentaire est de déployer un seul pod Opsani avec l’ application sous l’espace de noms d’optimisation. Le modèle Opsani pour le contrôleur d'entrée NGINX basé sur NGINX Plus pointe le point de terminaison des métriques vers le service Ingress pour capturer les métriques spécifiques à application nécessaires à l'optimisation. En traitant les métriques de trois ou quatre périodes de pointe, le moteur Opsani atteint un niveau d’optimisation optimal en quelques heures seulement. À ce jour, nous avons atteint une optimisation de la charge de pointe de 30 % à 70 %.

Premiers pas avec Opsani et NGINX Ingress Controller

Obtenez vos essais gratuits de NGINX Ingress Controller et Opsani , puis accédez à notre référentiel GitHub pour les scripts et les fichiers de configuration pour NGINX Ingress Controller et Opsani avec Prometheus.

Annexe : Méthodologie de test

Prérequis

• Le contrôleur d'entrée NGINX basé sur NGINX Plus est construit comme un conteneur .
• Kubernetes est configuré et le secret d'accès au registre est disponible pour fournir l'accès à un registre Docker privé sécurisé .
• Le contrôleur d’entrée NGINX basé sur NGINX Plus est déployé via Helm dans l’espace de noms d’entrée .
• Une ressource NGINX VirtualServer est configurée pour pointer vers le service à optimiser (généralement le service frontal par défaut). Voir frontend-virtualserver.yaml dans notre dépôt GitHut pour un exemple.

Topologie et configuration

Nous créons trois instances Opsani. Pour les topologies 1 et 2 , nous utilisons le modèle Opsani Dev standard disponible pour tous les comptes Opsani et connectons simplement l' application avec NGINX Ingress Controller et pointons vers le service application .

Pour la topologie 3 , nous utilisons le même modèle par défaut et modifions la configuration Servo avec le ConfigMap défini dans opsani-manifests-nginx-plus.yaml dans le dépôt GitHub. Comme avec le modèle standard, nous remplaçons les valeurs appropriées pour les variables suivantes dans le ConfigMap :

• {{ NAMESPACE }} – Espace de noms de la ressource cible
• {{ DEPLOYMENT }} – Déploiement cible
• {{ CONTAINER }} – Nom du conteneur de application cible

De plus, nous définissons OPSANI_ACCOUNT_NAME , OPSANI_APPLICATION_NAME et OPSANI_TOKEN conformément au document exposé avec le déploiement de application .

Alors que le ServoX par défaut pour Opsani Dev inclut une instance Prometheus, nous déployons plutôt l'instance Prometheus dans le même espace de noms que NGINX Ingress Controller, afin de réduire le besoin de configuration de ClusterRole.

Nous configurons également un service pour permettre au pod Servo de trouver et d’interroger l’instance correcte. Cet artefact est couvert dans opsani-manifests-nginx-plus.yaml .

Une fois que Bank of Anthos est exécuté en tant qu’exemple application Web et que l’entrée a été vérifiée, nous lançons l’instance Ingress Prometheus. Enfin, nous pouvons lancer l'optimisation Opsani en appliquant le fichier opsani-manifests-nginx-plus.yaml .