Freigeben über

Ressourcenbeschränkungen, VM-Größen und Regionen für von Azure Arc aktivierte AKS

  • Artikel

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Dieser Artikel enthält Informationen zu getesteten Konfigurationen, Ressourcengrenzwerten, VM-Größen und Regionen für Azure Kubernetes Service (AKS), die von Azure Arc aktiviert sind. Die Tests verwendeten die neueste Version von AKS auf Azure Local.

Maximale Spezifikationen

AKS, die von Arc-Bereitstellungen aktiviert wurden, wurden mit den folgenden Konfigurationen überprüft, einschließlich der angegebenen Höchstwerte. Beachten Sie, dass das Überschreiten dieser Höchstwerte auf eigene Gefahr erfolgt und zu unerwartetem Verhalten und Fehlern führen kann. Dieser Artikel bietet Anleitungen, um häufige Konfigurationsfehler zu vermeiden, und kann beim Erstellen einer größeren Konfiguration helfen. Wenden Sie sich im Zweifelsfall an Ihr lokales Microsoft-Büro, um Hilfe zu erhalten, oder senden Sie eine Frage in der lokalen Azure-Community.

Resource Maximum
Physische Server pro Cluster 8
Gesamtzahl der virtuellen Computer 200

Die empfohlenen Grenzwerte wurden basierend auf der folgenden Tabelle mit den Standardgrößen für virtuelle Computer (VM) getestet:

Systemrolle Größe des virtuellen Computers
AKS-Host Standard_A4_v2
Zielclustersteuerungsknoten Standard
Zielcluster-HAProxy-Lastenausgleich (optional) Standard_A4_v2
Zielcluster-Linux-Workerknoten Standard_K8S3_v1
Zielcluster-Windows-Workerknoten Standard_K8S3_v1

Die Hardwarekonfiguration der einzelnen physischen Knoten im lokalen Azure-Cluster lautet wie folgt:

  • Chassis: Dell PowerEdge R650 Server oder ähnlich.
  • RAM: RDIMM, 3200 MT/s, Dual Rank, gesamt 256 GB.
  • CPU: Zwei (2) Intel You Silver 4316 2.3G, 20C/40T, 10.4 GT/s, 30M Cache, Turbo, HT (150 W) DDR4-2666.
  • Datenträger: 8x HDDs (2 TB oder größer) und 2x 1,6 TB NVMe zur Unterstützung von S2D-Speicherkonfigurationen.
  • Netzwerk: Vier (4) 100-Gbit-NICs (Mellanox oder Intel).

Microsoft Engineering testete AKS, die von Arc mit der oben genannten Konfiguration aktiviert wurden. Für einen einzelnen Knoten. 2 Knoten, 4 Knoten und 8 Knoten Windows-Failovercluster. Wenn Sie eine Anforderung haben, die getestete Konfiguration zu überschreiten, lesen Sie die Skalierungs-AKS auf Azure Local.

Wichtig

Wenn Sie eine Bereitstellung von AKS aktualisieren, werden zusätzliche Ressourcen vorübergehend verbraucht. Jeder virtuelle Computer wird in einem rollierenden Updatefluss aktualisiert, beginnend mit den Steuerebenenknoten. Für jeden Knoten im Kubernetes-Cluster wird eine neue Knoten-VM erstellt. Die alte Knoten-VM ist eingeschränkt, um zu verhindern, dass Workloads darauf bereitgestellt werden. Der eingeschränkte virtuelle Computer wird dann von allen Containern entwässert, um die Container an andere virtuelle Computer im System zu verteilen. Der entwässerte virtuelle Computer wird dann aus dem Cluster entfernt, heruntergefahren und durch den neuen, aktualisierten virtuellen Computer ersetzt. Dieser Vorgang wird wiederholt, bis alle virtuellen Computer aktualisiert werden.

Verfügbare VM-Größen

Die folgenden VM-Größen für die Steuerung von Ebenenknoten, Linux-Workerknoten und Windows-Workerknoten sind für AKS auf Azure Local verfügbar. Während VM-Größen wie Standard_K8S2_v1 und Standard_K8S_v1 für Tests und bereitstellungen geringer Ressourcenanforderungen unterstützt werden, verwenden Sie diese Größen sorgfältig, und wenden Sie strenge Tests an, da sie aufgrund von Arbeitsspeicherbedingungen zu unerwarteten Fehlern führen können.

Größe des virtuellen Computers CPU Arbeitsspeicher (GB) GPU-Typ GPU-Anzahl
Standard 4 4
Standard_A2_v2 2 4
Standard_A4_v2 4 8
Standard_D2s_v3 2 8
Standard_D4s_v3 4 16
Standard_D8s_v3 8 32
Standard_D16s_v3 16 64
Standard_D32s_v3 32 128
Standard_DS2_v2 2 7
Standard_DS3_v2 2 14
Standard_DS4_v2 8 28
Standard_DS5_v2 16 56
Standard_DS13_v2 8 56
Standard_K8S_v1 4 2
Standard_K8S2_v1 2 2
Standard_K8S3_v1 4 6
Standard_NK6 6 12 Tesla T4 1
Standard_NK12 12 24 Tesla T4 2

