Zum Hauptinhalt wechseln

 Subscribe

Im Dezember 2022 haben wir unsere Partnerschaft mit Isovalent angekündigt, um die nächste Generation erweiterten Berkeley Packet Filter (eBPF)-Datenplan für cloudnative Anwendungen in Microsoft Azure zu bringen, und es wurde gezeigt, dass die nächste Generation von Azure Container Network Interface (CNI)-Datenplane von eBPF und Cilium unterstützt werden würde.

Heute freuen wir uns, die allgemeine Verfügbarkeit von Azure CNI bekanntzugeben, die von Cilium unterstützt wird. Azure CNI unterstützt von Cilium ist eine Netzwerkplattform der nächsten Generation, die zwei leistungsstarke Technologien kombiniert: Azure CNI für skalierbare und flexible Pod-Netzwerksteuerung, die in den Azure Virtual Network-Stapel integriert ist, und Cilium, ein Open-Source-Projekt, das eBPF-gestützte Datenebene für Netzwerke, Sicherheit und Observierbarkeit in Kubernetes nutzt. Azure CNI unterstützt von Cilium nutzt den Direct Routing-Modus von Cilium in virtuellen Gastcomputern und kombiniert es mit dem nativen Azure-Routing innerhalb des Azure-Netzwerks, wodurch eine verbesserte Netzwerkleistung für Workloads ermöglicht wird, die in Azure Kubernetes Service (AKS)-Clustern bereitgestellt werden, und mit einer integrierten Unterstützung für die Durchsetzung der Netzwerksicherheit.

In diesem Blog befassen wir uns weiter mit den Leistungs- und Skalierbarkeitsergebnissen, die durch dieses leistungsstarke Netzwerkangebot in Azure Kubernetes Service erzielt werden.

Leistungs- und Skalierungsergebnisse

Leistungstests werden in AKS-Clustern im Überlagerungsmodus durchgeführt, um das Systemverhalten zu analysieren und die Leistung unter schwerlastigen Bedingungen zu bewerten. Diese Tests simulieren Szenarien, in denen der Cluster einer hohen Ressourcenauslastung unterzogen wird, z. B. große gleichzeitige Anforderungen oder hohe Workloads. Ziel ist es, verschiedene Leistungsmetriken wie Reaktionszeiten, Durchsatz, Skalierbarkeit und Ressourcennutzung zu messen, um das Verhalten des Clusters zu verstehen und Leistungsengpässe zu identifizieren.

Dienstroutinglatenz

Das Experiment nutzte den Standard D4 v3 SKU-Knotenpool (16 GB Mem, 4 vCPU) in einem AKS-Cluster. Das Apachebench-Tool, das häufig für Benchmarking- und Lasttestwebserver verwendet wird, wurde zur Messung der Dienstroutinglatenz verwendet. Insgesamt wurden 50.000 Anforderungen generiert und für die Gesamtabschlusszeit gemessen. Es wurde festgestellt, dass die Dienstroutinglatenz von Azure CNI, die von Cilium und Kube-Proxy unterstützt wird, zunächst eine ähnliche Leistung aufweisen, bis die Anzahl der Pods 5000 erreicht. Über diesen Schwellenwert hinaus beginnt die Latenz für das Dienstrouting für kube-proxybasierte Cluster zu erhöhen, während sie eine konsistente Latenzstufe für Cilium-basierte Cluster Standard.

Insbesondere bei der Skalierung von bis zu 16.000 Pods zeigt das azure CNI, das vom Cilium-Cluster unterstützt wird, eine erhebliche Verbesserung bei einer Verringerung der Dienstroutinglatenz gegenüber dem Kube-Proxy-Cluster. Diese Ergebnisse bestätigen erneut, dass das eBPF-basierte Dienstrouting im Vergleich zu IPTables-basiertem Dienstrouting, das von kube-proxy verwendet wird, besser skaliert wird.

Dienstroutinglatenz in Sekunden

Service routing latency in seconds with single service and different number of pods in backend.
Dienstroutinglatenz in Sekunden mit einzelnem Dienst und unterschiedlicher Anzahl von Pods im Back-End.

Skalierungstestleistung

Der Skalierungstest wurde in einem Azure CNI durchgeführt, das von Cilium Azure Kubernetes Service Cluster unterstützt wird, unter Verwendung des Standard D4 v3 SKU-Knotenpools (16 GB Mem, 4 vCPU). Der Zweck des Tests bestand darin, die Leistung des Clusters unter hohen Skalierungsbedingungen zu bewerten. Der Test konzentrierte sich auf die Erfassung der zentralen Verarbeitungseinheit (CPU) und der Speicherauslastung der Knoten sowie auf die Überwachung der Last auf dem API-Server und Cilium.

