Gérer des pools de nœuds pour un cluster dans Azure Kubernetes Service (AKS)

Article
08/10/2023

Dans Azure Kubernetes Service (AKS), les nœuds d’une même configuration sont regroupés dans des pools de nœuds. Ces pools de nœuds contiennent les machines virtuelles sous-jacentes qui exécutent vos applications. Lorsque vous créez un cluster AKS, vous définissez le nombre initial de nœuds et leur taille (SKU). À mesure que les demandes des applications changent, vous devrez peut-être modifier les paramètres de vos pools de nœuds. Par exemple, vous devrez peut-être mettre à l’échelle le nombre de nœuds dans un pool de nœuds ou mettre à niveau la version Kubernetes d’un pool de nœuds.

Cet article vous montre comment gérer un ou plusieurs pools de nœuds dans un cluster AKS.

Avant de commencer

Consultez Créer des pools de nœuds pour un cluster dans Azure Kubernetes Service (AKS) pour savoir comment créer des pools de nœuds pour vos clusters AKS.
La version 2.2.0 (ou ultérieure) d’Azure CLI doit être installée et configurée. Exécutez az --version pour trouver la version. Si vous devez installer ou mettre à niveau, voir Installer Azure CLI.
Consultez Options de stockage pour les applications dans Azure Kubernetes Service pour planifier votre configuration de stockage.

Limites

Les limitations suivantes s’appliquent lorsque vous créez et gérez les clusters AKS prenant en charge plusieurs pools de nœuds :

Voir Quotas, restrictions de taille de machine virtuelle et disponibilité des régions dans Azure Kubernetes Service (AKS).
Les pools de système doivent contenir au moins un nœud, et les pools de nœuds de l’utilisateur peuvent contenir zéro ou plusieurs nœuds.
Vous ne pouvez pas changer la taille des machines virtuelles d’un pool de nœuds, une fois que vous l’avez créé.
Lorsque vous créez plusieurs pools de nœuds au moment de la création du cluster, assurez-vous que toutes les versions de Kubernetes utilisées par les pools de nœuds correspondent à la version définie pour le plan de contrôle. Vous pouvez effectuer des mises à jour après l’approvisionnement du cluster à l’aide des opérations par pool de nœuds.
Vous ne pouvez pas exécuter simultanément des opérations de mise à niveau et de mise à l’échelle sur un cluster ou un pool de nœuds. Si vous tentez de les exécuter en même temps, vous allez recevoir une erreur. Chaque type d’opération doit être terminé sur la ressource cible avant l’exécution de la demande suivante sur cette même ressource. Pour plus d’informations, consultez le guide de résolution des problèmes.

Mettre à niveau un pool de nœuds unique

Notes

La version de l'image de système d'exploitation du pool de nœuds est liée à la version Kubernetes du cluster. Vous n'obtiendrez les mises à niveau de l'image de système d'exploitation qu'après une mise à niveau du cluster.

Dans cet exemple, nous mettons à niveau le pool de nœuds mynodepool . Étant donné qu’il existe deux pools de nœuds, nous devons utiliser la commande az aks nodepool upgrade pour effectuer la mise à niveau.

Vérifiez les mises à niveau disponibles à l’aide de la commande az aks get-upgrades.
```
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster
```

Mettez à niveau le pool de nœuds mynodepool à l’aide de la commande az aks nodepool upgrade.

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

Listez l’état de vos pools de nœuds à l’aide de la commande az aks nodepool list.

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

L’exemple de sortie suivant montre que mynodepool est dans l’état Mise à niveau :

[
  {
    ...
    "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",
    ...
  }
]

Il faut quelques minutes pour mettre à niveau les nœuds vers la version spécifiée.

En guise de bonne pratique, vous devez mettre à niveau tous les pools de nœuds dans un cluster AKS vers la même version de Kubernetes. Le comportement par défaut de az aks upgrade est de mettre à niveau tous les pools de nœuds en même temps que le plan de contrôle pour obtenir cet alignement. La possibilité de mettre à niveau les pools de nœuds individuels vous permet d’effectuer une mise à niveau propagée et de planifier des pods entre les pools de nœuds pour maintenir la disponibilité des applications au sein des contraintes susmentionnées.

Mettre à niveau un plan de contrôle de cluster avec plusieurs pools de nœuds

Notes

Kubernetes utilise le schéma de contrôle de version standard Semantic Versioning. Le numéro de version est exprimé par x.y.z, où x est la version principale, y est la version secondaire et z est la version du correctif. Par exemple, dans la version 1.12.6, 1 est la version principale, 12 est la version secondaire, et 6 est la version du correctif. La version Kubernetes du plan de contrôle et le pool de nœuds initial sont définis lors de la création du cluster. Tous les pools de nœuds supplémentaires ont leur version Kubernetes définie lorsqu'ils sont ajoutés au cluster. Les versions Kubernetes peuvent différer entre les pools de nœuds. Elles peuvent également différer entre un pool de nœuds et le plan de contrôle.

