Bewährte Methoden im Zusammenhang mit der Leistung und Skalierung großer Workloads in Azure Kubernetes Service (AKS)

  • Artikel

Hinweis

Dieser Artikel befasst sich mit allgemeinen bewährten Methoden für große Workloads. Bewährte Methoden für kleine bis mittelgroße Workloads finden Sie unter Bewährte Methoden im Zusammenhang mit der Leistung und Skalierung kleiner bis mittelgroßer Workloads in Azure Kubernetes Service (AKS).

Wenn Sie Cluster in AKS bereitstellen und verwalten, können Sie die folgenden bewährten Methoden verwenden, um die Leistung und Skalierung zu optimieren.

Denken Sie daran, dass groß ein relativer Begriff ist. Kubernetes verfügt über einen mehrdimensionalen Umschlag, und der Skalierungsumschlag für Ihre Workload hängt von den ressourcen ab, die Sie verwenden. Beispielsweise kann ein Cluster mit 100 Knoten und Tausenden von Pods oder CRDs als groß betrachtet werden. Ein 1 000-Knotencluster mit 1 000 Pods und verschiedenen anderen Ressourcen kann aus Sicht der Steuerungsebene als klein betrachtet werden. Am besten lässt sich die Skalierung einer Kubernetes-Kontrollebene an der Erfolgsrate und Latenz der HTTP-Anforderungen des API-Servers ablesen, da dies ein Indikator für die Belastung der Kontrollebene ist.

In diesem Artikel lernen Sie Folgendes:

  • Skalierbarkeit der AKS- und Kubernetes-Steuerungsebene.
  • Bewährte Methoden des Kubernetes-Clients, einschließlich Backoff, Überwachungselemente und Paginierung.
  • Einschränkungen für Azure-API und Plattformeinschränkung.
  • Funktionseinschränkungen.
  • Bewährte Methoden für die Skalierung von Netzwerk- und Knotenpools.

Skalierbarkeit der AKS- und Kubernetes-Steuerungsebene

In AKS besteht ein Cluster aus einer Reihe von Knoten (physischen oder virtuellen Computern), die Kubernetes-Agents ausführen und von der Kubernetes-Kontrollebene verwaltet werden, die von AKS gehostet wird. Obwohl AKS die Steuerungsebene von Kubernetes und seine Komponenten im Hinblick auf Skalierbarkeit und Leistung optimiert, ist es immer noch an die Grenzen des Upstream-Projekts gebunden.

Kubernetes verfügt über einen mehrdimensionalen Skalierungsumschlag mit jedem Ressourcentyp, der eine Dimension darstellt. Nicht alle Ressourcen sind gleich. Beispielsweise werden Überwachungselemente häufig für geheime Schlüssel festgelegt, was zu Listenaufrufen an den Kube-API-Server führt, die Kosten hinzufügen und eine unverhältnismäßig höhere Belastung für die Steuerungsebene im Vergleich zu Ressourcen ohne Überwachungselemente ergeben.

Die Steuerungsebene verwaltet die gesamte Ressourcenskalierung im Cluster. Je mehr Sie also den Cluster innerhalb einer bestimmten Dimension skalieren, desto weniger können Sie in anderen Dimensionen skalieren. Beispielsweise wirkt sich das Ausführen von Hunderten von Tausenden von Pods in einem AKS-Cluster darauf aus, wie viel Pod-Churn (Pod-Mutationen pro Sekunde) die Steuerungsebene unterstützen kann.

Die Größe des Umschlags ist proportional zur Größe der Kubernetes-Steuerebene. AKS unterstützt drei Steuerungsebenen als Teil der Basis-SKU: die Ebenen in den Tarifen „Free“, „Standard“ und „Premium“. Weitere Informationen finden Sie unter Tarife „Free“, „Standard“ und „Premium“ von für die AKS-Clusterverwaltung.

Wichtig

