Freigeben über

Häufige Probleme beim Ausführen oder Skalieren großer AKS-Cluster – Häufig gestellte Fragen

  • Artikel

In diesem Artikel werden häufig gestellte Fragen zu häufig gestellten Problemen beantwortet, die auftreten können, wenn Sie große Cluster in Microsoft Azure Kubernetes Service (AKS) ausführen oder skalieren. Ein großer Cluster ist ein beliebiger Cluster, der mit mehr als 500 Knoten ausgeführt wird.

Beim Erstellen, Skalieren oder Upgrade wird ein Fehler "Kontingent überschritten" angezeigt.

Um dieses Problem zu beheben, erstellen Sie eine Supportanfrage im Abonnement, in dem Sie versuchen, ein Kontingent für den entsprechenden Ressourcentyp zu erstellen, zu skalieren oder zu aktualisieren. Weitere Informationen finden Sie unter regionalen Berechnungskontingenten.

Beim Bereitstellen eines AKS-Clusters, der erweiterte Netzwerke verwendet, wird beim Bereitstellen eines AKS-Clusters ein Fehler "insufficientSubnetSize" angezeigt.

Dieser Fehler gibt an, dass ein Subnetz, das für einen Cluster verwendet wird, keine IPs mehr innerhalb des CIDR für eine erfolgreiche Ressourcenzuordnung verfügbar ist. Dieses Problem kann während der Erstellung von Upgrades, Skalierungen oder Knotenpools auftreten. Dieses Problem tritt auf, da die Anzahl der freien IPs im Subnetz kleiner als das Ergebnis der folgenden Formel ist:

Anzahl der angeforderten Knoten * Knotenpoolwert --max-pod

Voraussetzungen

  • Um über 400 Knoten zu skalieren, müssen Sie das Azure CNI-Netzwerk-Plug-In verwenden.

  • Informationen zum Planen Ihres virtuellen Netzwerks und Ihrer Subnetze für die Anzahl der Knoten und Pods, die Sie bereitstellen, finden Sie unter Planen von IP-Adressen für Ihren Cluster. Informationen zum Verringern des Aufwands für die Subnetzplanung oder clusterreaktivierung, die Sie aufgrund der IP-Erschöpfung tun würden, finden Sie unter Dynamische IP-Zuordnung.

Lösung

Da Sie den CIDR-Bereich eines vorhandenen Subnetzes nicht aktualisieren können, müssen Sie über die Berechtigung zum Erstellen eines neuen Subnetzes verfügen, um dieses Problem zu beheben. Führen Sie folgende Schritte aus:

  1. Erstellen Sie ein neues Subnetz neu, das über einen größeren CIDR-Bereich verfügt, der für die Betriebsziele ausreichend ist.

  2. Erstellen Sie ein neues Subnetz, das über einen neuen nicht überlappenden Bereich verfügt.

  3. Erstellen Sie einen neuen Knotenpool im neuen Subnetz.

  4. Entwässern Sie Pods aus dem alten Knotenpool, der sich im alten Subnetz befindet, das ersetzt wird.

  5. Löschen Sie das alte Subnetz und den alten Knotenpool.

Ich habe sporadische Verbindungsfehler aufgrund der SNAT-Portausschöpfung

Bei Clustern, die relativ groß (mehr als 500 Knoten) ausgeführt werden, empfehlen wir, das NAT-Gateway (Managed Network Address Translation) von AKS für eine höhere Skalierbarkeit zu verwenden. Das Azure NAT-Gateway ermöglicht bis zu 64.512 ausgehende UDP- und TCP-Datenverkehrsflüsse pro IP-Adresse und maximal 16 IP-Adressen.

Wenn Sie keine verwaltete NAT verwenden, lesen Sie die Problembehandlung bei SNAT-Ausschöpfungen (Source Network Address Translation) und Verbindungstimeouts , um SNAT-Portausschöpfungsprobleme zu verstehen und zu beheben.

Ich kann mit dem Azure-Portal nicht auf 5.000 Knoten skalieren.

Verwenden Sie die Azure CLI, um bis zu maximal 5.000 Knoten zu skalieren, indem Sie die folgenden Schritte ausführen:

  1. Erstellen Sie eine minimale Anzahl von Knotenpools im Cluster (da die maximale Knotenpool-Knotengrenze 1.000 beträgt), indem Sie den folgenden Befehl ausführen:

    az aks nodepool add --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

  2. Skalieren Sie die Knotenpools einzeln. Legen Sie im Idealfall fünf Minuten Schlafzeit zwischen aufeinander folgenden Skalierungen von 1.000 fest. Führen Sie den folgenden Befehl aus:

    az aks nodepool scale --resource-group MyResourceGroup --name nodepool1 --cluster-name MyManagedCluster

Mein Upgrade wird ausgeführt, aber es ist langsam