Un cluster AKS possède deux objets de ressource de cluster avec des versions Kubernetes qui leur sont associées :

La version Kubernetes du plan de contrôle du cluster et
Pool de nœuds avec une version de Kubernetes.

Le plan de contrôle est mappé à un ou plusieurs pools de nœuds. Le comportement d’une opération de mise à niveau dépend de la commande Azure CLI que vous utilisez.

az aks upgrade met à niveau le plan de contrôle et tous les pools de nœuds du cluster vers la même version Kubernetes.
az aks upgrade avec l’indicateur --control-plane-only met uniquement à niveau le plan de contrôle du cluster et laisse tous les pools de nœuds inchangés.
az aks nodepool upgrade met uniquement à niveau le pool de nœuds cible avec la version Kubernetes spécifiée.

Règles de validation pour les mises à niveau

Les mises à niveau valides de Kubernetes du plan de contrôle ou des pools de nœuds d’un cluster sont validées par les ensembles de règles suivants :

Règles des versions valides pour la mise à jour des pools de nœuds :
- La version du pool de nœuds doit avoir la même version principale que le plan de contrôle.
- La version secondaire du pool de nœuds doit être située à deux versions secondaires de la version du plan de contrôle.
- La version du pool de nœuds ne peut pas être supérieure à la version du major.minor.patch de contrôle.
Règles pour l’envoi d’une opération de mise à niveau ::
- Vous ne pouvez pas passer à une version de Kubernetes antérieure pour le plan de contrôle ou le pool de nœuds.
- Si une version Kubernetes de pool de nœuds n’est pas spécifiée, le comportement peut varier en fonction du client. Dans les modèles Resource Manager, la déclaration revient à la version existante définie pour le pool de nœuds. Si rien n’est défini, il utilise la version du plan de contrôle pour s’assurer.
- Vous ne pouvez pas envoyer simultanément plusieurs opérations sur un seul plan de contrôle ou une ressource de pool de nœuds. Vous pouvez mettre à niveau ou mettre à l'échelle un plan de contrôle ou un pool de nœuds à un moment donné.

Mettre manuellement à l'échelle un pool de nœuds

Lorsque vos exigences de charge de travail d’application changent, vous pouvez être amené à mettre à l’échelle le nombre de nœuds dans un pool de nœuds. Le nombre de nœuds peut être augmenté ou diminué.

Mettez à l’échelle le nombre de nœuds dans un pool de nœuds à l’aide de la commande az aks node pool scale.

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

Listez l’état de vos pools de nœuds à l’aide de la commande az aks node pool list.

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

L’exemple de sortie suivant montre que mynodepool est dans l’état Mise à l’échelle avec une nouvelle valeur de cinq nœuds :

[
  {
    ...
    "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",
    ...
  }
]

L’opération de mise à l’échelle peut prendre quelques minutes.

Mettre automatiquement à l’échelle un pool de nœuds spécifique à l’aide de la fonctionnalité mise à l’échelle automatique du cluster

AKS offre une fonctionnalité distincte pour mettre automatiquement à l’échelle les pools de nœuds avec une fonctionnalité appelée mise à l’échelle automatique du cluster. Vous pouvez activer cette fonctionnalité avec un nombre d’échelles minimal et maximal unique par pool de nœuds.

Pour plus d’informations, consultez Utiliser la mise à l’échelle automatique du cluster.

Associer des groupes de réservations de capacité à des pools de nœuds

À mesure que les demandes de votre charge de travail évoluent, vous pouvez associer des groupes de réservations de capacité existants à des pools de nœuds pour assurer la capacité allouée à vos pools de nœuds.

Prérequis pour utiliser des groupes de réservations de capacité avec AKS

Utilisez l’interface CLI version 2.56 ou supérieure et l’API version 2023-10-01 ou supérieure.
Le groupe de réservations de capacité doit déjà exister et contenir au minimum une réservation de capacité. À défaut, le pool de nœuds est ajouté au cluster avec un avertissement et aucun groupe de réservations de capacité n’est associé. Pour plus d’informations, consultez Groupes de réservation de capacité.
Vous devez créer une identité managée affectée par l’utilisateur pour le groupe de ressources qui contient le groupe de réservations de capacité (CRG). Les identités managées affectées par le système ne fonctionnent pas pour cette fonctionnalité. Dans l’exemple suivant, remplacez les variables suivantes par vos propres valeurs.
```
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)
```
Vous devez attribuer le rôle Contributor à l’identité affectée par l’utilisateur créée ci-dessus. Pour plus d’informations, consultez Procédure d’attribution d’un rôle Azure.

