Verwalten von 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. Wenn Sie einen AKS-Cluster erstellen, definieren Sie die anfängliche Anzahl von Knoten und deren Größe (SKU). Wenn sich die Anwendungsanforderungen ändern, müssen Sie möglicherweise die Einstellungen für Ihre Knotenpools ändern. Beispielsweise müssen Sie die Anzahl der Knoten in einem Knotenpool skalieren oder die Kubernetes-Version eines Knotenpools aktualisieren.

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

Voraussetzungen

• Unter Erstellen von Knotenpools für einen Cluster in Azure Kubernetes Service (AKS) erfahren Sie, wie Sie Knotenpools für Ihre AKS-Cluster erstellen.
• 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.
• Überprüfen Sie die Speicheroptionen für Anwendungen in Azure Kubernetes Service, um Ihre Speicherkonfiguration zu planen.

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).
• Systempools müssen mindestens einen Knoten enthalten, während Benutzerknotenpools keine oder mehrere Knoten enthalten können.
• Sie können die VM-Größe eines Knotenpools nach der Erstellung nicht mehr ändern.
• Beim Erstellen mehrerer Knotenpools während der Clustererstellung muss die Kubernetes-Version für alle Knotenpools der für die Steuerungsebene festgelegten Version entsprechen. Sie können Updates vornehmen, nachdem Sie den Cluster mithilfe von Vorgängen pro Knotenpool bereitgestellt haben.
• Upgrade- und Skalierungsvorgänge für einen Cluster oder Knotenpool können nicht gleichzeitig ausgeführt werden. Wenn Sie versuchen, sie gleichzeitig auszuführen, erhalten Sie eine Fehlermeldung. Jeder Vorgangstyp muss für die Zielressource abgeschlossen sein, bevor die nächste Anforderung an dieselbe Ressource gerichtet werden kann. Weitere Informationen finden Sie im Leitfaden zur Problembehandlung.

Upgrade eines einzelnen Knotenpools

Hinweis

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

In diesem Beispiel wird der Knotenpool mynodepool aktualisiert. Da es zwei Knotenpools gibt, müssen wir den Befehl az aks nodepool upgrade verwenden, um ein Upgrade durchzuführen.

1. Suchen Sie mithilfe des az aks get-upgrades-Befehls nach verfügbaren Upgrades.

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

2. Aktualisieren Sie den Knotenpool mynodepool mithilfe des Befehls az aks nodepool upgrade.

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