Der Test umfasste drei unterschiedliche Szenarien, die jeweils für die Bewertung verschiedener Aspekte der Leistung des Clusters unter unterschiedlichen Bedingungen konzipiert sind.

Skalierungstest mit 100k-Pods ohne Netzwerkrichtlinie

Der Skalierungstest wurde mit einem Cluster mit 1k-Knoten und insgesamt 100k-Pods ausgeführt. Der Test wurde ohne Netzwerkrichtlinien und Kubernetes-Dienste durchgeführt.

Während des Skalierungstests stieg die Anzahl der Pods von 20K auf 100K, die CPU-Auslastung des Cilium-Agenten re Standard konsistent niedrig, nicht mehr als 100 Millikerne und Arbeitsspeicher beträgt rund 500 MiB.

Average CPU utilization in Millicore by cilium agent pods for creating different number of pods without network policies and services.
Cilium average CPU usage for creating 100k pods.
Average Memory utilization in Mebibytes by cilium agent pods for creating different number of pods without network policies and services.
Cilium average memory usage for creating 100k pods.

Skalierungstest mit 100k-Pods mit 2k-Netzwerkrichtlinien

Der Skalierungstest wurde mit einem Cluster mit 1K-Knoten und insgesamt 100K-Pods ausgeführt. Der Test umfasste die Bereitstellung von 2K-Netzwerkrichtlinien, aber keine Kubernetes-Dienste.

Die CPU-Auslastung des Cilium-Agents Standard, der unter 150 Millikerne liegt, und der Arbeitsspeicher liegt bei etwa 1 GiB. Dies hat gezeigt, dass Cilium Standard geringen Mehraufwand hat, obwohl die Anzahl der Netzwerkrichtlinien verdoppelt wurde.

Average CPU utilization in Millicore by cilium agent pods for creating different number of pods with 2k network policies and without services.
Cilium average CPU usage for creating 100k pods, 2k network policies.
Average CPU utilization in Millicore by cilium agent pods for creating different number of pods with 2k network policies and without services.
Cilium average memory usage for creating 100k pods, 2k network policies.

Skalierungstest mit 1k-Diensten mit 60k-Pods-Back-End- und 2k-Netzwerkrichtlinien

Dieser Test wird mit 1K-Knoten und 60K-Pods ausgeführt, begleitet von 2K-Netzwerkrichtlinien und 1K-Diensten, die jeweils 60 Pods zugeordnet sind.

Die CPU-Auslastung des Cilium-Agents Standard wurde bei rund 200 Millikernen und Speicher re Standard bei etwa 1 GiB neu Standard. Dies zeigt, dass Cilium auch dann weiterhin einen geringen Mehraufwand Standard, auch wenn eine große Anzahl von Diensten bereitgestellt wurde, und da wir zuvor über eBPF gesehen haben, erhebliche Latenzgewinne für Anwendungen bietet, und es ist schön zu sehen, dass mit sehr geringem Mehraufwand auf Infrastrukturebene erreicht wird.

Average CPU utilization in Millicore by cilium agent pods after for 1k services different number of backend pods and with 2k network policies.
Cilium durchschnittliche CPU-Auslastung zum Erstellen von 1k-Diensten mit 60k-Pod-Back-Ends, 2k-Netzwerkrichtlinien.
Average Memory utilization in Mebibytes by cilium agent pods for creating 1k services with different number of backend pods and with 2k network policies.
Cilium average memory usage for creating 1k services with 60k pod backends, 2k network policies.

Erste Schritte mit Azure CNI unterstützt von Cilium

Wie aus den obigen Ergebnissen hervorgeht, ist Azure CNI mit eBPF-Datenplan von Cilium am leistungsfähigsten und skaliert wesentlich besser mit Knoten, Pods, Diensten und Netzwerkrichtlinien, während der Aufwand gering bleibt. Dieses Produktangebot ist jetzt allgemein in Azure Kubernetes Service (AKS) verfügbar und funktioniert sowohl mit Dem Overlay- als auch mit dem VNET-Modus für CNI. Wir freuen uns, Sie einzuladen, Azure CNI mit Cilium zu testen und die Vorteile in Ihrer AKS-Umgebung zu erleben.

Um heute zu beginnen, besuchen Sie die Dokumentation, die auf Azure CNI unterstützt von Cilium verfügbar ist.

  • Explore

     

    Let us know what you think of Azure and what you would like to see in the future.

     

    Provide feedback

  • Build your cloud computing and Azure skills with free courses by Microsoft Learn.

     

    Explore Azure learning


Join the conversation