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.
Suchen Sie mithilfe des
az aks get-upgrades
-Befehls nach verfügbaren Upgrades.az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
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
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:
- Kubernetes-Version der Clustersteuerungsebene
- 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.
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
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 (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 Service Level Agreements und der Herstellergarantie 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:
Registrieren oder aktualisieren Sie die Erweiterung
aks-preview
mithilfe des Befehlsaz extension add
oderaz extension update
.# Register the aks-preview extension az extension add --name aks-preview # Update the aks-preview extension az extension update --name aks-preview
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
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>
Ü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.
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
Ü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.
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
.kubectl apply -f nginx-toleration.yaml
Es dauert einige Sekunden, um den Pod zu planen und das NGINX-Image per Pull abzurufen.
Ü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.
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" } } ] }
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.
Azure Kubernetes Service