Erstellen und Verwalten mehrerer Knotenpools für einen Cluster in Azure Kubernetes Service (AKS)

Im Azure Kubernetes Service (AKS) werden Knoten derselben Konfiguration zu Knotenpools zusammengefasst. Diese Knotenpools enthalten die zugrunde liegenden virtuellen Computer, die Ihre Anwendungen ausführen. Die anfängliche Anzahl der Knoten und ihre Größe (SKU) werden beim Erstellen eines AKS-Clusters festgelegt, der einen Systemknotenpool erstellt. Sie können zusätzliche Benutzerknotenpools erstellen, um Anwendungen mit unterschiedlichen Compute- oder Speicheranforderungen zu unterstützen. Systemknotenpools dienen dem primären Zweck, kritische Systempods wie CoreDNS und tunnelfront zu hosten. Benutzerknotenpools dienen dem primären Zweck, Ihre Anwendungspods zu hosten. Anwendungspods lassen sich jedoch auf Systemknotenpools planen, wenn Sie nur einen Pool in Ihrem AKS-Cluster haben möchten. In Benutzerknotenpools können Sie dagegen anwendungsspezifische Pods speichern. Verwenden Sie diese zusätzlichen Benutzerknotenpools z. B. zum Bereitstellen von GPUs für rechenintensive Anwendungen oder für den Zugriff auf leistungsstarken SSD-Speicher.

Hinweis

Diese Funktion ermöglicht eine höhere Kontrolle über das Erstellen und Verwalten mehrerer Knotenpools. Daher sind separate Befehle zum Erstellen, Aktualisieren und Löschen erforderlich. Für über az aks create oder az aks update ausgeführte Clustervorgänge wurde bisher die managedCluster-API verwendet, und diese Vorgänge stellten die einzige Möglichkeit zum Ändern der Steuerungsebene und eines einzelnen Knotenpools dar. Diese Funktion stellt einen separaten Vorgang für Agent-Pools über die agentPool-API zur Verfügung und erfordert die Verwendung des az aks nodepool-Befehlssatzes zum Ausführen von Vorgängen für einen einzelnen Knotenpool.

In diesem Artikel erfahren Sie, wie Sie mehrere Knotenpools in einem AKS-Cluster erstellen und verwalten.

Voraussetzungen

Azure CLI-Version 2.2.0 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

Einschränkungen

Die folgenden Einschränkungen gelten für die Erstellung und Verwaltung von AKS-Clustern, die mehrere Knotenpools unterstützen:

  • Siehe Kontingente, Größeneinschränkungen für virtuelle Computer und regionale Verfügbarkeit in Azure Kubernetes Service (AKS).
  • Systemknotenpools können Sie löschen, wenn im AKS-Cluster ein anderer Systemknotenpool als Ersatz vorhanden ist.
  • Systempools müssen mindestens einen Knoten enthalten, während Benutzerknotenpools keine oder mehrere Knoten enthalten können.
  • Der AKS-Cluster muss den Lastenausgleich mit der SKU „Standard“ nutzen, um mehrere Knotenpools verwenden zu können. Das Feature wird für Lastenausgleichsmodule der SKU „Basic“ nicht unterstützt.
  • Der AKS-Cluster muss VM-Skalierungsgruppen für die Knoten verwenden.
  • Sie können die VM-Größe eines Knotenpools nach der Erstellung nicht mehr ändern.
  • Der Name eines Knotenpools darf nur Kleinbuchstaben und Ziffern enthalten und muss mit einem Kleinbuchstaben beginnen. Bei Linux-Knotenpools muss die Länge zwischen einem und zwölf Zeichen liegen. Bei Windows-Knotenpools muss die Länge zwischen einem und sechs Zeichen betragen.
  • Alle Knotenpools müssen sich im selben virtuellen Netzwerk befinden.
  • Beim Erstellen mehrerer Knotenpools während der Clustererstellung muss die Kubernetes-Version für alle Knotenpools der für die Steuerungsebene festgelegten Version entsprechen. Dies kann nach dem Bereitstellen des Clusters mithilfe von Poolvorgängen pro Knoten aktualisiert werden.

Erstellen eines AKS-Clusters

Wichtig

Wenn Sie für Ihren AKS-Cluster nur einen Systemknotenpool in einer Produktionsumgebung ausführen, sollten Sie für den Knotenpool mindestens drei Knoten verwenden.

Erstellen Sie zu Beginn einen AKS-Cluster mit einem einzelnen Knotenpool. Im folgenden Beispiel wird der Befehl az group create verwendet, um eine Ressourcengruppe namens myResourceGroup in der Region eastus zu erstellen. Anschließend wird mit dem Befehl az aks create ein AKS-Cluster mit dem Namen myAKSCluster erstellt.

Hinweis

Die Load Balancer-SKU Basic wird bei Verwendung mehrerer Knotenpools nicht unterstützt. Standardmäßig werden AKS-Cluster mit der Lastenausgleichs-SKU Standard über die Azure-Befehlszeilenschnittstelle und das Azure-Portal erstellt.

# Create a resource group in East US
az group create --name myResourceGroup --location eastus

# Create a basic single-node AKS cluster
az aks create \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --vm-set-type VirtualMachineScaleSets \
    --node-count 2 \
    --generate-ssh-keys \
    --load-balancer-sku standard

Die Erstellung des Clusters dauert einige Minuten.

Hinweis

Um sicherzustellen, dass Ihr Cluster zuverlässig funktioniert, sollten Sie mindestens zwei (2) Knoten im Standardknotenpool ausführen, da wichtige Systemdienste in diesem Knotenpool ausgeführt werden.

