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

„Es ist ein perfekter Sturm“ ist zwar eine gängige Aussage, aber im Fall der außer Kontrolle geratenen Kosten für Cloud Computing ist sie durchaus nützlich. Mehrere Faktoren bedingen einander und führen zu diesem perfekten Sturm:

1. Die Leute, die Workloads bereitstellen, sind nicht die Leute, die dafür bezahlen
2. Es ist einfach, Infrastruktur nach Bedarf und programmgesteuert zu nutzen
3. Leicht zugängliche Code-Repositories ermöglichen das „Ausleihen“ von Funktionen aus vorhandenem Code, der von jemand anderem geschrieben wurde
4. CI/CD-Pipelines und SRE-Praktiken helfen Entwicklern, Code schnell zu integrieren und bereitzustellen

Zusammenfassend haben wir eine Situation, in der Entwickler Anreize haben, neue Funktionen schnell bereitzustellen, indem sie vorhandene Codeblöcke nutzen, die normalerweise weder rationalisiert noch für den Zweck optimiert sind, dem sie in der neuen App dienen. Da die Markteinführungszeit von größter Bedeutung ist, steht die Optimierung in den Hintergrund (sehr weit hinten). Wenn der nicht optimierte Code die Leistung beeinträchtigt, ist die Bereitstellung einer leistungsfähigeren Infrastruktur nur einen API-Aufruf entfernt. Problem gelöst!

Das Problem wird noch verschärft durch die Kluft – sowohl in Bezug auf die Denkweise als auch auf die Organisationsstruktur – zwischen den Leuten, die den Code schreiben, und den Leuten, die die Rechnungen bezahlen. Wenn die Cloud-Kosten für Unternehmen steigen, gerät der CFO ins Schwitzen. Doch die Entwickler, die für die höheren Cloud-Rechnungen verantwortlich sind, werden für ihre schnelle Produktlieferung belohnt und können sich der finanziellen Probleme, die ihnen durch einen Anreiz entstehen, nicht bewusst sein.

Um das Problem zu lösen, haben sich F5 NGINX und Opsani zusammengetan, um eine Optimierungslösung bereitzustellen, die Abonnenten des F5 NGINX Ingress Controller zusätzliche Vorteile aus ihren vorhandenen 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 für Rate, Fehler und Dauer (RED) zu erfassen. Opsani nutzt seine autonomen Optimierungsfunktionen – unterstützt durch maschinelles Lernen – um die Infrastruktur kontinuierlich zu optimieren und sicherzustellen, dass die richtige Menge an Ressourcen für eine höhere Leistung und geringere Kosten verbraucht wird.

Kosten senken durch Cloud-Optimierung

NGINX-Benutzer kennen bereits die einfachste Möglichkeit, die Cloud-Kosten zu senken: Sie verwenden leichte Tools, die für minimale Latenz sorgen und gleichzeitig eine blitzschnelle Leistung bieten. Und natürlich sind in der Welt von Kubernetes einfache, aber leistungsstarke Tools eine Voraussetzung für eine erfolgreiche Bereitstellung. In diesem Blog erklären wir, wie Sie durch den Einsatz von drei Tools Kosten senken und gleichzeitig die Leistung verbessern können:

