Kubernetes-Kosten in der Cloud mit NGINX, Opsani und Prometheus um 70 % senken

Amir Sharif

„Ein perfekter Sturm“ mag eine gängige Redewendung sein, doch im Zusammenhang mit ausufernden Cloud-Computing-Kosten ist sie durchaus treffend. Mehrere Faktoren verstärken sich gegenseitig und führen zu diesem perfekten Sturm:

1. Die Personen, die Workloads bereitstellen, sind nicht diejenigen, die dafür bezahlen
2. Infrastruktur lässt sich einfach bedarfsgerecht und programmgesteuert nutzen
3. Leicht zugängliche Code-Repositorys ermöglichen es, Funktionalität aus vorhandenem, von anderen geschriebenem Code zu „übernehmen“
4. CI/CD-Pipelines und SRE-Praktiken helfen Entwicklern, Code schnell zu integrieren und bereitzustellen

Alles in allem ergibt sich eine Situation, in der Entwickler dazu angehalten werden, neue Funktionen schnell bereitzustellen, indem sie vorhandene Codebausteine nutzen, die in der Regel weder verschlankt noch für ihren jeweiligen Zweck in der neuen App optimiert sind. Da eine kurze Markteinführungszeit oberste Priorität hat, rückt die Optimierung in den Hintergrund (und zwar sehr weit). Wenn der nicht optimierte Code die Leistung beeinträchtigt, lässt sich mit nur einem API-Aufruf eine leistungsfähigere Infrastruktur bereitstellen. Problem gelöst!

Verschärft wird das Problem durch die Kluft – sowohl hinsichtlich der Denkweise als auch der Organisationsstruktur – zwischen denjenigen, die den Code schreiben, und denjenigen, die die Rechnungen bezahlen. Mit den Cloud-Kosten des Unternehmens steigt auch der Druck auf den CFO. Die Entwickler jedoch, die für die höheren Cloud-Rechnungen verantwortlich sind, werden für ihre schnelle Produktbereitstellung belohnt und bleiben dabei in seliger Unkenntnis über die daraus resultierenden finanziellen Probleme, zu deren Entstehung ihre Anreizstrukturen beigetragen haben.

Um das Problem zu lösen, haben F5 NGINX und Opsani gemeinsam eine Optimierungslösung entwickelt, die Abonnenten von F5 NGINX Ingress Controller zusätzliche Vorteile aus ihren bestehenden Bereitstellungen bietet. NGINX Ingress Controller wird zu einer optimierten Lösung, wenn der Opsani Servo-Container in KubeNest-Workloads bereitgestellt wird, wo er Prometheus nutzt, um Metriken zu Rate, Fehlern und Dauer (RED) zu erfassen. Opsani nutzt seine autonomen, auf maschinellem Lernen basierenden Optimierungsfunktionen, um die Infrastruktur kontinuierlich zu optimieren und sicherzustellen, dass für eine höhere Leistung bei geringeren Kosten die richtige Menge an Ressourcen genutzt wird.

Mit Cloud-Optimierung Kosten senken

NGINX-Benutzer kennen bereits die grundlegendste Möglichkeit, Cloud-Kosten zu senken: den Einsatz schlanker Tools, die nur minimale Latenz verursachen und gleichzeitig blitzschnelle Leistung bieten. Und natürlich sind in der Kubernetes-Welt einfache, aber leistungsstarke Tools eine Voraussetzung für eine erfolgreiche Bereitstellung. In diesem Blogbeitrag erläutern wir, wie Sie mithilfe von drei Tools gleichzeitig Kosten senken und die Leistung verbessern können:

• NGINX Ingress Controller – Ein Ingress-Controller auf Basis von F5 NGINX Plus, der eine deutlich höhere Leistung erzielt als andere NGINX-basierte Ingress-Controller, da er sich ohne Event-Handler oder das erneute Laden der Konfiguration dynamisch an Änderungen der Backend-Endpunkte anpasst.
• Opsani – Eine einzigartige Lösung für Continuous Optimization as a Service (COaaS), mit der Sie Continuous Optimization (CO) in Ihre CI/CD-Pipeline integrieren können. So können Sie Code schnell bereitstellen und ihn für optimale Leistung bei möglichst geringen Kosten optimieren.
• Prometheus – Ein beliebtes Open-Source-Projekt für Monitoring und Alarmierung. Mit dem NGINX Plus Prometheus-Modul exportiert der auf NGINXnbsp;Plus basierende NGINX Ingress Controller Hunderte von Metriken an einen Prometheus-Server.