Wenn der Cluster bereit ist, verwenden Sie den Befehl az aks get-credentials, um die Clusteranmeldeinformationen für die Verwendung mit kubectl zu erhalten:

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster

Hinzufügen eines Knotenpools

Der im vorherigen Schritt erstellte Cluster verfügt über einen einzelnen Knotenpool. Fügen Sie als Nächstes einen zweiten Knotenpool mit dem Befehl az aks nodepool add hinzu. Das folgende Beispiel erstellt einen Knotenpool namens mynodepool, der 3 Knoten ausführt:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3

Hinweis

Der Name eines Knotenpools muss mit einem Kleinbuchstaben beginnen und darf nur alphanumerische Zeichen enthalten. Bei Linux-Knotenpools muss die Länge zwischen einem und zwölf Zeichen liegen. Bei Windows-Knotenpools muss die Länge zwischen einem und sechs Zeichen betragen.

Um den Status Ihrer Knotenpools anzuzeigen, verwenden Sie den Befehl az aks node pool list, und geben Sie Ihre Ressourcengruppe und den Clusternamen an:

az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

Die folgende Beispielausgabe zeigt, dass mynodepool erfolgreich mit drei Knoten im Knotenpool erstellt wurde. Wenn der AKS-Cluster im vorherigen Schritt erstellt wurde, dann wurde ein Standardknotenpool (nodepool1) mit 2 Knoten erstellt.

