Bewährte Methoden für Leistung und Skalierung für große 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:

Node-Skalierung

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

• Verwenden Sie bei der Ausführung von AKS-Clustern die automatische Cluster-Skalierung oder die automatische Bereitstellung von Knoten , wenn möglich, um die dynamische Skalierung von Knoten basierend auf der Nachfrage nach Computeressourcen sicherzustellen.
• Wenn Sie ohne Verwendung der automatischen Clusterskalierung auf über 1 000 Knoten skalieren, wird empfohlen, in Batches von 500 – 700 Knoten gleichzeitig zu skalieren. Die Skalierungsvorgänge sollten eine Wartezeit von zwei bis fünf Minuten zwischen Skalierungsvorgängen haben, um Azure API-Drosselung zu verhindern. Weitere Informationen finden Sie unter API Management: Richtlinien für Zwischenspeicherung und Drosselung.
• 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.

Skalierbarkeit der AKS- und Kubernetes-Steuerungsebene

In Kubernetes werden alle Objekte, die in einem Cluster ausgeführt werden, von der Steuerebene verwaltet, die von AKS verwaltet 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 Umschlag, wobei jeder Ressourcentyp eine Dimension darstellt, und nicht alle Ressourcen sind in ihren Kosten gleich. Beispielsweise werden Secrets häufig von mehreren Controllern und Pods überwacht, von denen jeder einen anfänglichen LIST-Aufruf ausführt, um den Status zu synchronisieren. Da geheime Daten typischerweise groß sind und häufig aktualisiert werden, belasten sie die Steuerungsebene stärker als weniger häufig überwachte Ressourcen.

Je mehr Sie den Cluster innerhalb einer bestimmten Dimension skalieren, desto weniger können Sie innerhalb anderer 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.

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.

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.

Um zu bestätigen, ob die Steuerungsebene skaliert wurde, suchen Sie nach der Configmap large-cluster-control-plane-scaling-status.

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Überlegungen zu den Skalierungsgrenzen und Steuerebenen von Kubernetes

Kubernetes-Clients sind Anwendungskomponenten wie Operatoren oder Überwachungs-Agents, die im Cluster ausgeführt werden und mit dem Kube-API-Server kommunizieren, um Ressourcen zu lesen oder zu ändern. Es ist wichtig, zu optimieren, wie sich diese Clients verhalten, um die Last zu reduzieren, die sie auf dem Kube-API-Server und der Kubernetes-Steuerungsebene platzieren.

Die Anzahl der anforderungen, die aktiv vom API-Server zu einem bestimmten Zeitpunkt verarbeitet werden, wird durch --max-requests-inflight und --max-mutating-requests-inflight Flags bestimmt. AKS verwendet die Standardwerte von 400 und 200 Anforderungen für diese Flags, sodass insgesamt 600 Anforderungen zu einem bestimmten Zeitpunkt verteilt werden können. Da wir den API-Server auf größere Größen skalieren, erhöhen wir auch die Inflight-Anforderungen entsprechend.

Zwei Kubernetes-Objekttypen , PriorityLevelConfiguration und FlowSchema (APF), bestimmen, wie der API-Server die Gesamtanforderungskapazität über Anforderungstypen teilt. AKS verwendet die Standardkonfiguration.

Jeder PriorityLevelConfiguration wird ein Anteil der zulässigen Gesamtanforderungen zugewiesen. Führen Sie den folgenden Befehl aus, um die PriorityLevelConfiguration-Objekte in Ihrem Cluster und deren zugewiesenen Anforderungsfreigaben anzuzeigen.

kubectl get --raw /metrics | grep apiserver_flowcontrol_nominal_limit_seats

FlowSchema ordnet API-Serveranforderungen einer PriorityLevelConfiguration zu. Wenn mehrere FlowSchema-Objekte einer Anforderung entsprechen, wählt der API-Server das Objekt mit der niedrigsten übereinstimmenden Rangfolge aus.

Die Zuordnung von FlowSchemas zu PriorityLevelConfigurations kann mithilfe dieses Befehls angezeigt werden:

kubectl get flowschemas

Um zu bestätigen, ob Anforderungen aufgrund von APF verworfen werden, führen Sie den folgenden Befehl aus:

kubectl get --raw /metrics | grep apiserver_flowcontrol_rejected_requests_total

Bewährte Methoden für Kubernetes-Clients

