Application Gateway-Eingangscontroller für Azure Kubernetes Service

Veröffentlicht am 2 Dezember, 2019

Principal Software Engineer

Heute freuen wir uns, eine neue Lösung zur Bindung von Azure Kubernetes Service (AKS) und Application Gateway anzubieten. Die neue Lösung bietet einen Application Gateway-Eingangscontroller (Application Gateway Ingress Controller, AGIC) auf Open-Source-Grundlage für Kubernetes, der AKS-Kunden die Nutzung von Application Gateway ermöglicht, um ihre Cloudsoftware über das Internet verfügbar zu machen.

Unser nativer, skalierbarer und hochverfügbarer L7-Lastenausgleich ist bei unseren Kunden sehr gefragt. Er vereint die Vorteile von Azure Kubernetes Service, unserem verwalteten Kubernetes-Dienst, der den Betrieb fortschrittlicher Kubernetes-Umgebungen vereinfacht, und von Azure Application Gateway.

So funktioniert's

Der Application Gateway-Eingangscontroller wird in einem eigenen Pod im AKS des Kunden ausgeführt. Der Eingangscontroller überwacht eine Teilmenge der Kubernetes-Ressourcen auf Änderungen. Der Status des AKS-Clusters wird in Application Gateway-spezifische Konfiguration übersetzt und auf Azure Resource Manager angewendet. Die kontinuierliche Neukonfiguration von Application Gateway gewährleistet einen unterbrechungsfreien Datenfluss zu den AKS-Diensten. Das folgende Diagramm veranschaulicht den Fluss von Zustands- und Konfigurationsänderungen von der Kubernetes-API über den Application Gateway-Eingangscontroller zu Resource Manager und dann zu Application Gateway.

Ähnlich wie die beliebtesten Kubernetes-Eingangscontroller bietet der Application Gateway-Eingangscontroller mehrere Funktionen und nutzt dabei den nativen Application Gateway-L7-Lastenausgleich von Azure. Beispiele für solche Funktionen:

  • URL-Routing
  • Cookie-basierte Affinität
  • SSL-Terminierung (Secure Sockets Layer)
  • SSL-gesicherte End-to-End-Verbindungen
  • Unterstützung für öffentliche, private und hybride Websites
  • Integrierte Web Application Firewall

agic2

Die Architektur des Application Gateway-Eingangscontrollers unterscheidet sich von der eines herkömmlichen clusterinternen L7-Lastenausgleichs. Die architektonischen Unterschiede sind in diesem Diagramm dargestellt:

ausschnitt_bild003

  • Ein clusterinterner Lastenausgleich führt alle Datenpfadvorgänge durch und nutzt dabei die Computeressourcen des Kubernetes-Clusters. Er konkurriert mit den Geschäfts-Apps, die er verfügbar macht, um Ressourcen. Clusterinterne Eingangscontroller erstellen Kubernetes-Dienstressourcen und nutzen kubenet für den Netzwerkdatenverkehr. Im Vergleich zum Eingangscontroller fließt der Datenverkehr durch einen zusätzlichen Hop.
  • Der Eingangscontroller nutzt die erweiterten Netzwerke von AKS, die jedem Pod eine IP-Adresse aus dem mit Application Gateway gemeinsam verwendeten Subnetz zuweisen. Application Gateway verfügt über direkten Zugriff auf alle Kubernetes-Pods. Damit entfällt die Notwendigkeit, dass Daten über kubenet übergeben werden. Weitere Informationen zu diesem Thema finden Sie in unserem Artikel“Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service“, insbesondere im Abschnitt zum Vergleich von Netzwerkmodellen.

Lösungsleistung

Durch die direkte Verbindung von Application Gateway mit den Kubernetes-Pods kann der Application Gateway-Eingangscontroller eine bis zu 50 Prozent geringere Netzwerklatenz im Vergleich zu clusterinternen Eingangscontrollern erreichen. Application Gateway ist ein verwalteter Dienst, der durch VM-Skalierungsgruppen von Azure unterstützt wird. Folglich verwendet Application Gateway keine AKS-Computeressourcen für die Datenpfadverarbeitung. Ressourcen, die der Kubernetes-Bereitstellung zugeteilt sind, werden nicht durch Application Gateway mitgenutzt oder beeinträchtigt. Die automatische Skalierung von Application Gateway zu Spitzenzeiten beeinträchtigt im Gegensatz zu einem clusterinternen Eingang nicht die Fähigkeit, die Pods der Apps schnell zentral hochzuskalieren. Und natürlich wird durch den Wechsel vom clusterinternen L7-Eingang zu Application Gateway die Computeauslastung durch AKS sofort verringert.

Wir haben die Leistung eines clusterinternen Eingangscontrollers und eines Application Gateway-Eingangscontrollers in einem AKS-Cluster mit drei Knoten mit einer einfachen Web-App verglichen, die 22 Pods pro Knoten ausführt. Insgesamt 66 Web-App-Pods teilten sich Ressourcen mit drei clusterinternen Eingängen – einer pro Knoten. Wir haben Application Gateway mit zwei Instanzen konfiguriert. Wir haben mithilfe von Apache Bench insgesamt 100.000 Anforderungen erstellt, wobei die Parallelität auf 3.000 Anforderungen festgelegt wurde. Wir haben Apache Bench zweimal gestartet: einmal mit Verweis auf die Load Balancer Standard-Instanz, die den clusterinternen Eingangscontroller verfügbar macht, und ein zweites Mal mit Verbindung zur öffentlichen IP-Adresse von Application Gateway. Auf diesem stark ausgelasteten AKS-Cluster haben wir die durchschnittliche Wartezeit über alle Anforderungen hinweg aufgezeichnet:

  • Application Gateway: 480 ms pro Anforderung
  • Clusterinterner Eingang: 710 ms pro Anforderung

Wie die obigen Erfassungsdaten zeigen, weist der clusterinterne Eingangscontroller unter hoher Last eine etwa 48 Prozent höhere Latenz pro Anforderung als der Application Gateway-Eingangscontroller auf. Bei der Ausführung des gleichen Benchmarks auf dem gleichen Cluster, aber mit zwei Web-App-Pods pro Knoten, also insgesamt sechs Pods, konnten wie beobachten, dass der clusterinterne Eingangscontroller mit einer etwa 17 Prozent höheren Latenzzeit als Application Gateway arbeitete.

Nächste Schritte

Der Application Gateway-Eingangscontroller ist nun stabil und für den Einsatz in Produktionsumgebungen verfügbar. Das Projekt reift schnell aus, und wir arbeiten aktiv daran, neue Funktionen hinzuzufügen. Wir arbeiten daran, das Produkt mit Funktionen zu erweitern, die Kunden sich gewünscht haben, wie z. B. die Verwendung von auf Application Gateway gespeicherten Zertifikaten, gegenseitige TLS-Authentifizierung, gRPC und HTTP/2. Testen Sie den neuen Application Gateway-Eingangscontroller für AKS, verfolgen Sie den Fortschritt, und geben Sie uns Feedback über GitHub.