In der Standardkonfiguration steigt AKS während eines Upgrades, indem die folgenden Aktionen ausgeführt werden:

  • Erstellen eines neuen Knotens
  • Skalieren des Knotenpools über die gewünschte Anzahl von Knoten um einen Knoten.

Für die Einstellungen für den maximalen Aufstand bedeutet ein Standardwert eines Knotens, dass AKS einen neuen Knoten erstellt, bevor er die vorhandenen Anwendungen entwässert und einen früheren Versionsknoten ersetzt. Mit diesem zusätzlichen Knoten kann AKS Arbeitsauslastungsunterbrechungen minimieren.

Wenn Sie Cluster mit vielen Knoten aktualisieren, kann es mehrere Stunden dauern, bis das gesamte Cluster aktualisiert wird, wenn Sie den Standardwert von max-surge. Sie können die max-surge Eigenschaft pro Knotenpool anpassen, um einen Kompromiss zwischen Upgradegeschwindigkeit und Upgradeunterbrechung zu ermöglichen. Indem Sie den maximalen Aufstandswert erhöhen, können Sie den Upgradeprozess früher abschließen. Ein großer Wert für den maximalen Anstieg kann jedoch auch während des Upgradeprozesses zu Unterbrechungen führen.

Führen Sie den folgenden Befehl aus, um den maximalen Aufstand für einen vorhandenen Knotenpool zu vergrößern oder anzupassen:

az aks nodepool update --resource-group MyResourceGroup --name mynodepool --cluster-name MyManagedCluster --max-surge 5

Es ist auch wichtig zu berücksichtigen, wie Ihre Bereitstellungseinstellungen den Abschluss des Upgrade- oder Skalierungsvorgangs verzögern können:

Tipp

Um weitere Einblicke zu diesem Verhalten zu erhalten, können Sie Fehlerdetails auf der Seite "Aktivitätsprotokoll" im Azure-Portal anzeigen oder die Ressourcenprotokolle in Ihrem Cluster überprüfen.

Mein Upgrade erreicht das Kontingentlimit (5.000 Cluster)

Informationen zum Beheben dieses Problems finden Sie unter "Erhöhen regionaler vCPU-Kontingente".

Meine interne Diensterstellung bei mehr als 750 Knoten ist aufgrund eines Timeoutfehlers langsam oder fehlgeschlagen.

Load Balancer Standard (SLB)-Back-End-Poolupdates sind ein bekannter Leistungsengpässe. Wir arbeiten an einer neuen Funktion, die eine schnellere Erstellung von Diensten und SLB im großen Maßstab ermöglicht. Um uns Ihr Feedback zu diesem Problem zu senden, lesen Sie die Azure Kubernetes-Unterstützung für den Lastenausgleich mit IP-basiertem Back-End-Pool.

Lösung

Es wird empfohlen, den Cluster auf weniger als 750 Knoten zu skalieren und dann einen internen Lastenausgleich für den Cluster zu erstellen. Erstellen Sie zum Erstellen eines internen Lastenausgleichs einen Diensttyp und azure-load-balancer-internal eine LoadBalancer Anmerkung gemäß dem folgenden Beispielverfahren.

Schritt 1: Erstellen eines internen Lastenausgleichs

Erstellen Sie zum Erstellen eines internen Lastenausgleichs ein Dienstmanifest mit dem Namen "internal-lb.yaml ", das den LoadBalancer Diensttyp und die azure-load-balancer-internal Anmerkung enthält, wie im folgenden Beispiel gezeigt:

apiVersion: v1
kind: Service
metadata:
  name: internal-app
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
  type: LoadBalancer
  ports:
  - port: 80
  selector:
    app: internal-app

Schritt 2: Bereitstellen des internen Lastenausgleichs

Stellen Sie den internen Lastenausgleich mithilfe des kubectl apply Befehls bereit, und geben Sie den Namen Ihres YAML-Manifests an, wie im folgenden Beispiel gezeigt:

kubectl apply -f internal-lb.yaml

Nachdem Ihr Cluster erstellt wurde, können Sie auch einen internen Lastenausgleich (gemäß diesem Verfahren) bereitstellen und einen internen Lastenausgleichsdienst ausführen. Auf diese Weise können Sie dem Lastenausgleich im großen Maßstab weitere Dienste hinzufügen.

Die SLB-Diensterstellung im großen Maßstab dauert die Ausführung von Stunden.

SLB-Back-End-Poolupdates sind ein bekannter Leistungsengpässe. Wir arbeiten an einer neuen Funktion, die es Ihnen ermöglicht, lastenausgleichsfähige Dienste im Großen und Umfang mit erheblich schnellerer Leistung für Erstellungs-, Aktualisierungs- und Löschvorgänge auszuführen. Um uns Ihr Feedback zu senden, lesen Sie die Azure Kubernetes-Unterstützung für den Lastenausgleich mit IP-basiertem Back-End-Pool.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.