Activer ou désactiver l’approvisionnement automatique de nœud (NAP) dans Azure Kubernetes Service (AKS)

Cet article explique comment activer ou désactiver l’approvisionnement automatique de nœud dans Azure Kubernetes Service (AKS) à l’aide des modèles Azure CLI ou Azure Resource Manager (ARM).

Si vous souhaitez créer un cluster AKS compatible NAP avec un réseau virtuel personnalisé (VNet) et des sous-réseaux, consultez Créer un cluster d’approvisionnement automatique de nœud (NAP) dans un réseau virtuel personnalisé.

Avant de commencer

Avant de commencer, consultez la vue d’ensemble de l’approvisionnement automatique de nœud (NAP) dans l’article AKS , qui détaille le fonctionnement de NAP, les prérequis et les limitations.

Activer l’approvisionnement automatique de nœud (NAP) sur un cluster AKS

Les sections suivantes expliquent comment activer NAP sur un cluster AKS nouveau ou existant :

Note

Vous pouvez activer les métriques du plan de contrôle pour afficher les journaux et les opérations du provisionnement automatique des nœuds avec le module complémentaire Azure Monitor Managed Service pour Prometheus.

Activer NAP sur un nouveau cluster

  • Activez l'approvisionnement automatique de nœuds sur un nouveau cluster à l'aide de la commande az aks create avec le paramètre --node-provisioning-mode défini sur Auto. La commande suivante définit également --network-plugin à azure, --network-plugin-mode à overlay, et --network-dataplane à cilium.

    az aks create \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Auto \
    --network-plugin azure \
    --network-plugin-mode overlay \
    --network-dataplane cilium \
    --generate-ssh-keys

  1. Créez un fichier nommé nap.json et ajoutez la configuration de modèle ARM suivante, en définissant le champ properties.nodeProvisioningProfile.mode sur Auto, ce qui active NAP. (Le paramètre par défaut est Manual.)

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Auto"
        }
      }
    }
  ]
}

  2. Activez l'auto-approvisionnement de nœud sur un nouveau cluster en utilisant la commande az deployment group create avec l’indicateur --template-file défini sur le chemin du fichier de modèle ARM.

    az deployment group create --resource-group $RESOURCE_GROUP --template-file ./nap.json

Activer NAP sur un cluster existant

  • Activez l'autoprovisionnement de nœuds sur un cluster existant à l'aide de la commande az aks update avec l'indicateur --node-provisioning-mode défini sur Auto.

    az aks update --name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --node-provisioning-mode Auto

Désactiver l’approvisionnement automatique de nœud (NAP) sur un cluster AKS

Important

Vous pouvez uniquement désactiver NAP sur un cluster si les conditions suivantes sont remplies :

  • Il n’existe aucun nœud NAP existant. Vous pouvez utiliser la kubectl get nodes -l karpenter.sh/nodepool commande pour rechercher les nœuds gérés par NAP existants.
  • Tous les Karpenter NodePools existants ont leur champ spec.limits.cpu défini sur 0. Cette action empêche la création de nouveaux nœuds, mais n’interrompt pas les nœuds en cours d’exécution.

  1. Définissez le spec.limits.cpu champ sur 0 pour chaque Karpenter NodePoolexistant. Par exemple:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  limits:
    cpu: 0

    Important

    Si vous ne souhaitez pas vous assurer que chaque pod en cours d’exécution sur un nœud NAP est migré en toute sécurité vers un nœud non NAP avant de désactiver NAP, vous pouvez ignorer les étapes 2 et 3 et utiliser plutôt la kubectl delete node commande pour chaque nœud géré par NAP. Toutefois, nous ne recommandons pas ignorer ces étapes, car cela pourrait laisser certains pods en attente et ne respecterait pas les budgets de perturbation des pods (PDB).

    Lorsque vous utilisez la kubectl delete node commande, veillez à supprimer uniquement les nœuds gérés par NAP. Vous pouvez identifier les nœuds gérés par NAP à l’aide de la kubectl get nodes -l karpenter.sh/nodepool commande.

  2. Ajoutez la teinte karpenter.azure.com/disable:NoSchedule à chaque Karpenter NodePool. Par exemple:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      ...
      taints:
        - key: karpenter.azure.com/disable
          effect: NoSchedule

    Cette action démarre le processus de migration des charges de travail sur les nœuds gérés par NAP vers des nœuds non NAP, en respectant les limites de PDB et d’interruption. Les pods migrent vers des nœuds non NAP s'ils peuvent s'adapter. S'il n'y a pas suffisamment de capacité à taille fixe, certains nœuds gérés par NAP persistent.

  3. Effectuez une mise à l'échelle de taille fixe existanteManagedClusterAgentPools ou créez une nouvelle taille fixe AgentPools pour supporter la charge des nœuds gérés par NAP. À mesure que ces nœuds sont ajoutés au cluster, les nœuds gérés par NAP sont vidés et le travail est migré vers les nœuds de taille fixe.

  4. Supprimez tous les nœuds gérés par NAP à l’aide de la kubectl get nodes -l karpenter.sh/nodepool commande. Si des nœuds gérés par NAP existent toujours, le cluster manque probablement de capacité de taille fixe. Dans ce cas, vous devez ajouter d’autres nœuds afin que les charges de travail restantes puissent être migrées.

  1. Mettez à jour le mode NAP sur Manual à l’aide de la commande az aks update Azure CLI avec l’indicateur --node-provisioning-mode défini sur Manual.

    az aks update \
    --name $CLUSTER_NAME \
    --resource-group $RESOURCE_GROUP \
    --node-provisioning-mode Manual

  1. Mettez à jour le champ properties.nodeProvisioningProfile.mode en Manual dans votre modèle ARM et redéployez-le.

    {
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "metadata": {},
  "parameters": {},
  "resources": [
    {
      "type": "Microsoft.ContainerService/managedClusters",
      "apiVersion": "2025-05-01",
      "sku": {
        "name": "Base",
        "tier": "Standard"
      },
      "name": "napcluster",
      "location": "uksouth",
      "identity": {
        "type": "SystemAssigned"
      },
      "properties": {
        "networkProfile": {
            "networkPlugin": "azure",
            "networkPluginMode": "overlay",
            "networkPolicy": "cilium",
            "networkDataplane":"cilium",
            "loadBalancerSku": "Standard"
        },
        "dnsPrefix": "napcluster",
        "agentPoolProfiles": [
          {
            "name": "agentpool",
            "count": 3,
            "vmSize": "standard_d2s_v3",
            "osType": "Linux",
            "mode": "System"
          }
        ],
        "nodeProvisioningProfile": {
          "mode": "Manual"
        }
      }
    }
  ]
}