LISTENaufrufe, die von nicht optimierten Clients ausgegeben werden, sind häufig einer der größten Faktoren, die die Skalierbarkeit eines Clusters einschränken. 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 Last auf etcd und API-Server basiert in erster Linie auf der Größe der Antwort. Dieser Leitfaden gilt, ob der Client eine kleine Anzahl von LIST-Anforderungen für große Objekte oder eine große Anzahl von LIST-Anforderungen für kleinere Objekte ausgibt.

Verwenden von Informanten

• Wenn Ihr Code eine aktualisierte Liste von Objekten im Arbeitsspeicher verwalten muss, bietet ihnen die Verwendung eines Informers aus der Client-go-Bibliothek vorteile, um Änderungen an den Ressourcen basierend auf Ereignissen zu überwachen, anstatt Änderungen abzufragen. Dies ist der beste Ansatz, um nicht optimierte und wiederholte LISTs zu vermeiden.

Verwenden des API-Servercaches

• Verwenden Sie resourceVersion=0, um Ergebnisse aus dem API-Servercache zurückzugeben. Dies kann verhindern, dass Objekte aus etcd abgerufen werden, wodurch die Last auf etcd reduziert wird, aber die Paginierung wird nicht unterstützt.

  /api/v1/namespaces/default/pods?resourceVersion=0
  

Effiziente Kubernetes-API-Nutzung

• Es wird empfohlen, das Argument 'watch' nach Möglichkeit zu verwenden. Ohne Argumente ist das Standardverhalten das Auflisten von Objekten. Beziehen Sie sich auf das folgende Beispiel.

  /api/v1/namespaces/default/pods?watch=true
  

  Verwenden Sie "Überwachung" mit resourceVersion, um den zuletzt bekannten Wert aus der vorhergehenden Liste oder Überwachung zu übernehmen. Dies wird automatisch in Client-Go behandelt. Überprüfen Sie jedoch, ob Sie einen Kubernetes-Client in anderen Sprachen verwenden.

  /api/v1/namespaces/default/pods?watch=true&resourceVersion=<resourceversion>
  

• Wenn Controller oder Operatoren LIST-Aufrufe verwenden müssen, sollten sie das Abfragen von clusterweiten Ressourcen ohne Bezeichnungen oder Feldselektoren vermeiden, insbesondere in großen Clustern. Die folgenden Beispiele zeigen optimierte und nicht optimierte LISTENaufrufe.

  Optimierte LISTE:

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running
  

  Nicht optimierte LISTE:

  /api/v1/pods
  

• Verwenden Sie die Paginierung, um die Größe von LIST-Antworten zu verringern, wenn der Client Daten aus etcd abrufen muss. Im folgenden Beispiel wird das Limit-Argument verwendet, um die Antwort auf 100 Objekte einzuschränken.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100
  

  Wenn Sie die LIST weiterhin alle Pod-Objekte im obigen Beispiel zurückgeben lassen möchten, verwenden Sie das Argument "continue" zusammen mit dem Limit.

  /api/v1/namespaces/default/pods?fieldSelector=status.phase=Running&limit=100&continue=<continue_token>
  

  Wenn kubectl verwendet wird, kann das Argument --chunk-size direkt angewendet werden, um Antworten zu paginieren.

  kubectl get pods -n default --chunk-size=100
  

• Wenn Ihre Controller oder Operatoren Lease-Aktualisierungen für die Führungsauswahl verwenden, stellen Sie sicher, dass sie widerstandsfähig gegen vorübergehende Konnektivitätsprobleme sind, indem Sie leaseDuration, renewDeadline und retryPeriod optimieren, die für Ihre Workloads optimal sind. Verwenden Sie für Kubernetes-Controller, die die client-go Führungswahl nutzen, die folgende Formel:

  lease_duration > renew_deadline > retry_period
  

Daemonsets

• Es gibt einen erheblichen Unterschied zwischen einem einzelnen Controller, der Objekte auflistet, und einem DaemonSet, das auf jedem Knoten ausgeführt wird, was dasselbe tut. Wenn mehrere Instanzen Ihrer Clientanwendung regelmäßig eine große Anzahl von Objekten auflisten, wird die Lösung in großen Clustern nicht gut skaliert.

• Auf Clustern mit Tausenden von Knoten kann das Erstellen eines neuen DaemonSets, das Aktualisieren eines DaemonSets oder das Erhöhen der Anzahl von Knoten zu einer hohen Last führen, die auf der Steuerebene platziert wird. Wenn DaemonSet-Pods teure API-Serveranforderungen beim Starten von Pods ausgeben, können sie eine hohe Ressourcennutzung auf der Steuerungsebene aus einer großen Anzahl gleichzeitiger Anforderungen verursachen.