Einer der leistungsstärksten Anwendungsfälle für die auf NGINX Plus basierende Version des NGINX Ingress Controller ist die Möglichkeit, die Transparenz in Kubernetes zu verbessern – durch Live-Monitoring (über das NGINX Plus-Dashboard) und historische Daten (über Prometheus). Darüber hinaus kann der NGINX Ingress Controller in seiner Rolle als Frontend für Workloads Metriken zu Rate, Fehlern und Dauer (RED) erfassen und sie (über Prometheus) an Opsani übermitteln. Opsani nutzt maschinelles Lernen, um die Metriken mit der aktuell bereitgestellten Infrastruktur zu korrelieren und Änderungen zu empfehlen, die den NGINX Ingress Controller, Ihre Anwendungen oder den gesamten Technologie-Stack optimieren. Sie können Opsani sogar so konfigurieren, dass Sie bei Überschreitung der für den NGINX Ingress Controller festgelegten Latenz- und Leistungsschwellenwerte benachrichtigt werden.

Ein Blick auf die Zahlen – die Ergebnisse unserer Optimierungstests

Sehen wir uns ein Beispiel für die Ergebnisse an, die Sie von der Bereitstellung des auf NGINX Plus basierenden NGINX Ingress Controllers mit Opsani und Prometheus erwarten können. Wie im Screenshot zu sehen ist, zeigt die Opsani-Seite Zusammenfassung das Datenverkehrsvolumen (Anfragen pro Sekunde bzw. RPS) im Zeitverlauf und hebt die Vorteile ihrer Optimierungen gegenüber den Basiseinstellungen hervor – hier eine Einsparung von 70 % bei den Instanzkosten pro Stunde und eine um 5 % bessere P50-Antwortzeit.

Wir fragten uns, wie diese Ergebnisse im Vergleich zu einem der bekanntesten Ingress-Controller abschneiden würden – dem auf NGINX Open Source basierenden Ingress-Controller, der von der Kubernetes-Community im GitHub-Repository kubernetes/ingress-nginx gepflegt wird. (Gemäß der etablierten NGINX-Konvention bezeichnen wir ihn im weiteren Verlauf dieses Blogs als „Community-Ingress-Controller“. Die auf NGINX Plus basierende Version des NGINX Ingress Controller wird vom NGINX-Entwicklungsteam im GitHub-Repository nginxinc/kubernetes-ingress gepflegt, ebenso wie der zugehörige, auf NGINX Open Source basierende NGINX Ingress Controller.)

Wir haben die Leistung der beiden Ingress-Controller in drei Topologien getestet:

• Topologie 1 – Community-Ingress-Controller, bereitgestellt gemäß dem Standardverfahren. Die Metriken wurden erfasst, indem ein Envoy-Proxy als Sidecar-Container im Anwendungs-Pod direkt in den Datenpfad der getesteten Anwendung eingebunden wurde.
  
• Topologie 2 – auf NGINX Plus basierender NGINX Ingress Controller, bereitgestellt mit Helm. Die Metriken wurden mit derselben Envoy-Bereitstellung und -Konfiguration wie beim Community Ingress Controller erfasst, um sicherzustellen, dass die Metrikerfassung den Prozess der Leistungsoptimierung nicht beeinträchtigte.
  

• Topologie 3 – NGINX Ingress Controller auf Basis von NGINX Plus, ebenfalls mit Helm bereitgestellt. Die Metriken wurden mit Prometheus erfasst.
  

Die Tabelle fasst die Testergebnisse zusammen. Wie Sie sehen, erzielt der NGINX Ingress Controller eine stärkere Kostensenkung sowie eine bessere CPU- und Arbeitsspeicheroptimierung als der Community-Ingress-Controller. Wir führen dies auf die effizientere Lastverteilung des NGINX Ingress Controllers zurück.

Die Ergebnisse für die P50-Antwortzeit zeigen, dass Prometheus die ideale Lösung für die Erfassung von Metriken ist, da dadurch der zusätzliche Hop entfällt, den der Envoy-Sidecar-Mechanismus erfordert. Beim Community Ingress Controller hat Envoy keine Auswirkungen auf die P50-Antwortzeit, beim NGINX Ingress Controller erhöht es die Latenz jedoch um 4 %. Im Gegensatz dazu verbessert Prometheus die P50-Antwortzeit beim NGINX Ingress Controller um 5 %.

Informationen zur Durchführung der Tests finden Sie im Anhang.

Wie Opsani den NGINX Ingress Controller optimiert

Opsani kann Anwendungen selbst dann optimieren, wenn die Lastverteilung in dynamischen Umgebungen unzureichend ist. Es kann zudem jede Art von Metrikdaten nutzen. Die Optimierung verbundener Dienste wird jedoch erheblich verbessert, wenn die Daten von einem vorhandenen Tool stammen, das Netzwerkmetriken erfasst. Zu diesem Zweck verwenden wir einen einfachen Bereitstellungsprozess, um Opsani in den NGINX Ingress Controller zu integrieren.