Migrer de Karpenter open source auto-hébergé vers le provisionnement automatique de nœud managé (NAP)

Si Karpenter a été installé à partir du chart Helm open source, vous pouvez toujours activer NAP sur votre cluster. Ces étapes supposent que le graphique Helm Karpenter est installé.

Important

Vérifiez que vous exécutez la version la plus récente de Karpenter avant de lancer la migration. NAP exécute toujours la dernière version.

Important

Veillez à ne pas supprimer les CRD Karpenter lors de l’exécution de ce processus de migration. Si les CRD sont supprimés, il supprime les NodeClaims sous-jacents, ce qui peut perturber vos charges de travail.

  1. Pour éviter que les CRD Karpenter ne soient désinstallés à l’étape 2, supprimez les labels et annotations managed-by=Helm.

    kubectl get crds -l app.kubernetes.io/managed-by=Helm -o name | grep karpenter.azure.com | xargs -I{} kubectl patch {} --type=json -p '
[
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-name"},
  {"op":"remove","path":"/metadata/annotations/meta.helm.sh~1release-namespace"},
  {"op":"remove","path":"/metadata/labels/app.kubernetes.io~1managed-by"}
]'

  2. Désinstallez le chart Helm pour supprimer le déploiement, le service, les rôles et d’autres ressources utilisées par Karpenter open source. À ce stade, Karpenter ne réagit plus aux événements de mise à l’échelle, mais les nœuds existants continuent de fonctionner.

    helm uninstall karpenter -n kube-system  # If you installed Karpenter into a different namespace than kube-system, specify that here instead of kube-system

  3. Activez NAP sur votre cluster :

    az aks update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --node-provisioning-mode Auto --node-provisioning-default-pools None

    Cette commande désactive les nodePools par défaut, car vous avez des NodePools existants et souhaitez continuer à les utiliser. Si vous souhaitez activer les pools par défaut du provisionnement automatique des nœuds, vous pouvez omettre --node-provisioning-default-pools None de la commande az aks update.

  4. Vérifiez que la migration est terminée : une fois l’étape az aks update 3 terminée, la migration est effectuée. Vous pouvez également confirmer que la migration est effectuée en vérifiant les annotations sur les CRD Karpenter. Vous devriez voir :

        meta.helm.sh/release-name: aks-managed-karpenter-overlay-base
    meta.helm.sh/release-namespace: kube-system

    À ce stade, NAP est activé et la mise à l’échelle automatique doit reprendre.

Surveillance du provisionnement automatique des nœuds

Récupérer les journaux d’activité ainsi que l’état de Karpenter

Vous pouvez récupérer les journaux d’activité et les mises à jour d’état de Karpenter pour faciliter le diagnostic et le débogage d’événements liés à NAP. AKS gère le provisionnement automatique des nœuds en votre nom et l’exécute dans le plan de contrôle managé. Il est possible d’activer les journaux d’activité du plan de contrôle afin d’afficher les opérations et les événements Karpenter liés à l’approvisionnement automatique des nœuds. Pour plus d’informations sur les journaux du plan de contrôle, consultez la documentation sur les journaux du plan de contrôle AKS

  1. Configurez une règle pour que les journaux de ressources poussent les journaux d’auto-provisionnement vers Log Analytics en utilisant les instructions ici. Veillez à cocher la case node-auto-provisioning lors de la sélection des options pour Journaux d’activité.

  2. Sélectionnez la section Journal sur votre cluster.

  3. Entrez l’exemple de requête suivant dans Log Analytics :

    AKSControlPlane
| where Category == "karpenter-events"

  4. Afficher les événements d’approvisionnement automatique de nœud sur l’interface CLI :

    kubectl get events --field-selector source=karpenter-events

Métriques d’approvisionnement automatique de nœud

Vous pouvez également activer les mesures du plan de contrôle (préversion) pour consulter les métriques et opérations Karpenter spécifiques à l’approvisionnement automatique des nœuds via le service géré Azure Monitor pour le module complémentaire Prometheus.

Étapes suivantes

Pour plus d’informations sur le provisionnement automatique de nœuds dans AKS, consultez les articles suivants :

  • Last updated on