• NGINX Ingress Controller – Ein auf F5 NGINX Plus basierender Ingress Controller, der andere NGINX-basierte Ingress Controller deutlich übertrifft, da er sich dynamisch an Änderungen in Back-End-Endpunkten anpasst, ohne dass Ereignishandler oder Neuladen der Konfiguration erforderlich sind.
• Opsani – Eine einzigartige COaaS-Lösung (Continuous Optimization as a Service), die es ermöglicht, CO zu Ihrer CI/CD-Pipeline hinzuzufügen, sodass Sie Code schnell bereitstellen und diesen Code für optimale Leistung zu den geringstmöglichen Kosten optimieren können.
• Prometheus – Ein beliebtes Open-Source-Projekt für Überwachung 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 von NGINX Ingress Controller ist die Möglichkeit, die Sichtbarkeit in Kubernetes durch Live-Überwachung (über das NGINX Plus-Dashboard ) und historische Daten (über Prometheus) zu verbessern. Darüber hinaus kann der NGINX Ingress Controller in seiner Rolle als Front-End für Workloads Metriken zu Rate, Fehlern und Dauer (RED) erfassen und diese (über Prometheus) an Opsani weitergeben. Opsani verwendet maschinelles Lernen, um die Metriken mit der aktuell bereitgestellten Infrastruktur zu korrelieren und Änderungen zu empfehlen, die den NGINX Ingress Controller, Ihre Apps oder den gesamten Technologie-Stack optimieren. Sie können Opsani sogar so konfigurieren, dass Sie über für den NGINX Ingress Controller festgelegte Latenz- und Leistungsschwellenwerte benachrichtigt werden.

Ein Blick auf die Zahlen – Die Ergebnisse unserer Optimierungstests

Sehen wir uns ein Beispiel der 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 gezeigt, meldet die Opsani- Zusammenfassungsseite das Verkehrsaufkommen (Anfragen pro Sekunde oder RPS) im Zeitverlauf und hebt die Vorteile der Optimierungen im Vergleich zu den Basiseinstellungen hervor – hier eine Einsparung von 70 % bei den Instanzkosten pro Stunde und eine um 5 % bessere P50-Reaktionszeit .

Wir haben uns gefragt, wie diese Ergebnisse im Vergleich zu einem der bekanntesten Ingress-Controller abschneiden – dem auf Open Source basierenden Ingress-Controller NGINX, der von der Kubernetes-Community im GitHub-Repository kubernetes/ingress-nginx verwaltet wird. (Der etablierten NGINX-Konvention folgend werden wir es im Rest dieses Blogs „Community-Ingress-Controller“ nennen. Die auf NGINX Plus basierende Version von NGINX Ingress Controller wird vom NGINX-Entwicklungsteam im GitHub-Repository nginxinc/kubernetes-ingress gepflegt, zusammen mit dem Schwestermodell NGINX Ingress Controller, das auf NGINX Open Source basiert.)

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

• Topologie 1 – Community-Ingress-Controller, bereitgestellt mit dem Standardprozess . Die Erfassung der Messdaten erfolgte durch das Hinzufügen eines Envoy-Proxys in der zu testenden Application in einem Sidecar-Container im Application Pod.

  

• Topologie 2 – NGINX Ingress Controller basierend auf NGINX Plus, bereitgestellt mit Helm . Die Metriken wurden mit derselben Envoy-Bereitstellung und -Konfiguration wie für den Community-Ingress-Controller erfasst, um sicherzustellen, dass die Metrikerfassung den Leistungsoptimierungsprozess nicht beeinträchtigte.

  

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

  

Die Ergebnisse der Tests sind in der Tabelle zusammengefasst. Wie Sie sehen, erreicht der NGINX Ingress Controller eine bessere Kostenreduzierung, CPU-Optimierung und Speicheroptimierung als der Community-Ingress-Controller. Wir führen dies auf den effizienteren Lastausgleich des NGINX Ingress Controller zurück.

Die Ergebnisse für die P50-Reaktionszeit zeigen, dass Prometheus die ideale Methode zum Erfassen von Messdaten ist, da es den zusätzlichen Hop eliminiert, der vom Envoy-Sidecar-Mechanismus benötigt wird. Envoy hat keinen Einfluss auf die P50-Reaktionszeit für den Community Ingress Controller, verschlechtert die Latenz mit dem NGINX Ingress Controller jedoch tatsächlich um 4 %. Im Gegensatz dazu verbessert Prometheus die P50-Reaktionszeit mit NGINX Ingress Controller um 5 %.

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