Créez un cluster et attribuez l’identité nouvellement créée.

  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 --enable-managed-identity

Vous pouvez également attribuer l’identité managée par l’utilisateur sur un cluster managé existant avec la commande de mise à jour (update).

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

Associer un groupe de réservations de capacité existant à un pool de nœuds

Associez un groupe de réservations de capacité existant à un pool de nœuds à l’aide de la commande az aks nodepool add et spécifiez un groupe de réservations de capacité avec l’indicateur --crg-id. L’exemple suivant suppose que vous disposez d’un groupe CRG nommé « myCRG ».

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

Associer un groupe de réservations de capacité existant à un pool de nœuds système

Pour associer un groupe de réservations de capacité existant à un pool de nœuds système, associez le cluster à l’identité affectée par l’utilisateur ayant le rôle Contributeur dans votre groupe CRG et le CRG lui-même lors de la création du cluster. Utilisez la commande az aks create avec les indicateurs --assign-identity et --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 --enable-managed-identity

Remarque

La suppression d’un de pool de nœuds dissocie implicitement ce pool de nœuds de n’importe quel groupe de réservation de capacité associé, avant la suppression du pool de nœuds. La suppression d’un cluster dissocie implicitement tous les pools de nœuds de ce cluster de leurs groupes de réservation de capacité associés.

Remarque

Vous ne pouvez pas mettre à jour un pool de nœuds existant avec un groupe de réservations de capacité. L’approche recommandée consiste à associer un groupe de réservations de capacité pendant la création du pool de nœuds.

Spécifier une taille de machine virtuelle pour un pool de nœuds

Vous devrez peut-être créer des pools de nœuds avec différentes tailles et fonctionnalités de machine virtuelle. Par exemple, vous pouvez créer un pool de nœuds contenant des nœuds avec de grandes quantités de mémoire ou de processeur, ou un pool de nœuds fournissant une prise en charge de GPU. Dans la section suivante, vous allez utiliser des teintes et des tolérances pour indiquer au planificateur Kubernetes comment limiter l’accès aux pods qui peuvent s’exécuter sur ces nœuds.

Dans l’exemple suivant, nous créons un pool de nœuds basé sur un processeur graphique, qui utilise la taille VM Standard_NC6s_v3. Ces machines virtuelles sont alimentées par la carte NVIDIA Tesla K80. Pour plus d’information, consultez Tailles disponibles des machines virtuelles Linux dans Azure.

Créez un pool de nœuds à l’aide de la commande az aks node pool add. Spécifiez le nom gpunodepool et utilisez le paramètre --node-vm-size pour spécifier la taille Standard_NC6.

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

Vérifiez l’état du pod à l’aide de la commande az aks nodepool list.

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

L’exemple de sortie suivant montre que le pool de nœuds gpunodepool crée (Creating) des nœuds avec la taille VmSize spécifiée :

[
  {
    ...
    "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",
    ...
  }
]

Il faut quelques minutes pour que gpunodepool soit créé avec succès.

Spécifier une teinte, un intitulé ou une étiquette pour un pool de nœuds

Lorsque vous créez un pool de nœuds, vous pouvez lui ajouter des teintes, des intitulés ou des étiquettes. Lorsque vous ajoutez une teinte, un intitulé ou une étiquette, tous les nœuds du pool reçoivent cette teinte, cet intitulé ou cette étiquette.

Important

L’ajout de teintes, d’étiquettes ou de balises aux nœuds doit se faire pour l’ensemble du pool de nœuds à l’aide de az aks nodepool. Nous déconseillons l’utilisation de kubectl pour l’application de teintes, d’étiquettes ou de balises à des nœuds individuels dans un pool de nœuds.

Définir des teintes d’un pool de nœuds

Créez un pool de nœuds avec une teinte à l’aide de la commande az aks nodepool add . Spécifiez le nom taintnp et utilisez le paramètre --node-taints afin de spécifier sku=gpu:NoSchedule pour la teinte.
```
az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name taintnp \
    --node-count 1 \
    --node-taints sku=gpu:NoSchedule \
    --no-wait
```

Vérifiez l’état du pod à l’aide de la commande az aks nodepool list.

az aks nodepool list -g myResourceGroup --cluster-name myAKSCluster

L’exemple de sortie suivant montre que le pool de nœuds taintnp crée (Creating) des nœuds avec la taille nodeTaints spécifiée :

[
  {
    ...
    "count": 1,
    ...
    "name": "taintnp",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "nodeTaints":  [
      "sku=gpu:NoSchedule"
    ],
    ...
  },
 ...
]