In Umgebungen, in denen NGINX als Ingress-Controller eingesetzt wird – was heute auf viele Anwendungen zutrifft –, ermöglicht der unkomplizierte Wechsel zum NGINX Ingress Controller auf Basis von NGINX Plus einen effizienteren Lastverteilungsalgorithmus, ohne die Funktionsweise der Anwendung anderweitig zu beeinträchtigen. Ein weiterer Vorteil besteht darin, dass dadurch auch Metriken für die vom NGINX Ingress Controller lastverteilten Anwendungen verfügbar werden.

Die einzige zusätzliche Anforderung besteht darin, einen einzelnen Opsani-Pod zusammen mit der Anwendung im Optimierungs-Namespace bereitzustellen. Die Opsani-Vorlage für den auf NGINX Plus basierenden NGINX Ingress Controller verweist den Metrik-Endpunkt auf den Ingress-Service, um die für die Optimierung erforderlichen anwendungsspezifischen Metriken zu erfassen. Durch die Verarbeitung von Metriken aus drei oder vier Spitzenlastzeiträumen erreicht die Opsani-Engine innerhalb weniger Stunden ein optimales Optimierungsniveau. Bislang haben wir bei Spitzenlasten Optimierungen von 30 % bis 70 % erzielt.

Erste Schritte mit Opsani und dem NGINX Ingress Controller

Sichern Sie sich Ihre kostenlosen Testversionen von NGINX Ingress Controller und Opsani und besuchen Sie anschließend unser GitHub-Repository mit Skripten und Konfigurationsdateien für NGINX Ingress Controller und Opsani mit Prometheus.

Anhang: Testmethodik

Voraussetzungen

• Der auf NGINX Plus basierende NGINX Ingress Controller wird als Container erstellt.
• Kubernetes ist konfiguriert und das Geheimnis für den Registry-Zugriff ist verfügbar, um den Zugriff auf eine sichere private Docker-Registry zu ermöglichen.
• Der auf NGINX Plus basierende NGINX Ingress Controller wird über Helm im Namespace ingress bereitgestellt.
• Eine NGINX-VirtualServer-Ressource wird so konfiguriert, dass sie auf den zu optimierenden Dienst verweist (standardmäßig in der Regel der Frontend-Dienst). Ein Beispiel finden Sie in der Datei frontend-virtualserver.yaml in unserem GitHut-Repository.

Topologie und Konfiguration

Wir erstellen drei Opsani-Instanzen. Für die Topologien 1 und 2 verwenden wir die standardmäßige Opsani-Dev-Vorlage, die für alle Opsani-Konten verfügbar ist. Wir schalten der Anwendung lediglich den NGINX Ingress Controller vor und verweisen auf den Anwendungsdienst.

Für Topologie 3 verwenden wir dieselbe Standardvorlage und ändern die Servo-Konfiguration mithilfe der ConfigMap, die in opsani-manifests-nginx-plus.yaml im GitHub-Repository definiert ist. Wie bei der Standardvorlage ersetzen wir die folgenden Variablen in der ConfigMap durch die entsprechenden Werte:

• {{ NAMESPACE }} – Namespace der Zielressource
• {{ DEPLOYMENT }} – Ziel-Deployment
• {{ CONTAINER }} – Name des Ziel-Anwendungscontainers

Darüber hinaus legen wir OPSANI_ACCOUNT_NAME, OPSANI_APPLICATION_NAME und OPSANI_TOKEN gemäß dem mit der Anwendungsbereitstellung bereitgestellten Dokument fest.

Während die standardmäßige ServoX-Konfiguration für Opsani Dev eine Prometheus-Instanz umfasst, stellen wir die Prometheus-Instanz stattdessen im selben Namespace wie den NGINX Ingress Controller bereit, um den Bedarf an einer ClusterRole-Konfiguration zu reduzieren.

Wir konfigurieren außerdem einen Service, damit der Servo-Pod die richtige Instanz finden und abfragen kann. Dieses Artefakt ist in opsani-manifests-nginx-plus.yaml enthalten.

Sobald Bank of Anthos als Beispiel-Webanwendung ausgeführt wird und der Ingress überprüft wurde, starten wir die Ingress-Prometheus-Instanz. Abschließend können wir die Opsani-Optimierung starten, indem wir die Datei opsani-manifests-nginx-plus.yaml anwenden.

Über den Autor

Amir Sharif

Weitere Blogbeiträge von Amir Sharif