Unterstützte Azure-Regionen für die Azure-Registrierung

Von Arc aktivierte AKS werden in den folgenden Azure-Regionen unterstützt:

  • Australien (Osten)
  • East US
  • Asien, Südosten
  • Europa, Westen

Skalieren von AKS auf Azure Local

Die Skalierung einer AKS-Bereitstellung auf Azure Local umfasst die Planung voraus, indem Sie Ihre Workloads und die Zielclusternutzung kennen. Berücksichtigen Sie außerdem Hardwareressourcen in Ihrer zugrunde liegenden Infrastruktur, z. B. gesamter CPU-Kern, Gesamtspeicher, Speicher, IP-Adressen usw.

In den folgenden Beispielen wird davon ausgegangen, dass nur AKS-basierte Workloads in der zugrunde liegenden Infrastruktur bereitgestellt werden. Durch die Bereitstellung von Nicht-AKS-Workloads wie eigenständigen oder gruppierten virtuellen Computern oder Datenbankservern werden die verfügbaren Ressourcen für AKS reduziert, die Sie berücksichtigen müssen.

Bevor Sie beginnen, sollten Sie die folgenden Punkte berücksichtigen, um die maximale Skalierung und die Anzahl der Zielcluster zu ermitteln, die Sie unterstützen müssen:

  • Die Anzahl der IP-Adressen, die für Pods in einem Zielcluster verfügbar sind.
  • Die Anzahl der IP-Adressen, die für Kubernetes-Dienste in einem Zielcluster verfügbar sind.
  • Die Anzahl der Pods, die Sie zum Ausführen Ihrer Workloads benötigen.

Um die Größe Ihrer Azure Kubernetes-Diensthost-VM zu ermitteln, müssen Sie die Anzahl der Workerknoten und Zielcluster kennen, da die Größe der AKS-Host-VM bestimmt wird. Zum Beispiel:

  • Die Anzahl der Zielcluster im endgültig bereitgestellten System.
  • Die Anzahl der Knoten, einschließlich Steuerebene, Lastenausgleich und Arbeitsknoten über alle Zielcluster hinweg.

Hinweis

Ein einzelner AKS-Host kann Zielcluster nur auf derselben Plattform verwalten.

Um die Größe des Zielcluster-Steuerungsebenenknotens zu ermitteln, müssen Sie auch die Anzahl der Pods, Container und Workerknoten kennen, die Sie in jedem Zielcluster bereitstellen möchten.

Standardeinstellungen, die derzeit in AKS nicht geändert werden können

Für die Kundensteuerung während oder nach der Bereitstellung sind derzeit keine Standardkonfigurationen und Einstellungen verfügbar. Diese Einstellungen können die Skalierung für einen bestimmten Zielcluster einschränken.

  • Die Anzahl der IP-Adressen für Kubernetes-Pods in einem Zielcluster ist auf das Subnetz 10.244.0.0/16 beschränkt. Das heißt, 255 IP-Adressen pro Workerknoten in allen Kubernetes-Namespaces können für Pods verwendet werden. Verwenden Sie den folgenden Befehl in PowerShell, um die Pod-CIDR zu sehen, die jedem Workerknoten in Ihrem Cluster zugewiesen ist:
kubectl get nodes -o json | findstr 'hostname podCIDR'

                    "kubernetes.io/hostname": "moc-lip6cotjt0f",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.2.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-lmb6zqozk4m",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.4.0/24",
                "podCIDRs": [
                    "kubernetes.io/hostname": "moc-wgwhhijxtfv",
                                "f:podCIDR": {},
                                "f:podCIDRs": {
                                    "f:kubernetes.io/hostname": {},
                "podCIDR": "10.244.5.0/24",
                "podCIDRs": [

Im Beispiel sehen Sie drei Knoten mit drei CIDRs, die jeweils 254 Pods hosten können. Die Kubernetes-Skalierungsdokumentation empfiehlt, aus Leistungsgründen 110 Pods pro Knoten nicht zu überschreiten. Weitere Informationen zu großen Clustern finden Sie unter "Überlegungen".

Weitere Überlegungen:

  • Die Anzahl der IP-Adressen für Kubernetes-Dienste außerhalb des vip-Pools, den Sie zugewiesen haben, stammen aus dem 10.96.0.0/16 Adresspool. Das System verwendet eine der 255 verfügbaren Adressen für den Kubernetes-API-Server.
  • Die Größe der AKS-Host-VM kann nur bei der Installation festgelegt werden, wenn Sie Set-AksHciConfig zum ersten Mal ausführen. Sie können ihn später nicht mehr ändern.
  • Sie können nur die Größe der Zielclustersteuerungsebene und VMs zum Lastenausgleich zum Zeitpunkt der Erstellung des Zielclusters festlegen.

Skalierungsbeispiel

Das folgende Skalierungsbeispiel basiert auf diesen allgemeinen Annahmen/Anwendungsfällen:

  • Sie möchten den Verlust eines physischen Knotens im lokalen Azure-Cluster vollständig tolerieren können.
  • Sie möchten das Upgrade von Zielclustern auf neuere Versionen unterstützen.
  • Sie möchten eine hohe Verfügbarkeit der Zielclustersteuerungsebenenknoten und Lastenausgleichsknoten ermöglichen.
  • Sie möchten einen Teil der gesamten lokalen Azure-Kapazität für diese Fälle reservieren.

Vorschläge

  • Stellen Sie für eine optimale Leistung sicher, dass Sie mindestens 15 Prozent (100/8=12,5) der Clusterkapazität festlegen, damit alle Ressourcen von einem physischen Knoten auf die anderen sieben (7) Knoten verteilt werden können. Diese Konfiguration stellt sicher, dass Sie einige Reserven haben, um ein Upgrade oder einen anderen AKS-Tag zwei Vorgänge auszuführen.

  • Wenn Sie den Grenzwert von 200 VM für einen maximal acht (8) Knoten azure Local cluster überschreiten möchten, erhöhen Sie die Größe der AKS-Host-VM. Die Verdoppelung der Größe führt zu etwa doppelter Anzahl von virtuellen Computern, die verwaltet werden können. In einem lokalen Azure-Cluster mit 8 Knoten können Sie auf VMs mit 8.192 (8x1024) basierend auf den in den maximal unterstützten Hardwarespezifikationen dokumentierten lokalen Ressourcengrenzwerten von Azure abrufen. Sie sollten ungefähr 30 % der Kapazität reservieren, was Sie mit einem theoretischen Grenzwert von 5.734 VMs über alle Knoten hinaus lässt.

    • Standard_D32s_v3 kann für den AKS-Host mit 32 Kernen und 128 GB maximal 1.600 Knoten unterstützt werden.

    Hinweis

    Da diese Konfiguration nicht umfassend getestet wurde, ist ein sorgfältiger Ansatz und eine sorgfältige Überprüfung erforderlich.

  • In einer ähnlichen Skalierung möchten Sie die Umgebung möglicherweise in mindestens 8 Zielcluster mit jeweils 200 Arbeitsknoten aufteilen.

  • Um 200 Workerknoten in einem Zielcluster auszuführen, können Sie die Standardgröße der Steuerungsebene und des Lastenausgleichs verwenden. Je nach Anzahl der Pods pro Knoten können Sie mindestens eine Größe auf der Steuerebene nach oben gehen und Standard_D8s_v3 verwenden.

  • Abhängig von der Anzahl der kubernetes-Dienste, die in jedem Zielcluster gehostet werden, müssen Sie möglicherweise die Größe der VM für das Lastenausgleichsmodul erhöhen und bei der Zielclustererstellung sicherstellen, dass Dienste mit hoher Leistung erreicht werden können und der Datenverkehr entsprechend weitergeleitet wird.

Die Bereitstellung von von Arc aktivierten AKS verteilt die Arbeitsknoten für jeden Knotenpool in einem Zielcluster über die verfügbaren lokalen Azure-Knoten mithilfe der Azure Local Placement-Logik.

Wichtig

Die Knotenplatzierung wird während der Plattform- und AKS-Upgrades nicht beibehalten und ändert sich im Laufe der Zeit. Ein fehlerhafter physischer Knoten wirkt sich auch auf die Verteilung virtueller Computer über die verbleibenden Clusterknoten aus.

Hinweis

Führen Sie nicht mehr als vier Zielclustererstellungen gleichzeitig aus, wenn der physische Cluster bereits 50 % voll ist, da dies zu temporären Ressourcenkonflikten führen kann. Berücksichtigen Sie beim Skalieren von Zielclusterknotenpools durch große Zahlen die verfügbaren physischen Ressourcen, da AKS die Ressourcenverfügbarkeit für parallel ausgeführte Erstellungs-/Skalierungsprozesse nicht überprüft. Stellen Sie immer genügend Reserve sicher, um Upgrades und Failover zu ermöglichen. Insbesondere in sehr großen Umgebungen können diese Vorgänge parallel ausgeführt werden, zu einer schnellen Ressourcenauslastung führen.

Wenden Sie sich im Zweifelsfall an Ihr lokales Microsoft-Büro, um Hilfe zu erhalten oder im Lokalen Communityforum von Azure zu posten.

Nächste Schritte