• Verwenden Sie eine RollingUpdate-Strategie, um neue DaemonSet-Pods schrittweise zu einführen. Wenn die DaemonSet-Vorlage aktualisiert wird, ersetzt der Controller alte Pods durch neue Pods auf kontrollierte Weise. Wenn die Rollupdatestrategie nicht explizit konfiguriert ist, erstellt Kubernetes standardmäßig ein RollingUpdate mit maxUnavailable als 1, maxSurge as 0 und minReadySeconds als 0s. Sehen Sie sich das folgende Beispiel an.

    minReadySeconds: 30
    updateStrategy:
      type: RollingUpdate
      rollingUpdate:
        maxSurge: 0
        maxUnavailable: 1
  

• Die RollingUpdate-Strategie gilt nur für vorhandene DaemonSet-Pods. Es beschränkt nicht die Auswirkungen des Hinzufügens neuer Knoten, was zusätzliche DaemonSet-Pods erstellt oder komplett neue DaemonSets bereitstellt.

• Um zu verhindern, dass DaemonSets während des Starts gleichzeitige LIST-Anforderungen an den API-Server ausstellen, nachdem Knotenskalierung oder neue DaemonSet-Bereitstellungen durchgeführt wurden, implementieren Sie Start-Jitter im Containereintragspunkt und konfigurieren Sie entsprechende exponentielle Backoff - und Wiederholungsrichtlinien für 5xx- oder 429-Antworten, um wiederholte Wiederholungen großer LIST-Anforderungen zu verhindern.

    spec:
      template:
        spec:
          containers:
          - name: my-daemonset-container
            image: <image>
            command: ["/bin/sh", "-c", "sleep $(( (RANDOM % 60) + 1 )); exec /path/to/your/app --args"]
  

etcd-Optimierungen

• Halten Sie die Gesamtgröße von etcd klein und verwenden Sie etcd nicht als allgemeine Datenbank. AKS bietet standardmäßig 8 GB etcd-Speicher, aber größere etcd-Datenbanken erhöhen die Defragmentierungszeit, was zu Lese- und Schreibleistungsproblemen führen kann. Größere etcd-Datenbanken können auch die Wahrscheinlichkeit von API-Server- und etcd-Zuverlässigkeitsproblemen erhöhen, wenn ein nicht optimierter Client häufig eine große Anzahl von Objekten aus etcd abruft. Wenn die Größe der etcd-Datenbank 2 GB überschreitet, sollten Sie die unten aufgeführten Methoden zur Reduzierung der Objektgröße verwenden.
• Um die Größe der Podspezifikationen zu verringern, verschieben Sie Umgebungsvariablen aus den Podspezifikationen in ConfigMaps.
• Teilen Sie große Geheimnisse oder ConfigMaps in kleinere, verwaltbare Teile auf.
• Speichern Sie geheime Schlüssel in Azure Key Vault anstelle von Kubernetes Secrets, wenn möglich, um die Anzahl der geheimen Schlüssel zu reduzieren, die in usw. gespeichert sind.
• Bereinigen nicht verwendeter Objekte
  • Löschen Sie veraltete Aufträge und abgeschlossene Pods. Verwenden Sie "ttlSecondsAfterFinished" für Aufträge, sodass fertige Objekte automatisch entfernt werden.
  • Stellen Sie sicher, dass die Controller OwnerReferences festlegen. Dadurch kann die Kubernetes-Müllabfuhr abhängige Objekte automatisch entfernen, wenn die übergeordnete Ressource gelöscht wird.
  • Beschränken Sie den CronJob-Verlauf, indem Sie "successfulJobsHistoryLimit" und "failedJobsHistoryLimit" festlegen, um nur eine kleine Anzahl abgeschlossener Auftragsdatensätze beizubehalten.
  • Reduzieren Sie den Bereitstellungsrolloutverlauf. Alte ReplicaSets werden auch als API-Objekte gespeichert. Der Standardwert ist 10.
• Reduzieren Sie den Überarbeitungsverlauf von Helm mit dem Argument --history-max. Halten Sie sie in großen Clustern unter 5.

Überwachung der Metriken und Protokolle der AKS-Steuerungsebene