Es wird dringend empfohlen, den Tarif „Standard“ oder „Premium“ für Produktions- oder Skalierungsworkloads zu verwenden. AKS skaliert automatisch die Kubernetes-Steuerungsebene, um die folgenden Skalierungsgrenzwerte zu unterstützen:

  • Bis zu 5 000 Knoten pro AKS-Cluster
  • 200 000 Pods pro AKS-Cluster (mit Azure CNI Overlay)

In den meisten Fällen führt das Überschreiten des Skalierungsgrenzwerts zu einer beeinträchtigten Leistung, führt jedoch nicht dazu, dass der Cluster sofort fehlschlägt. Um die Last auf der Kubernetes-Steuerungsebene zu verwalten, sollten Sie die Skalierung in Batches von bis zu 10 bis 20 % der aktuellen Skalierung in Betracht ziehen. Bei einem Knotencluster mit 5 000 Knoten skalieren Sie beispielsweise in Schritten von 500 – 1 000 Knoten. Während AKS Ihre Steuerungsebene automatisch skalieren kann, geschieht dies nicht sofort.

Sie können die API-Priorität und Fairness (APF) nutzen, um bestimmte Clients und Anforderungstypen zu drosseln, um die Steuerungsebene bei hohem Churn und hoher Last zu schützen.

Kubernetes-Clients

Kubernetes-Clients sind die Anwendungsclients, z. B. Operatoren oder Überwachungsagents, die im Kubernetes-Cluster bereitgestellt werden, die mit dem Kube-API-Server kommunizieren müssen, um Lese- oder Stummschaltungsvorgänge auszuführen. Es ist wichtig, das Verhalten dieser Clients zu optimieren, um die Last zu minimieren, die sie dem Kube-API-Server und der Kubernetes-Steuerungsebene hinzufügen.

Sie können den API-Serverdatenverkehr und das Clientverhalten über Kube-Überwachungsprotokolle analysieren. Weitere Informationen finden Sie unter Problembehandlung für die Kubernetes-Steuerungsebene.

LIST-Anforderungen können teuer sein. Wenn Sie mit Listen arbeiten, die mehr als ein paar tausend kleine Objekte oder mehr als ein paar hundert große Objekte enthalten, sollten Sie die folgenden Richtlinien beachten:

  • Berücksichtigen Sie die Anzahl der Objekte (CRs), die Sie beim Definieren eines neuen Ressourcentyps (CRD) erwarten.
  • Die Belastung von etcd und API-Server hängt in erster Linie von der Anzahl der vorhandenen Objekte ab, nicht von der Anzahl der zurückgegebenen Objekte. Selbst wenn Sie eine Feldauswahl verwenden, um die Liste zu filtern und nur eine kleine Anzahl von Ergebnissen abzurufen, gelten diese Richtlinien weiterhin. Die einzige Ausnahme ist das Abrufen eines einzelnen Objekts nach metadata.name.
  • Wenn möglich, vermeiden Sie wiederholte LISTA-Aufrufe, wenn Ihr Code eine aktualisierte Liste von Objekten im Arbeitsspeicher verwalten muss. Erwägen Sie stattdessen die Verwendung der Informer-Klassen, die in den meisten Kubernetes-Bibliotheken bereitgestellt werden. Informer kombinieren LIST- und WATCH-Funktionen automatisch, um eine Auflistung im Speicher effizient zu verwalten.
  • Überlegen Sie, ob Sie eine hohe Konsistenz benötigen, wenn Informer Ihre Anforderungen nicht erfüllen. Müssen Sie die aktuellsten Daten bis zum genauen Zeitpunkt der Ausstellung der Abfrage anzeigen? Wenn nicht, legen Sie ResourceVersion=0 fest. Dies bewirkt, dass der API-Servercache Ihre Anforderung anstelle von etcd bedient.
  • Wenn Sie Informer oder den API-Servercache nicht verwenden können, lesen Sie große Listen in Blöcken.
  • Vermeiden Sie es, öfter als nötig aufzulisten. Wenn Sie Informer nicht verwenden können, überlegen Sie, wie oft Ihre Anwendung die Ressourcen auflistet. Nachdem Sie das letzte Objekt in einer großen Liste gelesen haben, fragen Sie nicht sofort die gleiche Liste erneut ab. Sie sollten stattdessen eine Weile warten.
  • Berücksichtigen Sie die Anzahl der ausgeführten Instanzen Ihrer Clientanwendung. Es gibt einen großen Unterschied zwischen dem Erstellen eines einzelnen Controller-Auflistungsobjekts und dem Ausführen von Pods auf jedem Knoten. Wenn Sie beabsichtigen, mehrere Instanzen Ihrer Clientanwendung regelmäßig auf eine große Anzahl von Objekten aufzulisten, wird ihre Lösung nicht auf große Cluster skaliert.