[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Tipp

Wenn beim Hinzufügen eines Knotenpools keine VmSize angegeben ist, lautet die Standardgröße Standard_D2s_v3 für Windows-Knotenpools und Standard_DS2_v2 für Linux-Knotenpools. Wenn keine OrchestratorVersion angegeben ist, wird standardmäßig die gleiche Version wie für die Steuerungsebene verwendet.

Hinzufügen eines ARM64-Knotenpools (Vorschau)

Der ARM64-Prozessor bietet Computing mit geringer Leistung für Ihre Kubernetes-Workloads. Zum Erstellen eines ARM64-Knotenpools müssen Sie eine [ARM-fähige Instanz-SKU][arm-sku-vm] auswählen.

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Installieren der Azure-Befehlszeilenschnittstelle aks-preview

Sie benötigen außerdem die Azure CLI-Erweiterung aks-preview in der Version 0.5.23 oder höher. Installieren Sie die Erweiterung aks-preview der Azure-Befehlszeilenschnittstelle mithilfe des Befehls az extension add. Alternativ können Sie verfügbare Updates mithilfe des Befehls az extension update installieren.

# Install the aks-preview extension
az extension add --name aks-preview
# Update the extension to make sure you have the latest version installed
az extension update --name aks-preview

Registrieren der Previewfunktion AKSARM64Preview

Sie müssen darüber hinaus das Featureflag AKSARM64Preview in Ihrem Abonnement aktivieren, um dieses Feature zu verwenden.

Registrieren Sie das Featureflag AKSARM64Preview mithilfe des Befehls AKSARM64Preview, wie im folgenden Beispiel gezeigt:

az feature register --namespace "Microsoft.ContainerService" --name "AKSARM64Preview"

Es dauert einige Minuten, bis der Status Registered (Registriert) angezeigt wird. Überprüfen Sie den Registrierungsstatus mithilfe des Befehls az feature list:

az feature list -o table --query "[?contains(name, 'Microsoft.ContainerService/AKSARM64Preview')].{Name:name,State:properties.state}"

Wenn der Vorgang abgeschlossen ist, können Sie die Registrierung des Microsoft.ContainerService-Ressourcenanbieters mit dem Befehl az provider register aktualisieren:

az provider register --namespace Microsoft.ContainerService

Verwenden Sie den Befehl az aks nodepool add, um einen ARM64-Knotenpool hinzuzufügen.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name armpool \
    --node-count 3 \
    --node-vm-size Standard_Dpds_v5

Hinzufügen eines Knotenpools mit einem eindeutigen Subnetz

Eine Workload erfordert für die logische Isolation möglicherweise das Aufteilen der Knoten eines Clusters in getrennte Pools. Diese Isolation kann mit separaten Subnetzen unterstützt werden, die für die einzelnen Knotenpools im Cluster vorgesehen sind. Damit können spezifische Anforderungen erfüllt werden, wie z. B. ein nicht zusammenhängender IP-Adressraum für das virtuelle Netzwerk, der auf Knotenpools aufgeteilt ist.

Hinweis

Stellen Sie sicher, dass Sie mindestens Version 2.35.0 der Azure CLI verwenden.

Einschränkungen

  • Alle Subnetze, die Knotenpools zugewiesen sind, müssen demselben virtuellen Netzwerk angehören.
  • Systempods müssen Zugriff auf alle Knoten/Pods im Cluster haben, um eine kritische Funktionalität bereitzustellen, z. B. DNS-Auflösung und Tunneln von kubectl-Protokollen/exec/Port-Weiterleitungsproxy.
  • Wenn Sie Ihr VNET nach dem Erstellen Ihres Clusters erweitern, müssen Sie den Cluster aktualisieren (einen beliebigen verwalteten Clustervorgang ausführen, Knotenpoolvorgänge zählen jedoch nicht), bevor Sie ein Subnetz außerhalb des ursprünglichen CIDR-Bereichs hinzufügen. Wenn der Agentpool hinzugefügt wird, tritt jetzt bei AKS ein Fehler auf, obwohl wir dies ursprünglich zugelassen haben. Die Azure CLI-Erweiterung (Version 0.5.66 und höher) für aks-preview unterstützt jetzt das Ausführen von az aks update -g <resourceGroup> -n <clusterName> ohne optionale Argumente. Dieser Befehl führt einen Updatevorgang ohne Änderungen aus, sodass ein Cluster in einem fehlgeschlagenen Zustand wiederhergestellt werden kann.
  • In Clustern mit Kubernetes Version < 1.23.3 führt kube-proxy SNAT für Datenverkehr von neuen Subnetzen aus, was dazu führen kann, dass die Azure-Netzwerkrichtlinie die Pakete verwirft.
  • Windows-Knoten führen SNAT für Datenverkehr an die neuen Subnetze aus, bis ein Reimaging für den Knotenpool durchgeführt wurde.
  • Interne Lastenausgleichsmodule sind standardmäßig auf eines der Knotenpoolsubnetze festgelegt (in der Regel das erste Subnetz des Knotenpools bei der Clustererstellung). Um dieses Verhalten außer Kraft zu setzen, können Sie das Subnetz des Lastenausgleichs explizit mithilfe einer Anmerkung angeben.

Um einen Knotenpool mit einem dedizierten Subnetz zu erstellen, übergeben Sie beim Erstellen des Knotenpools die Subnetzressourcen-ID als zusätzlichen Parameter.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 3 \
    --vnet-subnet-id <YOUR_SUBNET_RESOURCE_ID>

Durchführen eines Upgrades für einen Knotenpool

Hinweis

Upgrade- und Skalierungsvorgänge für einen Cluster- oder Knotenpool können nicht gleichzeitig ausgeführt werden. Bei dem Versuch wird ein Fehler zurückgegeben. Stattdessen muss jeder Vorgangstyp für die Zielressource abgeschlossen sein, bevor eine neue Anforderung an dieselbe Ressource gerichtet werden kann. Weitere Informationen hierzu finden Sie in unserem Leitfaden zur Problembehandlung.

Mit den Befehlen in diesem Abschnitt wird gezeigt, wie ein Upgrade für einen einzelnen spezifischen Knotenpool durchgeführt wird. Die Beziehung zwischen dem Upgrade der Kubernetes-Version der Steuerungsebene und des Knotenpools wird im Abschnitt weiter unten erläutert.

Hinweis

Die Betriebssystem-Imageversion des Knotenpools ist an die Kubernetes-Version des Clusters gebunden. Upgrades für Betriebssystemimages erhalten Sie nur nach einem Clusterupgrade.

Da in diesem Beispiel zwei Knotenpools vorhanden sind, muss az aks nodepool upgrade für das Upgrade eines Knotenpools verwendet werden. Verwenden Sie az aks get-upgrades, um die verfügbaren Upgrades anzuzeigen.

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

Führen Sie für mynodepool ein Upgrade durch. Verwenden Sie den Befehl az aks nodepool upgrade, um ein Upgrade für den Knotenpool durchzuführen, wie im folgenden Beispiel gezeigt:

az aks nodepool upgrade \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --kubernetes-version KUBERNETES_VERSION \
    --no-wait

Listen Sie den Status Ihrer Knotenpools mit dem Befehl az aks node pool list erneut auf. Das folgende Beispiel zeigt, dass mynodepool den Zustand Upgrading (Wird aktualisiert) auf KUBERNETES_VERSION aufweist:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "KUBERNETES_VERSION",
    ...
    "provisioningState": "Upgrading",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Es dauert einige Minuten, bis ein Upgrade der Knoten auf die angegebene Version erfolgt ist.

Als bewährte Methode sollten Sie alle Knotenpools in einem AKS-Cluster auf dieselbe Kubernetes-Version aktualisieren. Beim Standardverhalten von az aks upgrade werden alle Knotenpools gemeinsam mit der Steuerungsebene aktualisiert, um diese Anpassung zu erzielen. Durch die Möglichkeit, ein Upgrade für einzelne Knotenpools durchzuführen, können Sie ein paralleles Upgrade durchführen und Pods zwischen Knotenpools planen, um die Anwendungsbetriebszeit innerhalb der oben genannten Einschränkungen aufrechtzuerhalten.

Aktualisieren einer Clustersteuerungsebene mit mehreren Knotenpools

Hinweis

Kubernetes verwendet als Standardversionierungsschema die semantische Versionierung. Die Versionsnummer wird im Format x.y.z angegeben. x steht dabei für die Hauptversion, y für die Nebenversion und z für die Patchversion. Ein Beispiel: Bei der Version 1.12.6 ist „1“ die Hauptversion, „12“ die Nebenversion und „6“ die Patchversion. Die Kubernetes-Versionen der Steuerungsebene und des ursprünglichen Knotenpools werden bei der Clustererstellung festgelegt. Bei allen zusätzlichen Knotenpools wird die Kubernetes-Version festgelegt, wenn sie dem Cluster hinzugefügt werden. Die Kubernetes-Versionen können sich zwischen Knotenpools sowie zwischen einem Knotenpool und der Steuerungsebene unterscheiden.

Ein AKS-Cluster verfügt über zwei Clusterressourcenobjekte mit zugeordneten Kubernetes-Versionen.

  1. Eine Kubernetes-Version der Clustersteuerungsebene
  2. Ein Knotenpool mit einer Kubernetes-Version

Eine Steuerungsebene ist einem oder mehreren Knotenpools zugeordnet. Das Verhalten eines Upgradevorgangs hängt davon ab, welcher Azure CLI-Befehl verwendet wird.

Zum Aktualisieren einer AKS-Steuerungsebene muss az aks upgrade verwendet werden. Durch diesen Befehl werden die Version der Steuerungsebene und alle Knotenpools im Cluster aktualisiert.

Beim Ausgeben des Befehls az aks upgrade mit dem Flag --control-plane-only wird nur die Clustersteuerungsebene aktualisiert. Keiner der zugeordneten Knotenpools im Cluster wird geändert.

Zum Aktualisieren einzelner Knotenpools muss az aks nodepool upgrade verwendet werden. Durch diesen Befehl wird nur der Zielknotenpool mit der angegebenen Kubernetes-Version aktualisiert.

Validierungsregeln für Upgrades

Die gültigen Kubernetes-Upgrades für die Steuerungsebene und die Knotenpools eines Clusters werden anhand der folgenden Regeln überprüft.

  • Regeln für gültige Versionen zum Aktualisieren von Knotenpools:

    • Die Knotenpoolversion muss dieselbe Hauptversion aufweisen wie die Steuerungsebene.
    • Die Nebenversion des Knotenpools muss innerhalb von zwei Nebenversionen der Version der Steuerungsebene liegen.
    • Die Version des Knotenpools darf nicht höher sein als die Version major.minor.patch der Steuerungsebene.
  • Regeln für die Übermittlung eines Upgradevorgangs:

    • Sie können die Kubernetes-Version der Steuerungsebene und die eines Knotenpools nicht herabstufen.
    • Wenn die Kubernetes-Version eines Knotenpools nicht angegeben ist, hängt das Verhalten vom verwendeten Client ab. Bei der Deklaration in Resource Manager-Vorlagen wird auf die für den Knotenpool definierte vorhandene Version zurückgegriffen, sofern sie verwendet wird. Wenn kein Wert festgelegt ist, wird die Version der Steuerungsebene verwendet.
    • Sie können eine Steuerungsebene oder einen Knotenpool zu einem bestimmten Zeitpunkt aktualisieren oder skalieren. Sie können nicht mehrere Vorgänge für eine Steuerungsebene oder einen Knotenpool gleichzeitig übermitteln.

Manuelles Skalieren eines Knotenpools

Wenn sich die Anforderungen der Workloads Ihrer Anwendungen ändern, müssen Sie möglicherweise die Anzahl der Knoten in einem Knotenpool skalieren. Die Anzahl der Knoten kann erhöht oder verringert werden.

Um die Anzahl der Knoten in einem Knotenpool zu skalieren, verwenden Sie den Befehl az aks node pool scale. Das folgende Beispiel skaliert die Anzahl der Knoten in mynodepool auf 5:

az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5 \
    --no-wait

Listen Sie den Status Ihrer Knotenpools mit dem Befehl az aks node pool list erneut auf. Das folgende Beispiel zeigt, dass mynodepool den Zustand Scaling (Wird skaliert) mit einer neuen Anzahl von 5 Knoten aufweist:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Scaling",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Es dauert einige Minuten, bis die Skalierung abgeschlossen ist.

Automatisches Skalieren eines bestimmten Knotenpools durch Aktivieren der automatischen Clusterskalierung

AKS bietet eine separate Funktion zum automatischen Skalieren von Knotenpools mit einem als automatische Clusterskalierung bezeichneten Feature. Das Feature kann mit einer eindeutigen minimalen und maximalen Anzahl von Skalierungen pro Knotenpool aktiviert werden. Erfahren Sie, wie Sie die automatische Clusterskalierung pro Knotenpool verwenden.

Löschen eines Knotenpools

Wenn Sie einen Pool nicht mehr benötigen, können Sie ihn löschen und die zugrunde liegenden VM-Knoten entfernen. Um einen Knotenpool zu löschen, verwenden Sie den Befehl az aks node pool delete, und geben Sie den Namen des Knotenpools an. Im folgenden Beispiel wird der in den vorherigen Schritten erstellte Knotenpool mynodepool gelöscht:

Achtung

Wenn Sie einen Knotenpool löschen, führt AKS kein Absperren und Ausgleichen durch, und es gibt keine Wiederherstellungsoptionen für Datenverluste, die beim Löschen eines Knotenpools auftreten können. Wenn Pods nicht in anderen Knotenpools geplant werden können, sind diese Anwendungen dann nicht mehr verfügbar. Stellen Sie sicher, dass Sie einen Knotenpool nicht löschen, wenn aktive Anwendungen keine Datensicherungen aufweisen oder nicht in anderen Knotenpools in Ihrem Cluster ausgeführt werden können. Um die Unterbrechung der Neuplanung von Pods zu minimieren, die derzeit in dem Knotenpool ausgeführt werden, den Sie löschen möchten, führen Sie vor dem Löschen eine Absperrung und einen Ausgleich auf allen Knoten im Knotenpool durch. Weitere Informationen finden Sie unter Absperren und Ausgleichen von Knotenpools.

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name mynodepool --no-wait

Die folgende Beispielausgabe des Befehls az aks node pool list zeigt, dass sich mynodepool im Zustand Deleting (Wird gelöscht) befindet:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Deleting",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Das Löschen der Knoten und des Knotenpools dauert einige Minuten.

Zuordnen von Kapazitätsreservierungsgruppen zu Knotenpools (Vorschau)

Wichtig

AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von den Vereinbarungen zum Service Level und der eingeschränkten Garantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:

Gemäß den Anforderungen Ihrer Anwendungsworkloads können Sie Knotenpools zuvor erstellten Kapazitätsreservierungsgruppen zuordnen. Dadurch wird sichergestellt, dass garantierte Kapazität für Ihre Knotenpools zugeordnet wird.

Weitere Informationen zu Kapazitätsreservierungsgruppen finden Sie unter Zuordnen einer VM-Skalierungsgruppe zu einer Kapazitätsreservierungsgruppe (Vorschau).

Ein Knotenpool kann einer vorhandenen Kapazitätsreservierungsgruppe mithilfe des Befehls az aks nodepool add zugeordnet werden, und eine Kapazitätsreservierungsgruppe kann mit dem Flag „--capacityReservationGroup“ angegeben werden. Die Kapazitätsreservierungsgruppe muss bereits vorhanden sein. Andernfalls wird der Knotenpool dem Cluster mit einer Warnung hinzugefügt, und es wird keine Kapazitätsreservierungsgruppe zugeordnet.

az aks nodepool add -g MyRG --cluster-name MyMC -n myAP --capacityReservationGroup myCRG

Ein Systemknotenpool kann einer vorhandenen Kapazitätsreservierungsgruppe mithilfe des Befehls az aks create zugeordnet werden. Wenn die angegebene Kapazitätsreservierungsgruppe nicht vorhanden ist, wird eine Warnung ausgegeben, und der Cluster wird ohne Zuordnung einer Kapazitätsreservierungsgruppe erstellt.

az aks create -g MyRG --cluster-name MyMC --capacityReservationGroup myCRG

Mit dem Befehl zum Löschen eines Knotenpools wird die Zuordnung eines Knotenpools zu einer zugeordneten Kapazitätsreservierungsgruppe implizit aufgehoben, bevor dieser Knotenpool gelöscht wird.

az aks nodepool delete -g MyRG --cluster-name MyMC -n myAP

Mit dem Befehl zum Löschen eines Clusters wird die Zuordnung aller Knotenpools in einem Cluster zu den zugehörigen Kapazitätsreservierungsgruppen implizit aufgehoben.

az aks delete -g MyRG --cluster-name MyMC

Angeben einer VM-Größe für einen Knotenpool

In den vorherigen Beispielen zur Erstellung eines Knotenpools wurde für die im Cluster erstellten Knoten eine VM-Standardgröße verwendet. Ein üblicheres Szenario ist es, Knotenpools mit unterschiedlichen VM-Größen und -Funktionen zu erstellen. Sie können z. B. einen Knotenpool erstellen, der Knoten mit einer großen Anzahl an CPUs oder mit viel Arbeitsspeicher enthält, oder einen Knotenpool, der GPU-Unterstützung bietet. Im nächsten Schritt teilen Sie dem Kubernetes-Planer durch Verwenden von Taints und Toleranzen mit, wie Sie den Zugriff auf Pods, die auf diesen Knoten ausgeführt werden können, einschränken können.

Erstellen Sie im folgenden Beispiel einen GPU-basierten Knotenpool, der die VM-Größe Standard_NC6 verwendet. Diese virtuellen Computer werden von der NVIDIA Tesla K80-Karte unterstützt. Informationen zu den verfügbaren VM-Größen finden Sie unter Größen für virtuelle Linux-Computer in Azure.

Erstellen Sie erneut einen Knotenpool mit dem Befehl az aks node pool add. Geben Sie diesmal den Namen gpunodepool und mit dem Parameter --node-vm-size die Größe Standard_NC6 an:

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name gpunodepool \
    --node-count 1 \
    --node-vm-size Standard_NC6 \
    --no-wait

Die folgende Beispielausgabe des Befehls az aks node pool list zeigt, dass gpunodepool Knoten mit der angegebenen VmSize (VM-Größe) erstellt:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 1,
    ...
    "name": "gpunodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "vmSize": "Standard_NC6",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

Es dauert einige Minuten, bis gpunodepool erfolgreich erstellt wurde.

Angeben von Taint, Bezeichnung oder Tag für einen Knotenpool

Beim Erstellen eines Knotenpools können Sie diesem Knotenpool Taints, Bezeichnungen oder Tags hinzufügen. Wenn Sie einen Taint, eine Bezeichnung oder ein Tag hinzufügen, erhalten alle Knoten innerhalb dieses Knotenpools ebenfalls diesen Taint, diese Bezeichnung oder dieses Tag.

Wichtig

Das Hinzufügen von Taints, Bezeichnungen oder Tags zu Knoten sollte für den gesamten Knotenpool mithilfe von az aks nodepool erfolgen. Das Anwenden von Taints, Bezeichnungen oder Tags auf einzelne Knoten in einem Knotenpool mit kubectl wird nicht empfohlen.

Festlegen von Knotenpooltaints

Verwenden Sie az aks nodepool add, um einen Knotenpool mit einem Taint zu erstellen. Geben Sie den Namen taintnp an, und verwenden Sie den Parameter --node-taints, um sku=gpu:NoSchedule für den Taint anzugeben.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-count 1 \
    --node-taints sku=gpu:NoSchedule \
    --no-wait

Die folgende Beispielausgabe des Befehls az aks nodepool list zeigt, dass taintnp Knoten mit dem angegebenen nodeTaintserstellt:

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster
[
  {
    ...
    "count": 1,
    ...
    "name": "taintnp",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "nodeTaints":  [
      "sku=gpu:NoSchedule"
    ],
    ...
  },
 ...
]

Die Taint-Informationen sind in Kubernetes für die Behandlung von Planungsregeln für Knoten sichtbar. Der Kubernetes-Planer kann Taints und Toleranzen verwenden, um einzuschränken, welche Workloads auf Knoten ausgeführt werden können.

  • Ein Taint wird auf einen Knoten angewendet, der anzeigt, dass nur bestimmte Pods darauf geplant werden können.
  • Für den Pod wird anschließend eine Toleranz angewendet, damit dieser den Taint des Knotens tolerieren kann.

Weitere Informationen zur Verwendung der erweiterten geplanten Kubernetes-Features finden Sie unter Best Practices für erweiterte Scheduler-Funktionen in Azure Kubernetes Service (AKS).

Im vorherigen Schritt haben Sie beim Erstellen Ihres Knotenpools den sku=gpu:NoSchedule-Taint angewendet. Das folgende einfache YAML-Beispielmanifest verwendet eine Toleranz, damit der Kubernetes-Planer einen NGINX-Pod auf einem Knoten in diesem Knotenpool ausführen kann.

Erstellen Sie eine Datei mit dem Namen nginx-toleration.yaml, und fügen Sie den folgenden YAML-Beispielcode ein:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
    name: mypod
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 1
        memory: 2G
  tolerations:
  - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

Planen Sie den Pod mit dem Befehl kubectl apply -f nginx-toleration.yaml:

kubectl apply -f nginx-toleration.yaml

Es dauert einige Sekunden, um den Pod zu planen und das NGINX-Image per Pull abzurufen. Verwenden Sie den Befehl kubectl describe pod, um den Podstatus anzuzeigen. Die folgende kompakte Beispielausgabe zeigt, dass die Toleranz sku=gpu:NoSchedule angewendet wird. Im Ereignisabschnitt hat der Planer den Pod dem Knoten aks-taintnp-28993262-vmss000000 zugewiesen:

kubectl describe pod mypod
[...]
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
                 sku=gpu:NoSchedule
Events:
  Type    Reason     Age    From                Message
  ----    ------     ----   ----                -------
  Normal  Scheduled  4m48s  default-scheduler   Successfully assigned default/mypod to aks-taintnp-28993262-vmss000000
  Normal  Pulling    4m47s  kubelet             pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Pulled     4m43s  kubelet             Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Created    4m40s  kubelet             Created container
  Normal  Started    4m40s  kubelet             Started container

Nur Pods mit dieser Toleranz können auf Knoten in taintnp geplant werden. Alle anderen Pods werden im Knotenpool nodepool1 geplant. Wenn Sie weitere Knotenpools erstellen, können Sie mit zusätzlichen Taints und Toleranzen einschränken, welche Pods für diese Knotenressourcen geplant werden können.

Festlegen von Knotenpoolbezeichnungen

Weitere Informationen zur Verwendung von Bezeichnungen mit Knotenpools finden Sie unter Verwenden von Bezeichnungen in Azure Kubernetes Service-Cluster (AKS).

Festlegen von Azure-Tags für Knotenpools

Weitere Informationen zur Verwendung von Azure-Tags mit Knotenpools finden Sie unter Verwenden von Azure-Tags in Azure Kubernetes Service (AKS).

Hinzufügen eines FIPS-fähigen Knotenpools

Der Federal Information Processing Standard (FIPS) 140-2 ist ein Standard der US-Regierung, der Mindestsicherheitsanforderungen für kryptografische Module in IT-Produkten und -Systemen definiert. AKS ermöglicht es Ihnen, Linux-basierte Knotenpools mit aktiviertem FIPS 140-2 zu erstellen. Bereitstellungen, die in FIPS-fähigen Knotenpools ausgeführt werden, können mithilfe dieser Kryptografiemodule mehr Sicherheit bieten und Sicherheitskontrollen im Rahmen der FedRAMP-Compliance erfüllen. Weitere Informationen zu FIPS 140-2 finden Sie unter Federal Information Processing Standard (FIPS) 140-2.

Voraussetzungen

Azure CLI-Version 2.32.0 oder höher muss installiert und konfiguriert sein. Führen Sie az --version aus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sei bei Bedarf unter Installieren der Azure CLI.

Bei FIPS-fähigen Knotenpools gelten die folgenden Einschränkungen:

  • Zurzeit können nur FIPS-fähige Linux-basierte Knotenpools unter Ubuntu 18.04 ausgeführt werden.
  • FIPS-fähige Knotenpools erfordern Kubernetes, Version 1.19 und höher.
  • Zur Aktualisierung der zugrunde liegenden Pakete oder Module, die für FIPS verwendet werden, müssen Sie ein Knotenimageupgrade verwenden.
  • Containerimages auf den FIPS-Knoten wurden nicht auf FIPS-Konformität bewertet.

Wichtig

Das FIPS-fähige Linux-Image ist ein anderes als das Linux-Standardimage, das bei Linux-basierten Knotenpools verwendet wird. Zur Aktivierung von FIPS für einen Knotenpool müssen Sie einen neuen Linux-basierten Knotenpool erstellen. Sie können FIPS nicht für vorhandene Knotenpools aktivieren.

FIPS-fähige Knotenimages haben möglicherweise andere Versionsnummern, z. B. die Kernelversion, als nicht-FIPS-fähige Images. Außerdem kann sich der Updatezyklus für FIPS-fähige Knotenpools und Knotenimages von nicht-FIPS-fähigen Knotenpools und -images unterscheiden.

Wenn Sie einen Knotenpool erstellen, verwenden Sie zum Erstellen eines FIPS-fähigen Knotenpools az aks nodepool add mit dem Parameter –enable-fips-image.

az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name fipsnp \
    --enable-fips-image

Hinweis

Sie können auch beim Erstellen eines Clusters den Parameter –enable-fips-image mit az aks create verwenden, um FIPS im Standardknotenpool zu aktivieren. Wenn Sie Knotenpools zu einem auf diese Weise erstellten Cluster hinzufügen, müssen Sie zum Erstellen eines FIPS-fähigen Knotenpools weiterhin den Parameter –enable-fips-image verwenden.

Wenn Sie sich vergewissern möchten, ob Ihr Knotenpool FIPS-fähig ist, verwenden Sie az aks show zur Überprüfung des Werts enableFIPS in agentPoolProfiles.

az aks show --resource-group myResourceGroup --name myAKSCluster --query="agentPoolProfiles[].{Name:name enableFips:enableFips}" -o table

Die folgende Beispielausgabe zeigt, dass der Knotenpool fipsnp FIPS-fähig und nodepool1 nicht FIPS-fähig ist.

Name       enableFips
---------  ------------
fipsnp     True
nodepool1  False  

Sie können auch überprüfen, ob Bereitstellungen Zugriff auf die FIPS-Kryptografiebibliotheken haben, indem Sie auf einem Knoten im FIPS-fähigen Knotenpool kubectl debug verwenden. Mit kubectl get nodes können Sie die Knoten auflisten:

$ kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-fipsnp-12345678-vmss000000      Ready    agent   6m4s    v1.19.9
aks-fipsnp-12345678-vmss000001      Ready    agent   5m21s   v1.19.9
aks-fipsnp-12345678-vmss000002      Ready    agent   6m8s    v1.19.9
aks-nodepool1-12345678-vmss000000   Ready    agent   34m     v1.19.9

Im vorstehenden Beispiel gehören die Knoten, deren Namen mit aks-fipsnp anfangen, zum FIPS-fähigen Knotenpool. Verwenden Sie kubectl debug zur Ausführung einer Bereitstellung bei einer interaktiven Sitzung auf einem dieser Knoten im FIPS-fähigen Knotenpool.

kubectl debug node/aks-fipsnp-12345678-vmss000000 -it --image=mcr.microsoft.com/dotnet/runtime-deps:6.0

In der interaktiven Sitzung können Sie überprüfen, ob die FIPS-Kryptografiebibliotheken aktiviert wurden:

root@aks-fipsnp-12345678-vmss000000:/# cat /proc/sys/crypto/fips_enabled
1

FIPS-fähige Knotenpools haben auch die Bezeichnung kubernetes.azure.com/fips_enabled=true, die von Bereitstellungen für diese Knotenpools verwendet werden kann.

Verwalteten von Knotenpools mithilfe einer Resource Manager-Vorlage

Wenn Sie eine Azure Resource Manager-Vorlage zum Erstellen und Verwalten von Ressourcen verwenden, können Sie die Einstellungen in Ihrer Vorlage normalerweise aktualisieren und neu bereitstellen, um die Ressource zu aktualisieren. Bei Knotenpools in AKS kann das Profil des Anfangsknotenpools nicht mehr aktualisiert werden, nachdem der AKS-Cluster erstellt wurde. Dieses Verhalten bedeutet, dass Sie eine vorhandene Resource Manager-Vorlage nicht aktualisieren können, um eine Änderung an den Knotenpools vorzunehmen und dann neu bereitzustellen. Stattdessen müssen Sie eine separate Resource Manager-Vorlage erstellen, über die nur die Knotenpools für einen vorhandenen AKS-Cluster aktualisiert werden.

Erstellen Sie eine Vorlage wie aks-agentpools.json, und fügen Sie das folgende Beispielmanifest ein. Diese Beispielvorlage konfiguriert die folgenden Einstellungen:

  • Aktualisiert den Linux-Knotenpool mit dem Namen myagentpool, sodass dieser drei Knoten ausführt.
  • Legt die Knoten im Knotenpool auf die Ausführung von Kubernetes Version 1.15.7 fest.
  • Definiert die Knotengröße als Standard_DS2_v2.

Bearbeiten Sie diese Werte nach Bedarf, um Knotenpools nach Bedarf zu aktualisieren, hinzuzufügen oder zu löschen:

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "clusterName": {
            "type": "string",
            "metadata": {
                "description": "The name of your existing AKS cluster."
            }
        },
        "location": {
            "type": "string",
            "metadata": {
                "description": "The location of your existing AKS cluster."
            }
        },
        "agentPoolName": {
            "type": "string",
            "defaultValue": "myagentpool",
            "metadata": {
                "description": "The name of the agent pool to create or update."
            }
        },
        "vnetSubnetId": {
            "type": "string",
            "defaultValue": "",
            "metadata": {
                "description": "The Vnet subnet resource ID for your existing AKS cluster."
            }
        }
    },
    "variables": {
        "apiVersion": {
            "aks": "2020-01-01"
        },
        "agentPoolProfiles": {
            "maxPods": 30,
            "osDiskSizeGB": 0,
            "agentCount": 3,
            "agentVmSize": "Standard_DS2_v2",
            "osType": "Linux",
            "vnetSubnetId": "[parameters('vnetSubnetId')]"
        }
    },
    "resources": [
        {
            "apiVersion": "2020-01-01",
            "type": "Microsoft.ContainerService/managedClusters/agentPools",
            "name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
            "location": "[parameters('location')]",
            "properties": {
                "maxPods": "[variables('agentPoolProfiles').maxPods]",
                "osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
                "count": "[variables('agentPoolProfiles').agentCount]",
                "vmSize": "[variables('agentPoolProfiles').agentVmSize]",
                "osType": "[variables('agentPoolProfiles').osType]",
                "storageProfile": "ManagedDisks",
                "type": "VirtualMachineScaleSets",
                "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                "orchestratorVersion": "1.15.7"
            }
        }
    ]
}