3. Listen Sie den Status Ihrer Knotenpools mit dem Befehl az aks nodepool list auf.

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

   Die folgende Beispielausgabe zeigt, dass mynodepool den Zustand Upgrading (Wird aktualisiert) aufweist:

   [
     {
       ...
       "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 anderen 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. Kubernetes-Version der Clustersteuerungsebene
2. Ein Knotenpool mit einer Kubernetes-Version

Die Steuerungsebene ist einem oder mehreren Knotenpools zugeordnet. Das Verhalten eines Upgradevorgangs hängt davon ab, welchen Azure CLI-Befehl Sie verwenden.

• az aks upgrade aktualisiert die Steuerungsebene und alle Knotenpools im Cluster auf dieselbe Kubernetes-Version.
• az aks upgrade mit dem Flag --control-plane-only aktualisiert nur die Clustersteuerungsebene und lässt alle Knotenpools unverändert.
• az aks nodepool upgrade aktualisiert nur den Zielknotenpool mit der angegebenen Kubernetes-Version.

Validierungsregeln für Upgrades

Kubernetes-Upgrades für die Steuerungsebene und die Knotenpools eines Clusters werden mithilfe 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 Client ab. In Resource Manager-Vorlagen greift die Deklaration auf die vorhandene Version zurück, die für den Knotenpool definiert ist. Ist keine Version festgelegt, wird auf die Version der Steuerungsebene zurückgegriffen.
  • Sie können nicht gleichzeitig mehrere Vorgänge für eine einzelne Steuerungsebene oder Knotenpoolressource übermitteln. Sie können jeweils entweder eine Kontrollebene oder einen Knotenpool aktualisieren oder skalieren.

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.

1. Verwenden Sie zum Skalieren der Anzahl von Knoten in einem Knotenpool den Befehl az aks node pool scale.

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

2. Listen Sie den Status Ihrer Knotenpools mit dem Befehl az aks node pool list auf.

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

   Die folgende Beispielausgabe zeigt, dass mynodepool den Zustand Scaling (Wird skaliert) mit einer neuen Anzahl von fünf Knoten aufweist:

   [
     {
       ...
       "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 mithilfe der automatischen Clusterskalierung

AKS bietet eine separate Funktion zum automatischen Skalieren von Knotenpools mit einem als automatische Clusterskalierung bezeichneten Feature. Sie können dieses Feature mit einer eindeutigen minimalen und maximalen Anzahl von Skalierungen pro Knotenpool aktivieren

Weitere Informationen finden Sie unter Verwenden der automatischen Clusterskalierung.

Entfernen bestimmter VMs aus dem vorhandenen Knotenpool

Hinweis

Wenn Sie eine VM mit diesem Befehl löschen, führt AKS kein Absperren und Entleeren durch. Um Unterbrechungen durch die Neuplanung von Pods, die derzeit in der zu löschenden VM ausgeführt werden, zu minimieren, führen Sie vor dem Löschen der VM ein Absperren und Entleeren durch. Weitere Informationen zum Absperren und Entleeren finden Sie im Beispielszenario im Tutorial zum Ändern der Größe von Knotenpools.

1. Listen Sie die vorhandenen Knoten mithilfe des Befehls kubectl get nodes auf.

   kubectl get nodes
   

   Ihre Ausgabe sollte in etwa dem folgendem Beispiel entsprechen:

   NAME                                 STATUS   ROLES   AGE   VERSION
   aks-mynodepool-20823458-vmss000000   Ready    agent   63m   v1.21.9
   aks-mynodepool-20823458-vmss000001   Ready    agent   63m   v1.21.9
   aks-mynodepool-20823458-vmss000002   Ready    agent   63m   v1.21.9
   

2. Löschen Sie die angegebenen VMs mithilfe des Befehls az aks nodepool delete-machines. Vergessen Sie nicht, die Platzhalter durch Ihre eigenen Werte zu ersetzen.

   az aks nodepool delete-machines \
       --resource-group <resource-group-name> \
       --cluster-name <cluster-name> \
       --name <node-pool-name>
       --machine-names <vm-name-1> <vm-name-2>
   

3. Überprüfen Sie, ob die VMs mithilfe des Befehls kubectl get nodes erfolgreich gelöscht wurden.

   kubectl get nodes
   

   Ihre Ausgabe sollte die VMs, die Sie im Befehl az aks nodepool delete-machines angegeben haben, nicht mehr enthalten.

Zuordnen von Kapazitätsreservierungsgruppen zu Knotenpools

Wenn sich Ihre Workloadanforderungen ändern, können Sie vorhandene Kapazitätsreservierungsgruppen Knotenpools zuordnen, um die zugewiesene Kapazität für Ihre Knotenpools zu gewährleisten.

Voraussetzungen für die Verwendung von Kapazitätsreservierungsgruppen mit AKS

• Verwenden Sie CLI Version 2.56 oder höher und API Version 2023-10-01 oder höher.

• Die Kapazitätsreservierungsgruppe muss bereits vorhanden sein und sollte mindestens eine Kapazitätsreservierung enthalten. Andernfalls wird der Knotenpool dem Cluster mit einer Warnung hinzugefügt, und es wird keine Kapazitätsreservierungsgruppe zugeordnet. Weitere Informationen zu Kapazitätsreservierungsgruppen finden Sie hier.

• Sie müssen eine vom Benutzer zugewiesene verwaltete Identität für die Ressourcengruppe erstellen, die die Kapazitätsreservierungsgruppe (Capacity Reservation Group, CRG) enthält. Vom System zugewiesene verwaltete Identitäten funktionieren für dieses Feature nicht. Ersetzen Sie im folgenden Beispiel die Umgebungsvariablen durch Ihre eigenen Werte.

  IDENTITY_NAME=myID
  RG_NAME=myResourceGroup
  CLUSTER_NAME=myAKSCluster
  VM_SKU=Standard_D4s_v3
  NODE_COUNT=2
  LOCATION=westus2
  az identity create --name $IDENTITY_NAME --resource-group $RG_NAME  
  IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)
  

• Sie müssen die Rolle Contributor der benutzerseitig zugewiesenen Identität zuweisen, die Sie oben erstellt haben. Weitere Informationen finden Sie unter Schritte zum Hinzufügen einer Rollenzuweisung.

• Erstellen Sie einen neuen Cluster, und weisen Sie die neu erstellte Identität zu.

    az aks create \
        --resource-group $RG_NAME \
        --name $CLUSTER_NAME \
        --location $LOCATION \
        --node-vm-size $VM_SKU --node-count $NODE_COUNT \
        --assign-identity $IDENTITY_ID \
        --generate-ssh-keys 
  

• Sie können die vom Benutzer verwaltete Identität auch mit dem Aktualisierungsbefehl einem vorhandenen verwalteten Cluster zuweisen.

  az aks update \
      --resource-group $RG_NAME \
      --name $CLUSTER_NAME \
      --location $LOCATION \
      --node-vm-size $VM_SKU \
      --node-count $NODE_COUNT \
      --enable-managed-identity \
      --assign-identity $IDENTITY_ID         
  

Zuordnen einer vorhandenen Kapazitätsreservierungsgruppe zu einem Knotenpool

Ordnen Sie mithilfe des Befehls az aks nodepool add eine vorhandene Kapazitätsreservierungsgruppe zu einem Knotenpool zu, und geben Sie eine Kapazitätsreservierungsgruppe mit dem Flag --crg-id an. Im folgenden Beispiel wird davon ausgegangen, dass Sie eine CRG mit dem Namen „myCRG“ haben.

RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
az aks nodepool add --resource-group $RG_NAME --cluster-name $CLUSTER_NAME --name $NODEPOOL_NAME --crg-id $CRG_ID

Zuordnen einer vorhandenen Kapazitätsreservierungsgruppe zu einem Systemknotenpool

Um eine vorhandene Kapazitätsreservierungsgruppe zu einem Systemknotenpool zuzuordnen, ordnen Sie den Cluster der vom Benutzer zugewiesenen Identität während der Clustererstellung der Rolle "Mitwirkender" in Ihrer CRG und der CRG selbst zu. Verwenden Sie den Befehl az aks create mit den Flags --assign-identity und --crg-id.

IDENTITY_NAME=myID
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)

az aks create \
    --resource-group $RG_NAME \
    --cluster-name $CLUSTER_NAME \
    --crg-id $CRG_ID \
    --assign-identity $IDENTITY_ID \
    --generate-ssh-keys

Hinweis

Beim Löschen eines Knotenpools wird die Zuordnung dieses Knotenpools zu einer zugeordneten Kapazitätsreservierungsgruppe implizit aufgehoben, bevor der Knotenpool gelöscht wird. Beim Löschen eines Clusters wird die Zuordnung aller Knotenpools in diesem Cluster zu den zugehörigen Kapazitätsreservierungsgruppen implizit aufgehoben.

Hinweis

Sie können einen vorhandenen Knotenpool nicht mit einer Kapazitätsreservierungsgruppe aktualisieren. Der empfohlene Ansatz besteht darin, während der Erstellung des Knotenpools eine Kapazitätsreservierungsgruppe zuzuordnen.

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

Möglicherweise müssen Sie Knotenpools mit unterschiedlichen VM-Größen und Funktionen 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 Abschnitt 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.

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

1. Erstellen Sie einen Knotenpool mit dem Befehl az aks node pool add. Geben Sie 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_NC6s_v3 \
       --no-wait
   

2. Überprüfen Sie mit dem Befehl az aks nodepool list den Status des Knotenpools.

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

   Die folgende Beispielausgabe zeigt, dass der Knotenpool gpunodepool Knoten mit der angegebenen VM-Größe (VmSize) erstellt (Creating):

   [
     {
       ...
       "count": 1,
       ...
       "name": "gpunodepool",
       "orchestratorVersion": "1.15.7",
       ...
       "provisioningState": "Creating",
       ...
       "vmSize": "Standard_NC6s_v3",
       ...
     },
     {
       ...
       "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 ihm 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 mithilfe von kubectl wird nicht empfohlen.

Festlegen von Taints für Knotenpools

AKS unterstützt zwei Arten von Knotenmarkierungen: Knotenmarkierungen und Knoteninitialisierungsmarkierungen (Vorschau). Weitere Informationen finden Sie unter Verwenden von Knotenmarkierungen in einem AKS-Cluster (Azure Kubernetes Service).

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

Festlegen von Knotenpooltoleranzen

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

1. 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"
   

2. Planen Sie den Pod mit dem Befehl kubectl apply.

   kubectl apply -f nginx-toleration.yaml
   

   Es dauert einige Sekunden, um den Pod zu planen und das NGINX-Image per Pull abzurufen.

3. Überprüfen Sie mit dem Befehl kubectl describe pod den Status.

   kubectl describe pod mypod
   

   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:

   [...]
   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 mehr Knotenpools erstellen, können Sie mit Taints und Toleranzen einschränken, welche Pods für diese Knotenressourcen geplant werden können.

Festlegen von Bezeichnungen für Knotenpools

Weitere Informationen finden Sie unter Verwenden von Bezeichnungen in einem AKS-Cluster (Azure Kubernetes Service).

Festlegen von Azure-Tags für Knotenpools

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

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 ändern und diese neu bereitstellen, um Ressourcen zu aktualisieren. Bei AKS-Knotenpools können Sie das Profil des Anfangsknotenpools nicht mehr aktualisieren, 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 die Vorlage neu bereitzustellen. Stattdessen müssen Sie eine separate Resource Manager-Vorlage erstellen, über die die Knotenpools für den vorhandenen AKS-Cluster aktualisiert werden.

1. Erstellen Sie eine Vorlage wie aks-agentpools.json, und fügen Sie das folgende Beispielmanifest ein. Sie müssen die Werte nach Bedarf bearbeiten. 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.

   {
       "$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]",
                   "type": "VirtualMachineScaleSets",
                   "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                   "orchestratorVersion": "1.15.7"
               }
           }
       ]
   }
   

2. Stellen Sie die Vorlage mithilfe des Befehls az deployment group create bereit.

   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.

Nächste Schritte

• Weitere Informationen zum knotenpoolübergreifenden Steuern von Pods finden Sie unter Best Practices für erweiterte Scheduler-Funktionen in Azure Kubernetes Service (AKS).
• Verwenden Sie Näherungsplatzierungsgruppe, um die Latenz für Ihre AKS-Anwendungen zu verringern.
• Verwenden Sie öffentliche IP-Adressen auf Instanzebene, damit Ihre Knoten Datenverkehr direkt verarbeiten können.