Les informations concernant la teinte sont visibles dans Kubernetes pour la gestion des règles de planification des nœuds. Le planificateur Kubernetes peut utiliser des teintes et des tolérances pour restreindre les charges de travail qui peuvent s’exécuter sur des nœuds.

Quand une teinte est appliquée à un nœud, seuls des pods spécifiques peuvent être planifiés sur le nœud.
Une tolérance est ensuite appliquée à un pod pour lui permettre de tolérer la teinte d’un nœud.

Pour plus d’informations sur la façon d’utiliser les fonctionnalités de Kubernetes planifiées avancées, consultez Bonnes pratiques relatives aux fonctionnalités avancées du planificateur dans AKS.

Définir des tolérances de pool de nœuds

À l’étape précédente, vous avez appliqué la teinte sku=gpu:NoSchedule lorsque vous avez créé votre pool de nœuds. L’exemple de manifeste YAML suivant utilise une tolérance pour autoriser le planificateur Kubernetes à exécuter un pod NGINX sur un nœud de ce pool de nœuds.

Créez un fichier nommé nginx-toleration.yaml et copiez-y l’exemple de code YAML suivant.

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"

Planifiez le pod à l’aide de la commande kubectl apply.
```
kubectl apply -f nginx-toleration.yaml
```
Il faut quelques secondes pour planifier le pod et extraire l’image NGINX.

Vérifiez l’état à l’aide de la commande kubectl describe pod.

kubectl describe pod mypod

L’exemple de sortie condensée suivant montre que la tolérance sku=gpu:NoSchedule est appliquée. Dans la section des événements, le planificateur a affecté le pod au nœud aks-taintnp-28993262-vmss000000 :

[...]
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

Seuls les pods auxquels cette tolérance est appliquée peuvent être planifiés sur les nœuds dans taintnp. Tous les autres pods seront planifiés dans le pool de nœuds nodepool1. Si vous créez des pools de nœuds supplémentaires, vous pouvez utiliser des teintes et des tolérances supplémentaires pour limiter les pods qui peuvent être planifiés sur ces ressources de nœud.

Définition des étiquettes d’un pool de nœuds

Pour plus d’informations, consultez Utiliser des étiquettes dans un cluster Azure Kubernetes Service (AKS).

Définition des étiquettes Azure d’un pool de nœuds

Pour plus d'informations sur ce scénario, consultez Utiliser des balises Azure dans le service Azure Kubernetes (AKS).

Gérer les pools de nœuds à l’aide d’un modèle Resource Manager

Lorsque vous utilisez un modèle Azure Resource Manager pour créer et gérer des ressources, vous pouvez modifier les paramètres dans votre modèle et le redéployer pour mettre à jour les ressources. Avec les pools de nœuds AKS, vous ne pouvez pas mettre à jour le profil initial du pool nœuds une fois que le cluster AKS a été créé. Ce comportement signifie que vous ne pouvez pas mettre à jour un modèle Resource Manager existant, apporter un changement aux pools de nœuds et ensuite redéployer le modèle. Au lieu de cela, vous devez créer un modèle Resource Manager distinct qui mette à jour les pools de nœuds pour le cluster AKS existant.

Créez un modèle tel que aks-agentpools.json et collez dans l’exemple de manifeste suivant. Veillez à modifier les valeurs en fonction des besoins. Cet exemple de modèle configure les paramètres suivants :

Met à jour le pool de nœuds Linux nommé myagentpool pour exécuter trois nœuds.
Définit les nœuds dans le pool de nœuds pour exécuter Kubernetes version 1.15.7.
Définit la taille de nœud en tant que 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"
            }
        }
    ]
}

Déployez le modèle à l’aide de la commande az deployment group create .
```
az deployment group create \
    --resource-group myResourceGroup \
    --template-file aks-agentpools.json
```
Conseil

Vous pouvez ajouter une balise à votre pool de nœuds en ajoutant la propriété tag au modèle, comme dans l’exemple suivant :
```
...
"resources": [
{
  ...
  "properties": {
    ...
    "tags": {
      "name1": "val1"
    },
    ...
  }
}
...
```
La mise à jour de votre cluster AKS peut prendre quelques minutes selon les paramètres de pool de nœuds et les opérations que vous définissez dans votre modèle Resource Manager.

Étapes suivantes

Pour plus d’informations sur la façon de contrôler les pods entre les pools de nœuds, consultez Bonnes pratiques relatives aux fonctionnalités avancées du planificateur dans AKS.
Utilisez les groupes de placement de proximité pour réduire la latence dans vos applications AKS.
Utilisez des adresses IP publiques au niveau de l’instance pour permettre à vos nœuds de servir directement le trafic.