So optimiert Opsani den NGINX Ingress Controller

Opsani kann Applications optimieren, selbst wenn in dynamischen Umgebungen eine schlechte Lastverteilung vorliegt. Es können auch beliebige Metrik-Inputs genutzt werden, die Optimierung verbundener Dienste wird jedoch erheblich verbessert, wenn der Input von einem vorhandenen Tool stammt, das Netzwerkmetriken erfasst. Zu diesem Zweck verwenden wir einen einfachen Bereitstellungsprozess, um Opsani mit dem NGINX Ingress Controller zu integrieren.

In Umgebungen, in denen NGINX der Ingress-Controller ist – was heutzutage auf viele Applications zutrifft – bietet die direkte Umstellung auf den NGINX Plus-basierten NGINX Ingress Controller einen effizienteren Lastausgleichsalgorithmus, ohne die Funktionsfähigkeit der Application anderweitig zu beeinträchtigen. Ein zweiter Vorteil besteht darin, dass auch Metriken für die durch den NGINX Ingress Controller ausgeglichene Applications verfügbar werden.

Die einzige zusätzliche Anforderung besteht darin, einen einzelnen Opsani-Pod mit der Application unter dem Optimierungs-Namespace bereitzustellen. Die Opsani-Vorlage für den auf NGINX Plus basierenden NGINX Ingress Controller richtet den Metrik-Endpunkt auf den Ingress-Dienst, um die application Metriken zu erfassen, die für die Optimierung erforderlich sind. Durch die Verarbeitung von Metriken aus drei oder vier Spitzenzeiten erreicht die Opsani-Engine innerhalb weniger Stunden ein optimales Optimierungsniveau. Bisher haben wir eine Spitzenlastoptimierung von 30 % bis 70 % erreicht.

Erste Schritte mit Opsani und NGINX Ingress Controller

Holen Sie sich Ihre kostenlosen Testversionen von NGINX Ingress Controller und Opsani und besuchen Sie dann unser GitHub-Repository für Skripts und Konfigurationsdateien für NGINX Ingress Controller und Opsani mit Prometheus.

Anhang: Testmethodik

Voraussetzungen

• Der auf NGINX Plus basierende NGINX Ingress Controller ist als Container aufgebaut .
• Kubernetes ist konfiguriert und das Zugriffsgeheimnis für die Registrierung ist verfügbar, um Zugriff auf eine sichere private Docker-Registrierung zu gewähren.
• Der auf NGINX Plus basierende NGINX Ingress Controller wird über Helm im Ingress -Namespace bereitgestellt.
• Eine NGINX VirtualServer-Ressource wird so konfiguriert, dass sie auf den zu optimierenden Dienst verweist (normalerweise standardmäßig der Frontend-Dienst). Ein Beispiel finden Sie in frontend-virtualserver.yaml in unserem GitHut-Repo.

Topologie und Konfiguration

Wir erstellen drei Opsani-Instanzen. Für die Topologien 1 und 2 verwenden wir die für alle Opsani-Konten verfügbare standardmäßige Opsani Dev-Vorlage, führen das Front-End der Application einfach mit dem NGINX Ingress Controller aus und verweisen auf den Application .

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

• {{ NAMESPACE }} – Zielressourcen-Namespace
• {{ DEPLOYMENT }} – Zielbereitstellung
• {{ CONTAINER }} – Name des Application

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

Während das Standard -ServoX für Opsani Dev eine Prometheus-Instanz enthält, stellen wir die Prometheus-Instanz stattdessen im selben Namespace wie den NGINX Ingress Controller bereit, um den Bedarf an ClusterRole-Konfiguration zu reduzieren.

Wir konfigurieren auch einen Dienst, der es dem Servo-Pod ermöglicht, die richtige Instanz zu finden und abzufragen. Dieses Artefakt wird in opsani-manifests-nginx-plus.yaml behandelt.

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