Stellen Sie diese Vorlage wie im folgenden Beispiel gezeigt mithilfe des Befehls az deployment group create bereit. Sie werden zur Eingabe des Namens und Speicherorts des vorhandenen AKS-Clusters aufgefordert:

az deployment group create \
    --resource-group myResourceGroup \
    --template-file aks-agentpools.json

Tipp

Sie können Ihrem Knotenpool ein Tag hinzufügen, indem Sie die tag-Eigenschaft in der Vorlage hinzufügen, wie im folgenden Beispiel gezeigt.

...
"resources": [
{
  ...
  "properties": {
    ...
    "tags": {
      "name1": "val1"
    },
    ...
  }
}
...

Es kann ein paar Minuten dauern, bis Ihr AKS-Cluster aktualisiert wird, abhängig von den Knoteneinstellungen und Vorgängen, die Sie in Ihrer Resource Manager-Vorlage definieren.

Zuweisen einer öffentlichen IP-Adresse pro Knoten in Ihren Knotenpools

AKS-Knoten benötigen keine eigene öffentliche IP-Adresse für die Kommunikation. In einigen Szenarien müssen Knoten in einem Knotenpool jedoch möglicherweise jeweils eine eigene dedizierte öffentliche IP-Adresse erhalten. Ein häufiges Szenario hierfür sind Gamingworkloads, bei denen eine Konsole eine direkte Verbindung mit einem virtuellen Cloudcomputer herstellen muss, um Hops zu minimieren. Dieses Szenario kann in AKS durch öffentliche IP-Adressen für Knoten erzielt werden.

Erstellen Sie zunächst eine neue Ressourcengruppe.

az group create --name myResourceGroup2 --location eastus

Erstellen Sie einen neuen AKS-Cluster, und fügen Sie an Ihre Knoten eine öffentliche IP-Adresse an. Jeder Knoten im Knotenpool erhält eine eindeutige öffentliche IP-Adresse. Sie können dies überprüfen, indem Sie sich die VM-Skalierungsgruppeninstanzen ansehen.

az aks create -g MyResourceGroup2 -n MyManagedCluster -l eastus  --enable-node-public-ip

Bei vorhandenen AKS-Clustern können Sie auch einen neuen Knotenpool hinzufügen und eine öffentliche IP-Adresse an Ihre Knoten anfügen.

az aks nodepool add -g MyResourceGroup2 --cluster-name MyManagedCluster -n nodepool2 --enable-node-public-ip

Präfix für öffentliche IP-Adressen verwenden

Es gibt viele Vorteile bei der Verwendung eines öffentlichen IP-Präfixes. AKS unterstützt die Verwendung von Adressen aus einem vorhandenen öffentlichen IP-Präfix für Ihre Knoten durch das Übergeben der Ressourcen-ID mit dem Flag node-public-ip-prefix Erstellen eines neuen Clusters oder durch Hinzufügen eines Knoten-Pools.

Erstellen Sie zunächst mit AZ Network Public-IP Prefixein öffentliches IP-Präfix:

az network public-ip prefix create --length 28 --location eastus --name MyPublicIPPrefix --resource-group MyResourceGroup3

Sehen Sie sich die Ausgabe an, und notieren Sie sich die id für das Präfix:

{
  ...
  "id": "/subscriptions/<subscription-id>/resourceGroups/myResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix",
  ...
}

Wenn Sie einen neuen Cluster erstellen oder einen neuen Knoten-Pool hinzufügen, verwenden Sie schließlich das node-public-ip-prefix-Flag und übergeben Sie die Ressourcen-ID des Präfixes:

az aks create -g MyResourceGroup3 -n MyManagedCluster -l eastus --enable-node-public-ip --node-public-ip-prefix /subscriptions/<subscription-id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix

Öffentliche IPS für Knoten suchen

Sie können die öffentlichen IP-Adressen Ihrer Knoten auf verschiedene Weise ermitteln:

Wichtig

Die Knotenressourcengruppe enthält die Knoten und deren öffentlichen IP-Adressen. Verwenden Sie die Knotenressourcengruppe, wenn Sie Befehle ausführen, um die öffentlichen IP-Adressen Ihrer Knoten zu ermitteln.

az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName

Bereinigen von Ressourcen

In diesem Artikel haben Sie einen AKS-Cluster erstellt, der GPU-basierte Knoten enthält. Um unnötige Kosten zu reduzieren, können Sie gpunodepool oder den gesamten AKS-Cluster löschen.

Verwenden Sie zum Löschen des GPU-basierten Knotenpools den Befehl az aks nodepool delete, wie im folgenden Beispiel gezeigt:

az aks nodepool delete -g myResourceGroup --cluster-name myAKSCluster --name gpunodepool

Wenn Sie den Cluster selbst löschen möchten, verwenden Sie den Befehl az group delete, um die AKS-Ressourcengruppe zu löschen:

az group delete --name myResourceGroup --yes --no-wait

Sie können auch den zusätzlichen Cluster löschen, den Sie für das Szenario für öffentliche IP-Adressen für Knotenpools erstellt haben.

az group delete --name myResourceGroup2 --yes --no-wait

Nächste Schritte

Weitere Informationen zu Systemknotenpools.

In diesem Artikel haben Sie erfahren, wie Sie mehrere Knotenpools in einem AKS-Cluster erstellen und verwalten. Weitere Informationen zum knotenpoolübergreifenden Steuern von Pods finden Sie unter Best Practices für erweiterte Scheduler-Funktionen in Azure Kubernetes Service (AKS).

Informationen zum Erstellen und Verwenden von Windows Server-Containerknotenpools finden Sie unter Erstellen eines Windows Server-Containers in AKS.

Verwenden Sie Näherungsplatzierungsgruppe, um die Latenz für Ihre AKS-Anwendungen zu verringern.