Azure-API und Plattformdrosselung

Die Auslastung einer Cloudanwendung kann im Laufe der Zeit variieren, je nach Faktoren wie der Anzahl der aktiven Benutzer*inen oder den Arten von Aktionen, die Benutzer*inen ausführen. Wenn die Verarbeitungsanforderungen des Systems die Kapazität der verfügbaren Ressourcen übersteigen, kann das System überlastet werden und unter schlechter Leistung und Ausfällen leiden.

Um unterschiedliche Lastgrößen in einer Cloud-Anwendung zu bewältigen, können Sie der Anwendung erlauben, Ressourcen bis zu einer bestimmten Grenze zu nutzen, und sie dann drosseln, wenn die Grenze erreicht ist. Auf Azure erfolgt die Drosselung auf zwei Ebenen. Azure Resource Manager (ARM) drosselt Anforderungen für das Abonnement und den Mandanten. Wenn die Anforderung unterhalb der Drosselungsgrenzwerte für das Abonnement und den Mandanten liegt, leitet ARM die Anforderung an den Ressourcenanbieter weiter. Der Ressourcenanbieter wendet dann Drosselungsgrenzwerte an, die auf seinen Betrieb zugeschnitten sind. Weitere Informationen finden Sie unter ARM-Drosselungsanforderungen.

Verwalten der Drosselung in AKS

Azure-API-Grenzwerte werden in der Regel auf Einer Kombinationsebene für Abonnementregionen definiert. Beispielsweise können alle Clients innerhalb eines Abonnements in einer bestimmten Region API-Grenzwerte für eine bestimmte Azure-API freigeben, z. B. PUT-APIs für Virtual Machine Scale Sets. Jeder AKS-Cluster verfügt über mehrere AKS-basierte Clients, z. B. Cloudanbieter oder automatische Sclusterskalierung, oder kundeneigene Clients, z. B. Datadog oder selbst gehostete Prometheus, die Azure-APIs aufrufen. Beim Ausführen mehrerer AKS-Cluster in einem Abonnement innerhalb einer bestimmten Region teilen sich alle AKS-eigenen und kundeneigenen Clients innerhalb der Cluster eine gemeinsame Gruppe von API-Grenzwerten. Daher ist die Anzahl der Cluster, die Sie in einer Abonnementregion bereitstellen können, eine Funktion der Anzahl der bereitgestellten Clients, deren Anrufmuster und der gesamter Skalierung und Flexibilität der Cluster.

Unter Berücksichtigung der oben genannten Überlegungen können Kunden in der Regel zwischen 20 und 40 kleinen bis mittleren Clustern pro Abonnementregion bereitstellen. Sie können ihre Abonnementskala mithilfe der folgenden bewährten Methoden maximieren:

Aktualisieren Sie Ihre Kubernetes-Cluster immer auf die neueste Version. Neuere Versionen enthalten viele Verbesserungen, mit denen Leistungs- und Drosselungsprobleme behoben werden. Wenn Sie eine aktualisierte Version von Kubernetes verwenden und aufgrund der tatsächlichen Last oder der Anzahl der Clients im Abonnement weiterhin Drosselung sehen, können Sie die folgenden Optionen ausprobieren:

  • Analysieren Sie Fehler mithilfe von AKS Diagnose and Solve Problems: Sie können AKS Diagnose and Solve Problems verwenden, um Fehler zu analysieren, die Ursache zu identifizieren und Lösungsempfehlungen zu erhalten.
  • Teilen Sie Ihre Cluster in verschiedene Abonnements oder Regionen auf: Wenn Sie über eine große Anzahl von Clustern und Knotenpools verfügen, die Skalierungsgruppen für virtuelle Computer verwenden, können Sie sie in verschiedene Abonnements oder Regionen innerhalb desselben Abonnements aufteilen. Die meisten Azure-API-Grenzwerte werden auf Abonnementregionsebene freigegeben, sodass Sie Ihre Cluster auf verschiedene Abonnements oder Regionen verschieben oder skalieren können, um die Blockierung für die Azure-API-Drosselung aufzuheben. Diese Option ist besonders hilfreich, wenn Sie erwarten, dass Ihre Cluster eine hohe Aktivität aufweisen. Für diese Grenzwerte gibt es keine allgemeinen Richtlinien. Wenn Sie bestimmte Anleitungen benötigen, können Sie ein Supportticket erstellen.

Funktionseinschränkungen

Beachten Sie beim Skalieren ihrer AKS-Cluster auf größere Skalierungspunkte die folgenden Featurebeschränkungen:

Hinweis

Während des Vorgangs zum Skalieren der Steuerebene treten möglicherweise erhöhte API-Serverlatenz oder Timeouts für bis zu 15 Minuten auf. Wenn Sie weiterhin Probleme beim Skalieren auf das unterstützte Limit haben, öffnen Sie ein Supportticket.

  • Azure Network Policy Manager (Azure npm) unterstützt nur bis zu 250 Knoten.
  • Einige AKS-Knotenmetriken, einschließlich Knotendatenträgerauslastung, CPU-Speicherauslastung und Netzwerkeingang/-ausgang, sind in Azure Monitor-Plattformmetriken nicht mehr verfügbar, nachdem die Steuerungsebene skaliert wurde. Um zu bestätigen, ob die Steuerungsebene hochskaliert wurde, suchen Sie nach dem configmap-Status „control-plane-scaling-status“.
kubectl describe configmap control-plane-scaling-status -n kube-system

Netzwerk

Beachten Sie beim Skalieren Ihrer AKS-Cluster auf größere Skalierungspunkte die folgenden bewährten Methoden für Netzwerke:

  • Verwenden Sie verwaltete NAT für den Clusterausgang mit mindestens zwei öffentlichen IP-Adressen im NAT-Gateway. Weitere Informationen finden Sie unter Erstellen eines verwalteten NAT-Gateways für Ihren AKS-Cluster.
  • Verwenden Sie Azure CNI Overlay, um bis zu 200 000 Pods und 5 000 Knoten pro Cluster zu skalieren. Weitere Informationen finden Sie unter Konfigurieren von Azure CNI-Überlagerungsnetzwerken in AKS.
  • Wenn Ihre Anwendung eine direkte Pod-zu-Pod-Kommunikation über Cluster hinweg benötigt, verwenden Sie Azure CNI mit dynamischer IP-Zuweisung und skalieren Sie bis zu 50 000 Anwendungspods pro Cluster mit einer routingfähigen IP pro Pod. Weitere Informationen finden Sie unter Konfigurieren des Azure CNI-Netzwerks für die dynamische IP-Zuordnung in AKS.
  • Wenn Sie interne Kubernetes-Dienste hinter einem internen Lastenausgleich verwenden, empfiehlt es sich, einen internen Lastenausgleich oder einen Dienst mit weniger als 750 Knoten zu erstellen, um eine optimale Skalierungsleistung und Elastizität des Lastenausgleichs zu erzielen.
  • Azure NPM unterstützt nur bis zu 250 Knoten. Wenn Sie Netzwerkrichtlinien für größere Cluster erzwingen möchten, sollten Sie Azure CNI unterstützt von Cilium verwenden, das die robuste Kontrollebene von Azure CNI mit der Cilium-Datenebene kombiniert, um Netzwerk- und Sicherheitsfunktionen mit hoher Leistung bereitzustellen.