Die Überwachung von Steuerungsebenenmetriken in großen AKS-Clustern ist entscheidend für die Sicherstellung der Stabilität und Leistung von Kubernetes-Workloads. Diese Metriken bieten Einblicke in die Integrität und das Verhalten kritischer Komponenten wie dem API-Server, etcd, Controller, Manager und Scheduler. In großen Umgebungen, in denen Ressourcenkonflikte und ein hohes API-Aufrufvolumen üblich sind, hilft die Überwachung von Steuerungsebenenmetriken bei der Identifizierung von Engpässen, beim Erkennen von Anomalien und beim Optimieren der Ressourcennutzung. Durch die Analyse dieser Metriken können Operatoren proaktiv Probleme beheben, wie die API-Serverlatenz, viele etcd-Objekte oder einen übermäßigen Ressourcenverbrauch der Steuerungsebene, um einen effizienten Clusterbetrieb sicherzustellen und Ausfallzeiten zu minimieren.

Azure Monitor bietet umfassende Metriken und Protokolle über den Zustand der Steuerungsebene durch Azure Managed Prometheus und Diagnostikeinstellungen an.

• Eine Liste der Warnungen, die zur Überwachung des Zustands der Steuerungsebene konfiguriert werden sollen, finden Sie unter Bewährte Methoden für die Überwachung der AKS-Steuerungsebene.
• Um die Liste der Benutzer-Agents mit der höchsten Latenz zu erhalten, können Sie die Protokolle/Diagnoseeinstellungen für die Steuerungsebene verwenden.

Wichtige Steuerungsebene-Plattformmetriken

AKS macht die folgenden Plattformmetriken in Azure Monitor für die Überwachung des API-Servers und etcd verfügbar. Diese Metriken sind verfügbar, ohne verwaltete Prometheus zu aktivieren und können direkt im Azure-Portal unter Metrics für Ihren AKS-Cluster angezeigt werden.

API-Servermetriken:

Etcd-Metriken:

Konsistent überwachen Sie apiserver_cpu_usage_percentage und apiserver_memory_usage_percentage, um den Ressourcendruck auf dem API-Server zu erkennen. Wenn etcd_database_usage_percentage konsistent über 50 % liegt, überprüfen Sie den Abschnitt Etcd-Optimierungen, um die Datenbankgröße zu verringern. Die vollständige Liste der verfügbaren Metriken finden Sie unter AKS-Überwachungsdatenreferenz.

Funktionseinschränkungen

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

• AKS unterstützt standardmäßig die Skalierung von bis zu 5.000 Knoten für alle Standardebenen-/LTS-Cluster. AKS skaliert die Steuerungsebene Ihres Clusters zur Laufzeit basierend auf der Clustergröße und der API-Serverressourcenauslastung. Wenn Sie nicht bis zum unterstützten Grenzwert skalieren können, aktivieren Sie Kontrollebenenmetriken (Vorschau) mit dem verwalteten Azure Monitor-Dienst für Prometheus, um die Kontrollebene zu überwachen. Informationen zur Problembehandlung bei der Skalierung von Leistungs- oder Zuverlässigkeitsproblemen finden Sie in den folgenden Ressourcen:

  • Leitfaden zur Problembehandlung bei AKS im großen Stil
  • Problembehandlung für die Kubernetes-Steuerungsebene

  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 den unterstützten Grenzwert haben, öffnen Sie ein Support-Ticket.

• Azure Network Policy Manager (Azure npm) unterstützt nur bis zu 250 Knoten.

• Einige AKS-Knotenmetriken, einschließlich Knotendatenträgerauslastung, CPU/Arbeitsspeicherauslastung und Netzwerkein-/Ausgabe, sind in Azure Überwachen von Plattformmetriken nach der Skalierung der Steuerungsebene nicht verfügbar.

• Sie können das Feature „Beenden und Starten“ nicht mit Clustern mit mehr als 100 Knoten verwenden. Weitere Informationen finden Sie unter Beenden und Starten eines AKS-Clusters.

Azure API- und Plattform-Drosselung

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. Bei Azure erfolgt die Drosselung auf zwei Ebenen. Azure Resource Manager (ARM) begrenzt Anfragen auf Abonnement- und Mandantenebene. 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. Innerhalb eines Abonnements in einer bestimmten Region teilen alle Clients die API-Grenzwerte für eine bestimmte Azure-API, wie beispielsweise die PUT-APIs für Virtual Machine Scale Sets. Jeder AKS-Cluster verfügt über mehrere AKS-basierte Clients, z. B. Cloudanbieter oder Cluster autoscaler, 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.
  • Increase the Cluster Autoscaler scan interval: Wenn die Diagnoseberichte zeigen, dass eine Drosselung des Cluster Autoscalers festgestellt wurde, können Sie das Scanintervall erhöhen, um die Anzahl der Aufrufe von Virtual Machine Scale Sets vom Cluster Autoscaler zu reduzieren.
  • Rekonfigurieren von Anwendungen von Drittanbietern, um weniger Aufrufe zu tätigen: Wenn Sie in der Diagnose Anforderungsrate und Drosselungsdetails anzeigen nach Benutzeragenten filtern und feststellen, dass eine Anwendung eines Drittanbieters, z. B. eine Überwachungsanwendung, eine große Anzahl von GET-Anforderungen stellt, können Sie die Einstellungen dieser Anwendungen ändern, um die Häufigkeit der GET-Aufrufe zu verringern. Stellen Sie sicher, dass die Anwendungsclients beim Aufrufen von Azure-APIs exponentielles Backoff verwenden.