Skalierung des Knotenpools

Beachten Sie beim Skalieren ihrer AKS-Cluster auf größere Skalierungspunkte die folgenden bewährten Methoden für die Skalierung des Knotenpools:

  • Verwenden Sie für Systemknotenpools die Standard_D16ds_v5-SKU oder eine entsprechende Core/Memory-VM-SKU mit kurzlebigen Betriebssystemdatenträgern, um ausreichende Computeressourcen für Kube-System-Pods bereitzustellen.
  • Da AKS einen Grenzwert von 1 000 Knoten pro Knotenpool aufweist, wird empfohlen, mindestens fünf Benutzerknotenpools zu erstellen, um auf bis zu 5 000 Knoten hochzuskalieren.
  • Verwenden Sie bei Ausführung von AKS-Clustern im großen Stil wann immer möglich die automatische Clusterskalierung, um die dynamische Skalierung von Knotenpools basierend auf der Nachfrage nach Computeressourcen sicherzustellen. Weitere Informationen finden Sie unter Automatisches Skalieren eines AKS-Clusters zur Erfüllung von Anwendungsanforderungen.
  • Wenn Sie ohne Verwendung der automatischen Clusterskalierung auf über 1 000 Knoten skalieren, wird empfohlen, in Batches von 500 – 700 Knoten gleichzeitig zu skalieren. Außerdem sollte zwischen solchen Skalierungsvorgängen eine Wartezeit von 2 bis 5 Minuten liegen, um eine Drosselung der Azure-API zu verhindern. Weitere Informationen finden Sie unter API Management: Richtlinien für Zwischenspeicherung und Drosselung.

Überlegungen und bewährte Methoden für ein Clusterupgrade

  • Wenn ein Cluster das Limit von 5.000 Knoten erreicht, werden Clusterupgrades blockiert. Diese Grenzwerte verhindern ein Upgrade, da keine Kapazität für Knoten verfügbar ist, um rollende Updates innerhalb des Grenzwerts der maximalen Surge-Eigenschaft durchzuführen. Wenn Sie einen Cluster an diesem Grenzwert haben, wird empfohlen, vor dem Versuch eines Clusterupgrades das Cluster auf 3.000 Knoten herunterzuskalieren. Dadurch wird zusätzliche Kapazität für Knotenänderungen bereitgestellt und die Last auf der Steuerebene minimiert.
  • Beim Upgrade von Clustern mit mehr als 500 Knoten wird empfohlen, eine maximale Surge-Konfiguration von 10 bis 20 % der Kapazität des Knotenpools zu verwenden. AKS konfiguriert Upgrades mit einem Standardwert von 10 % für maximalen Surge. Sie können die Einstellungen für den maximalen Anstieg pro Knotenpool anpassen, um einen Kompromiss zwischen Upgradegeschwindigkeit und Workloadunterbrechung zu ermöglichen. Wenn Sie die Einstellungen für den maximalen Anstieg (max surge) erhöhen, wird der Upgradevorgang schneller abgeschlossen, kann aber zu Unterbrechungen während des Upgradevorgangs führen. Weitere Informationen finden Sie unter Anpassen des Knotenanstiegsupgrades.
  • Weitere Informationen zu Clusterupgrades finden Sie unter Upgrade eines AKS-Clusters.