• Teilen Sie Ihre Cluster in verschiedene Abonnements oder Regionen auf: Wenn Sie eine große Anzahl von Clustern und Knotenpools haben, die Virtual Machine Scale Sets verwenden, können Sie diese in verschiedene Abonnements oder Regionen innerhalb desselben Abonnements aufteilen. Die meisten Azure API-Grenzwerte werden auf der Ebene von Abonnementen und Regionen geteilt, sodass Sie Ihre Cluster auf verschiedene Abonnements oder Regionen verschieben oder skalieren können, um die Blockierung durch Azure API-Drosselung zu vermeiden. 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.

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.

• Wenn Sie Azure Load Balancer Standard verwenden, verwenden Sie mindestens 2 Ausgehende öffentliche IPs. Berücksichtigen Sie auch Einschränkungen für LoadBalancer-Dienst-Back-End-Regeln bei der Planung für große Cluster. Azure Standardmäßige Lastenausgleichsgeräte unterstützen bis zu 10.000 Back-End-IP-Konfigurationen pro Front-End-IP. Jeder Typ: LoadBalancer-Dienst erstellt eine Lastenausgleichsregel pro verfügbar gemachter Port und ordnet alle Clusterknoten dem Back-End-Pool des Lastenausgleichs zu. Wenn Sie beispielsweise fünf Ports für einen einzelnen Dienst verfügbar machen, wird dieser Grenzwert bei 2000 Knoten erreicht.

  1 service * 5 ports * 2000 nodes = 10000 backend IP configurations
  

• Verwenden Sie Azure CNI-Überlagerung, um bis zu 200.000 Pods und 5.000 Knoten pro Cluster zu skalieren. Weitere Informationen finden Sie unter Configure Azure CNI Overlay Networking in AKS.

• Wenn Ihre Anwendung eine direkte Pod-zu-Pod-Kommunikation über Cluster benötigt, verwenden Sie Azure CNI mit dynamischer IP-Zuweisung und skalieren Sie bis zu 50.000 Anwendungs pods pro Cluster mit einer routingfähigen IP pro Pod. Weitere Informationen finden Sie unter Configure Azure CNI-Netzwerk für 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 Network Policy Manager (NPM) unterstützt nur bis zu 250 Knoten. Wenn Sie Netzwerkrichtlinien für größere Cluster erzwingen möchten, sollten Sie Azure CNI verwenden, das von Cilium unterstützt wird, wodurch die robuste Kontrollebene Azure CNI mit der Cilium-Datenebene kombiniert wird, um leistungsstarke Netzwerke und Sicherheit bereitzustellen.

• Aktivieren Sie LocalDNS in Ihren Knotenpools, um die Latenz der DNS-Auflösung zu reduzieren und zentrale CoreDNS-Pods zu entlasten. In großen Clustern mit hohen DNS-Abfragevolumes kann die zentralisierte DNS-Auflösung zu einem Engpass werden. LocalDNS stellt einen DNS-Proxy als systemd Dienst auf jedem Knoten bereit, löst Abfragen lokal auf, beseitigt den conntrack Tabellendruck und aktualisiert Verbindungen auf TCP, um Race-Conditions zu vermeidenconntrack. LocalDNS unterstützt auch die Bereitstellung abgelaufener zwischengespeicherter Antworten, wenn Upstream-DNS nicht verfügbar ist, wodurch die Workload-Resilienz bei vorübergehenden Ausfällen verbessert wird. Weitere Informationen finden Sie unter DNS-Auflösung in AKS.

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

• Wenn ein Cluster das Limit von 5.000 Knoten erreicht, werden Clusterupgrades blockiert. Dieser Grenzwert verhindert ein Upgrade, da keine Knotenkapazität verfügbar ist, um Rollupdates innerhalb des Grenzwerts der maximalen Surge-Eigenschaft auszufü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 Aufstufkonfiguration von 10-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.