Configurer les ressources AKSNodeClass pour l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS)

Cet article explique comment configurer des ressources AKSNodeClass pour définir des paramètres spécifiques à Azure pour l’approvisionnement automatique de nœud (NAP) dans Azure Kubernetes Service (AKS) à l’aide de Karpenter. AKSNodeClass vous permet de personnaliser différents aspects des nœuds approvisionnés par Karpenter, tels que l’image de machine virtuelle, la taille de disque du système d’exploitation (OS), le nombre maximal de pods par nœud et les configurations kubelet.

Important

À compter de November 30, 2025, Azure Kubernetes Service (AKS) ne prend plus en charge ni ne fournit plus de mises à jour de sécurité pour Azure Linux 2.0. L’image de nœud Azure Linux 2.0 est figée à la version 202512.06.0. À compter du 31 octobre 2026, les images de nœud seront supprimées et vous ne pourrez pas mettre à l’échelle vos pools de nœuds. Migrez vers une version Azure Linux prise en charge en mettant à niveau vos pools de nœuds vers une version de Kubernetes prise en charge ou en migrant vers osSku AzureLinux3. Pour plus d'informations, consultez le problème de retrait sur GitHub et l'annonce de la mise hors service des mises à jour Azure. Pour rester informé des annonces et des mises à jour, suivez les notes de publication AKS.

Vue d’ensemble des ressources AKSNodeClass

AKSNodeClass ressources vous permettent de configurer des paramètres spécifiques à Azure pour NAP. Chaque NodePool ressource doit référencer un AKSNodeClass à l'aide de spec.template.spec.nodeClassRef. Vous pouvez avoir plusieurs NodePools qui pointent vers le même AKSNodeClass, ce qui vous permet de partager des configurations de Azure courantes sur différents pools de nœuds.

Important

La modification d’un paramètre sur un AKSNodeClass existant ne reconfigure pas les nœuds en cours d’exécution. NAP marque les nœuds approvisionnés à partir de la configuration précédente comme étant dérivés et les remplace, sous réserve des contrôles d’interruption sur les ressources NodePool qui y font référence. Le tags champ est la seule exception, car les modifications de balise s’appliquent aux ressources Azure existantes sans remplacer le nœud. Pour en savoir plus, consultez Dérive et les budgets de perturbation. Avant de modifier un AKSNodeClass utilisé par des charges de travail de production, passez en revue ces conseils.

Configuration de la famille d’images

Le imageFamily champ définit l’image de machine virtuelle par défaut et la logique de démarrage pour les nœuds approvisionnés via le AKSNodeClass. Si vous ne spécifiez pas de famille d’images, la version du système d’exploitation par défaut en fonction de votre version Kubernetes est utilisée. Les GPU sont pris en charge avec les deux familles d’images sur les tailles de machine virtuelle compatibles. Pour plus d’informations sur la version par défaut du système d’exploitation par version Kubernetes, consultez la documentation sur la version du système d’exploitation AKS.

Familles d’images prises en charge

Ubuntu: Ubuntu est la distribution Linux par défaut pour les nœuds AKS.
- La version du système d’exploitation change par défaut en fonction de votre version kubernetes. Ubuntu 22.04 est la valeur par défaut pour Kubernetes versions 1.25 à 1.33. Ubuntu 24.04 est la valeur par défaut pour Kubernetes versions 1.34 et ultérieures.
AzureLinux : Azure Linux est la distribution Linux alternative de Microsoft pour les charges de travail AKS. Pour plus d’informations, consultez la documentation Azure Linux.
AzureContainerLinux: Azure Container Linux est pris en charge avec AKS 1.34 et versions ultérieures. Utilisez une machine virtuelle de génération 2 et activez explicitement les deux paramètres Trusted Launch, même si vous n’en avez pas besoin autrement :
- Réglez security.trustedLaunch.vtpm sur true.
- Réglez security.trustedLaunch.secureBoot sur true.
- Si vous définissez osDiskSizeGB, utilisez une valeur d’au moins 60.
- Ne combinez pas cette famille d’images avec des paramètres non pris en charge par cette image. Pour plus d’informations, consultez Azure Container Linux sur AKS.
Windows2022: Windows Server 2022 est en préversion. Elle nécessite une architecture AMD64 et n’est pas prise en charge avec le plan de données Cilium. Windows2022 ne prend pas en charge FIPS ou Trusted Launch. Ne configurez pas linuxOSConfig, n’activez pas le streaming d’artefacts et ne définissez pas LocalDNS sur un mode autre que Disabled.
Windows2025: Windows Server 2025 est en préversion. Elle nécessite une architecture AMD64 et n’est pas prise en charge avec le plan de données Cilium. FIPS est nécessaire et est effectivement activé même lorsque fipsMode est omis. Ne configurez pas linuxOSConfig, activez le streaming d’artefacts ou définissez LocalDNS sur un mode autre que Disabled.

Exemple de configuration de la famille d’images

L’exemple suivant configure le AKSNodeClass pour utiliser la famille d’images AzureLinux :

spec:
  imageFamily: AzureLinux

configuration Azure Container Linux

L’exemple suivant utilise Azure Container Linux avec les paramètres Trusted Launch requis. Omettez osDiskSizeGB de sorte que la plateforme sélectionne une taille de disque prise en charge.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: azure-container-linux
spec:
  imageFamily: AzureContainerLinux
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

prise en charge de Windows OS (aperçu)

Note

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions préliminaires sont fournies « en l’état » et « selon leur disponibilité » et ne sont pas couvertes par les accords de niveau de service ni par la garantie limitée. Les versions préliminaires d’AKS sont partiellement couvertes par le support client, dans la limite du raisonnable. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

NAP prend en charge Windows2022 et Windows2025 images.

Windows2022: Windows Server 2022 est en préversion. Elle nécessite une architecture AMD64 et n’est pas prise en charge avec le plan de données Cilium. Windows2022 ne prend pas en charge FIPS ou Trusted Launch. Ne configurez pas linuxOSConfig, n’activez pas le streaming d’artefacts et ne définissez pas LocalDNS sur un mode autre que Disabled.
Windows2025: Windows Server 2025 est en préversion. Elle nécessite une architecture AMD64 et n’est pas prise en charge avec le plan de données Cilium. FIPS est nécessaire et est effectivement activé même lorsque fipsMode est omis. Ne configurez pas linuxOSConfig, activez le streaming d’artefacts ou définissez LocalDNS sur un mode autre que Disabled.

Configuration de Windows2022

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025

Configuration de Windows2025

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: windows-2025
spec:
  imageFamily: Windows2025
  security:
    trustedLaunch:
      vtpm: true
      secureBoot: true

Important

Les familles d’images Windows sont en préversion. Utilisez un NodePool Windows qui sélectionne kubernetes.io/os: windows et kubernetes.io/arch: amd64, vérifiez que les charges de travail sélectionnent également les nœuds Windows. Pour plus d’informations, consultez Configurer des pools de nœuds pour l’approvisionnement automatique de nœuds sur AKS.

Configuration de l’image de nœud conforme FIPS

Vous pouvez également activer les images de nœud conformes aux normes FIPS (Federal Information Processing Standards). Pour plus d’informations sur FIPS dans AKS, consultez la documentation FIPS.

Le fipsMode champ est défini par défaut sur Désactivé et peut être défini sur les options suivantes :

FIPS : sélectionner des images de nœud conformes à FIPS
Désactivé : n’utilisez pas d’images de nœud compatibles FIPS

L’exemple suivant configure « AKSNodeClass » pour sélectionner des images de nœud conformes à FIPS en définissant fipsMode sur FIPS:

spec:
  fipsMode: FIPS

Configuration d’adresse IP publique au niveau de l’instance

Vous pouvez affecter une adresse IPv4 publique à chaque nœud provisionné NAP en définissant nodePublicIP.enabled sur true. Vous pouvez facultativement spécifier ipTags ou prefixIDs. Utilisez l’un ou l’autre, pas les deux.

Utiliser l’adresse IP publique au niveau de l’instance avec des préfixes

Si vous le souhaitez, spécifiez un préfixe d’adresse IP publique IPv4 à l’aide de prefixIDs. Le préfixe doit se trouver dans la même région que le cluster. Pour un préfixe zonal, limitez le NodePool correspondant à la même zone de disponibilité. Vous ne pouvez pas spécifier ipTags et prefixIDs ensemble ; utilisez-en un seul.

L’identité du cluster doit être autorisée à utiliser le préfixe d’adresse IP publique, le cas échéant, et à créer et gérer les ressources IP publiques du nœud. Pour obtenir des instructions complètes sur l’installation, la sécurité réseau et la vérification, consultez Utiliser des adresses IP publiques de nœud.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Utiliser une adresse IP publique au niveau de l’instance avec des balises IP et une préférence de routage Internet

L’exemple suivant montre comment utiliser l’adresse IP publique au niveau de l’instance avec une balise IP :

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: public-ip-nodes
spec:
  nodePublicIP:
    enabled: true
    ipTags:
      - ipTagType: RoutingPreference
        tag: Internet
    # Optional. Specify at most one IPv4 public IP prefix resource ID.
    prefixIDs:
      - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/publicIPPrefixes/<prefix-name>

Diffusion en continu d'artéfacts

Artifact Streaming vous permet de diffuser des images de conteneur depuis Azure Container Registry (ACR) vers Azure Kubernetes Service (AKS). AKS extrait uniquement les couches nécessaires pour le démarrage initial du pod, ce qui réduit le temps nécessaire pour déployer vos charges de travail.

Prerequisites

Artifact Streaming nécessite que vous ayez un ACR de niveau Premium intégré à votre cluster AKS.
Le streaming d’artefacts doit être activé dans ACR.

Consultez la documentation Artifact Streaming pour savoir comment activer Artifact Streaming dans ACR.

Activer le streaming d’artefacts dans les clusters NAP

Les clusters avec Node Auto Provisioning (NAP) activé peuvent activer le streaming d’artefacts à l’aide du champ spec.artifactStreaming.enabled de la CRD AKSNodeClass. Définissez ce champ sur true pour activer le streaming d’artefacts pour tous les nouveaux nœuds ou nœuds existants gérés par NAP associés à ce CRD AKSNodeClass.

apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  # Enables artifact streaming; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: 
      true

Note

Pour utiliser le streaming d’artefacts sur des nœuds managés AKS NAP, vous devez également activer la diffusion en continu d’artefacts dans Azure Container Registry (ACR). Si vous ne définissez pas cette option dans ACR, le champ a la valeur false par défaut.

Configuration du sous-réseau de réseau virtuel (VNet)

** Le champ vnetSubnetID spécifie quel sous-réseau Azure VNet doit être utilisé pour provisionner les interfaces réseau des nœuds. Ce champ est facultatif. Si vous ne spécifiez pas de sous-réseau, NAP utilise le sous-réseau par défaut configuré pendant l’installation de Karpenter. Pour plus d’informations, consultez Configurations de sous-réseau pour NAP.

Exemple de configuration de sous-réseau

L’ID de sous-réseau doit être au format complet Azure Resource Manager (ARM), comme illustré dans l’exemple suivant :

spec:
  vnetSubnetID: "/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/virtualNetworks/{vnet-name}/subnets/{subnet-name}"

Configuration de la taille du disque du système d’exploitation

Le champ osDiskSizeGB spécifie la taille du disque du système d’exploitation en gigaoctets. La valeur par défaut est de 128 Go et la valeur minimale est de 30 Go.

Tenez compte des tailles de disque de système d’exploitation supérieures pour les charges de travail qui :

Stockez des données significatives localement.
Nécessiter un espace additionnel pour les images de conteneur.
Disposez d’exigences élevées en matière d’E/S sur disque.

Exemple de configuration de taille de disque du système d’exploitation

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Configuration du disque de système d’exploitation éphémère

NAP utilise automatiquement les disques de système d’exploitation éphémères lorsqu’ils sont disponibles et adaptés à la taille de disque demandée. Les disques de système d’exploitation éphémères offrent de meilleures performances et un coût moindre par rapport aux disques managés.

Critères de sélection de disque éphémère

Le système choisit automatiquement les disques éphémères dans les scénarios suivants :

Le type d’instance de machine virtuelle prend en charge les disques de système d’exploitation éphémères.
La capacité de disque éphémère est supérieure ou égale à la capacité demandée osDiskSizeGB.
La machine virtuelle dispose d’une capacité de stockage éphémère suffisante.

Si ces conditions ne sont pas remplies, le système revient à utiliser des disques managés.

Types de disques éphémères et hiérarchisation

Azure machines virtuelles peuvent avoir différents types de stockage éphémère. Le système utilise l’ordre de priorité suivant :

Disques NVMe (performances les plus élevées)
Disques de cache (performances équilibrées)
Disques de ressources (performances de base)

Exemple de configuration de disque éphémère

Vous pouvez utiliser les exigences du pool de nœuds pour garantir que les nœuds disposent d’une capacité de disque éphémère suffisante, comme indiqué dans l’exemple suivant :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: ephemeral-disk-pool
spec:
  template:
    spec:
      requirements:
        - key: karpenter.azure.com/sku-storage-ephemeralos-maxsize
          operator: Gt
          values: ["128"]  # Require ephemeral disk larger than 128 GB
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: my-node-class
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: my-node-class
spec:
  osDiskSizeGB: 128  # This will use ephemeral disk if available and large enough

Cette configuration garantit que seuls les types d’instances de machine virtuelle avec des disques éphémères de plus de 128 Go sont sélectionnés, garantissant ainsi l’utilisation des disques éphémères pour la taille de disque du système d’exploitation spécifiée.

Configuration maximale des pods

Le champ maxPods spécifie le nombre maximal de pods qui peuvent être planifiés sur un nœud. Ce paramètre affecte à la fois la densité de cluster et la configuration réseau.

La valeur minimale pour maxPods 10 et la valeur maximale est 250.

Comportement par défaut pour `maxPods`

Le comportement par défaut de maxPods dépend de la configuration du plug-in réseau. Le tableau suivant récapitule les valeurs par défaut :

Configuration du plug-in réseau	Valeur par défaut `maxPods` par nœud
Azure CNI avec mise en réseau standard (v1 ou NodeSubnet)	30
Azure CNI avec mise en réseau superposée	250
Aucun (pas de plugin réseau)	250
Autres configurations	110 (standard Kubernetes par défaut)

Exemple de configuration du nombre maximal de pods

spec:
  maxPods: 50  # Allow up to 50 pods per node

Configuration LocalDNS

LocalDNS déploie un proxy DNS au niveau du nœud qui résout les requêtes DNS plus proches des charges de travail, ce qui réduit la latence des requêtes et améliore la résilience pendant les interruptions DNS temporaires. Pour plus d’informations, consultez la documentation LocalDNS. Par défaut, LocalDNS est défini sur Désactivé et peut être configuré sur les options suivantes :

Disabled (par défaut) : désactive la fonctionnalité LocalDNS. Les requêtes DNS ne sont pas résolues localement sur le nœud.
Preferred - AKS gère l’activation LocalDNS en fonction de la version Kubernetes du pool de nœuds. La configuration est toujours validée et incluse, mais LocalDNS n’est pas activée, sauf si la version de Kubernetes correcte est utilisée.
Required - LocalDNS est appliqué au pool de nœuds si tous les prérequis sont satisfaits. Si la configuration requise n’est pas remplie, le déploiement échoue.

Exemple de configuration LocalDNS

Vous pouvez personnaliser des configurations LocalDNS telles que vnetDNSOverrides et kubeDNSOverrides. Pour plus d’informations sur les plug-ins pris en charge, consultez Personnaliser localDNS.

spec:
  LocalDNS:
    mode: Required
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

Mettre à jour la configuration LocalDNS sur une classe AKSNodeClass existante

Le localDNS paramètre participe à la détection de dérive comme d’autres AKSNodeClass paramètres. Lorsque vous changez spec.localDNS sur un AKSNodeClass que des nœuds existants référencent déjà, NAP applique la modification par le biais du mécanisme de Dérive standard. NAP ne réinitialise pas des nœuds existants.

Le comportement suivant s’applique lorsque vous modifiez le mode LocalDNS ou les remplacements, tels que la modification de mode de Disabled en Required :

Nouveaux nœuds : chaque nœud approvisionné par NAP après la mise à jour du AKSNodeClass, utilise la nouvelle configuration LocalDNS.
Nœuds existants : NAP marque les objets existants NodeClaim comme dérivés, car leur configuration enregistrée ne correspond plus au AKSNodeClass. NAP lance un nœud de remplacement qui utilise la nouvelle configuration LocalDNS, puis isole, évacue et supprime le nœud en dérive.
Pas de réinitialisation : l’activation de LocalDNS sur un pool de nœuds managés AKS réinitialise chaque nœud du pool. NAP remplace le nœud à la place. Dans les deux cas, les pods sur les nœuds affectés sont expulsés et replanifiés. Prévoyez donc le même impact sur la charge de travail.

Important

Définir mode sur Preferred ou Disabled modifie également la configuration résolue AKSNodeClass et met les nœuds existants en dérive. Toute modification dans la section localDNS, y compris les valeurs kubeDNSOverrides et vnetDNSOverrides, entraîne le remplacement du nœud.

Au démarrage du remplacement

L’évaluation de la dérive et le remplacement commencent dès que vous appliquez la version mise à jour de AKSNodeClass. Le remplacement suit le cycle de vie de perturbation NAP standard, de sorte que le taux et le moment dépendent des contrôles de perturbation que vous configurez sur les ressources NodePool référençant le AKSNodeClass.

Comment NAP orchestre le remplacement

La dérive provoquée par une modification LocalDNS respecte les contrôles d’interruption NAP standard décrits dans le tableau suivant :

Contrôler	Effet sur le remplacement induit par LocalDNS
Budgets de perturbation (`spec.disruption.budgets`)	Le taux limite le nombre de nœuds que NAP remplace en une seule fois. Si vous ne définissez pas de budgets, NAP utilise par défaut un budget de `nodes: 10%`, ce qui interrompt simultanément un maximum de 10 % des nœuds du pool de nœuds.
Budget `schedule` et `duration`	Limite le remplacement à une fenêtre de maintenance. Placez `nodes: "0"` en dehors de la fenêtre pour bloquer le remplacement.
Budgets de perturbation des pods (PDB)	Appliquez pendant le vidage du nœud. NAP attend au lieu de supprimer des pods qui violent un PDB.
`karpenter.sh/do-not-disrupt` annotation	Exclut les pods annotés et les nœuds de toute interruption volontaire, y compris la dérive.
`terminationGracePeriod`	Plafonne le temps de vidage. Ce paramètre contourne les PDB et l’annotation `karpenter.sh/do-not-disrupt` lorsque la période s’écoule.

Le remplacement n’est ni entièrement sériel ni entièrement parallèle. NAP provisionne la capacité de remplacement avant de supprimer un nœud dérivé, mais il peut remplacer plusieurs nœuds qui font référence au même AKSNodeClass simultanément, jusqu’à la limite définie par vos budgets de perturbation.

Warning

Si vous ne définissez pas de budgets d’interruption sur vos pools de nœuds et que vous ne définissez pas de budgets d’interruption de pod pour vos charges de travail, modifier localDNS sur un AKSNodeClass très sollicité peut perturber jusqu’à 10 % de vos nœuds à la fois sans protection au niveau de l’application, ce qui peut entraîner un temps d’arrêt de la charge de travail. Définissez des PDB pour les charges de travail critiques et définissez un budget d’interruption conservateur avant de changer localDNS sur un cluster de production.

Réduire le risque d’indisponibilité lorsque vous activez LocalDNS

Vérifiez que vos serveurs DNS personnalisés répondent aux requêtes via le port 53 en UDP et en TCP à partir du sous-réseau de nœud. Pour plus d’informations, consultez Valider le DNS personnalisé avant d’activer LocalDNS.
Définissez des budgets d’interruption de pod pour chaque charge de travail critique.
Définissez un budget de perturbation conservateur sur les ressources affectées NodePool avant de modifier le AKSNodeClass, comme indiqué dans l’exemple suivant :
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
    - nodes: "1"   # Replace one node at a time
```
Appliquez d’abord la localDNS modification à un environnement hors production AKSNodeClass. Vous pouvez également créer un AKSNodeClass avec LocalDNS activé et migrer des charges de travail vers une NodePool qui y fait référence.

Surveillez la progression du remplacement en répertoriant les NodeClaims. Le remplacement est terminé lorsqu’aucune revendication de nœud ne signale la condition d’état Drifted.

# List node claims and watch replacements appear as drifted nodes are removed
kubectl get nodeclaims

# Inspect the status conditions on a specific node claim
kubectl describe nodeclaim <nodeclaim-name>

Vérifiez que LocalDNS est actif sur les nœuds de remplacement. Pour plus d’informations, consultez Vérifier l’opération LocalDNS.

Configuration de kubelet

La section kubelet vous permet de configurer différents paramètres kubelet qui affectent le comportement du nœud. Ces paramètres sont des arguments kubelet classiques. Par conséquent, le fournisseur Azure les transmet simplement au kubelet sur le nœud.

Important

Configurez soigneusement les paramètres kubelet et testez d’abord les modifications apportées aux environnements hors production.

Gestion du processeur

Les paramètres suivants contrôlent le comportement de gestion du processeur pour kubelet :

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"

cpuManagerPolicy : contrôle la façon dont kubelet alloue des ressources processeur. Défini sur "static" pour l’épinglage du processeur dans les charges de travail sensibles à la latence.
cpuCFSQuota : active l’application du quota DU PLANIFICATEUR COMPLÈTEMENT ÉQUITABLE (CFS) pour les conteneurs qui spécifient des limites d’UC.
cpuCFSQuotaPeriod: définit la période de quota CFS du processeur.

Garbage collection d’images

Les paramètres suivants contrôlent le comportement de la collecte des ordures d'images pour le kubelet :

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Ces paramètres contrôlent quand kubelet effectue le GC d’images conteneur :

imageGCHighThresholdPercent: pourcentage d'utilisation du disque qui déclenche le ramasse-miettes des images.
imageGCLowThresholdPercent : pourcentage d’utilisation du disque cible après le GC

Gestion de la topologie

Le paramètre suivant contrôle la stratégie du gestionnaire de topologie pour kubelet :

spec:
  kubelet:
    topologyManagerPolicy: "best-effort"  # none, restricted, best-effort, single-numa-node

Le gestionnaire de topologie permet de coordonner l’allocation de ressources pour les charges de travail sensibles à la latence sur les ressources processeur et appareil (comme GPU).

Configuration système

Les paramètres suivants vous permettent de configurer des paramètres système supplémentaires pour kubelet :

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096

allowedUnsafeSysctls : liste des sysctls non sécurisés autorisés que les pods peuvent utiliser.
containerLogMaxSize: Taille maximale des fichiers journaux du conteneur avant la rotation.
containerLogMaxFiles: nombre maximal de fichiers journaux de conteneur à conserver.
podPidsLimit: nombre maximal de processus autorisés dans n’importe quel pod.

Paramètres de configuration du système d’exploitation personnalisé Linux

La section LinuxOSConfig vous permet de configurer différents paramètres kubelet qui affectent le comportement du nœud. Ces paramètres sont des arguments de système d’exploitation personnalisés typiques. Par conséquent, le nap les transmet simplement à kubelet sur le nœud.

Pour plus d’informations sur les paramètres de configuration de système d’exploitation Linux personnalisés, les valeurs par défaut et les considérations, consultez la référence des paramètres de configuration de nœud personnalisé.

Important

Configurez soigneusement les paramètres du système d’exploitation Linux et testez tout d’abord les modifications apportées aux environnements hors production.

Paramètres des limites de descripteurs de fichiers sous Linux

Utilisez les paramètres suivants pour définir les paramètres du système de fichiers.

spec:
  linuxOSConfig: 
    # Sysctl Settings  
    sysctls:  
      # File System Settings  
      fsFileMax: 2000000               # Range: 8192-12000500  Default: Max of available range
      fsInotifyMaxUserWatches: 1000000 # Range: 781250-2097152 Default: 1048576
      fsAioMaxNr: 1000000              # Range: 65536-6553500  Default: 65536
      fsNrOpen: 1000000                # Range: 8192-20000500  Default: 1048576

Paramètres de socket Linux et de paramétrage réseau

Utilisez les paramètres suivants pour définir le paramètre TCP et réseau.

spec:
  linuxOSConfig:
      # Network Settings  
      netCoreSomaxconn: 65535          # Range: 4096-3240000  Default: 16384
      netCoreNetdevMaxBacklog: 5000    # Range: 1000-3240000  Default: 1000
      netCoreRmemMax: 134217728        # Range: 212992-134217728  Default: 1048576
      netCoreOptmemMax: 102400         # Range: 20480-4194304     Default: 131072 
      netCoreWmemMax: 134217728        # Range: 212992-134217728  Default: 212992
      netCoreRmemDefault: 212992       # Range: 212992-134217728  
      netCoreWmemDefault: 212992       # Range: 212992-134217728  
      netIPv4IPLocalPortRange: "1024 65535" # Format: "first last", first: 1024-60999, last: 32768-65535  

      # Neighbor Table GC Thresholds  
      netIPv4NeighDefaultGcThresh1: 1024   # Range: 128-80000  Default: 4096
      netIPv4NeighDefaultGcThresh2: 2048   # Range: 512-80000  Default: 8192
      netIPv4NeighDefaultGcThresh3: 4096   # Range: 1024-80000  Default: 16384
      # Note: thresh1 <= thresh2 <= thresh3  

      # Connection Tracking  
      netNetfilterNfConntrackBuckets: 131072  # Range: 65536-524288   Default: dynamically calculated 
      netNetfilterNfConntrackMax: 262144       # Range: 131072-2097152 Default: dynamically calculated

Paramètres de limite de travail Linux

Utilisez les paramètres suivants pour définir le paramètre du noyau.

spec:
  linuxOSConfig:
      # Kernel Settings  
      kernelThreadsMax: 100000         # Range: 20-513785  Default: Dynamically calculated

Paramètres de mémoire virtuelle Linux

Utilisez les options suivantes pour paramétrer l’opération du sous-système de mémoire virtuelle Linux du noyau Linux et l’écriture de données sales sur le disque.

spec:
  linuxOSConfig:
      # Memory Management  
      vmMaxMapCount: 262144          # Range: 65530-262144 Default: Max of available range
      vmVfsCachePressure: 100        # Range: 0-100  Default: 100
      vmSwappiness: 60               # Range: 0-100  Default: 60

      # Swap File Configuration  
      swapFileSize: "2Gi"             # Default: (not set) | Pattern: quantity with units Note: Requires kubelet.failSwapOn: false  

      # Transparent Huge Pages  
      transparentHugePageEnabled: "madvise"    # Values: [always, madvise, never]  Default: always
      transparentHugePageDefrag: "defer+madvise" # Values: [always, defer, defer+madvise, madvise, never]  Default: madvise

Paramètres GPU

Utilisez le champ suivant pour activer l’installation du pilote GPU personnalisé, par exemple avec l’opérateur GPU NVIDIA.

spec:
  gpu:
    mode: 
      # acceptable values: [driver, none] default(or if not specified): driver
      # none skips gpu driver installation, driver has NAP manage the GPU driver installation  
      none

GPU géré

Le champ gpu.mode contrôle l’installation du pilote GPU. Elle accepte None ou Driver et prend par défaut la valeur Driver. Définissez cette option None pour ignorer l’installation du pilote, par exemple lors de l’utilisation de l’opérateur GPU NVIDIA.

Pour activer l’expérience GPU NVIDIA managée, utilisez mode: Driver et définissez nvidia.managementMode: Managed. Le GPU géré est pris en charge pour les nœuds GPU NVIDIA Linux à l’aide du mode d’approvisionnement de l’API Machine AKS. Le mode de gestion NVIDIA par défaut est Unmanaged.

spec:
  gpu:
    mode: Driver
    nvidia:
      managementMode: Managed

Pour obtenir un exemple complet de GPU géré par NAP et des étapes de vérification, consultez les nœuds GPU gérés par AKS.

Paramètres de sécurité

Chiffrement sur l’hôte

Le champ suivant spécifie si le chiffrement au niveau de l’hôte est activé pour les nœuds approvisionnés. Lorsque vous définissez ce champ sur true, NAP inclut uniquement les options d’instance qui prennent en charge le chiffrement au niveau de l’hôte.

spec:
  security:
    encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Pour plus d’informations sur le chiffrement basé sur l’hôte, consultez la documentation chiffrement sur l’hôte.

Clés gérées personnalisées et jeux de chiffrement de disque

NAP prend en charge les clusters qui utilisent des clés gérées par le client et des jeux de chiffrement de disque. Activez ces options au niveau du cluster. Ils n’ont AKSNodeClass pas de champs que vous devez définir. Vérifiez que votre identité de cluster dispose du contrôle d’accès en fonction du rôle approprié (RBAC) :

L’identité du cluster a un accès Reader au jeu de chiffrement de disque.
La ressource du jeu de chiffrement de disque a un accès Key Vault Crypto Service Encryption User à Azure Key Vault.

Pour plus d’informations sur les clés gérées par le client et les ensembles de chiffrement de disque activés lors de la création du cluster, consultez la documentation sur les clés gérées par le client.

Activer le lancement fiable dans les clusters NAP

Les clusters avec l’approvisionnement automatique de nœuds activé (NAP) peuvent activer Trusted Launch en utilisant le champ spec.security.trustedLaunch de la AKSNodeClass CRD. Définissez les champs vTPM et true sur secureBoot pour activer le lancement approuvé pour tous les nœuds gérés par NAP, nouveaux ou existants, associés à ce CRD AKSNodeClass.

spec:
  security:
  # Enables trusted lunch
  # Valid values: true, false; defaults to false if not specified
     trustedLaunch:
       secureBoot: true
       vTPM: true

configuration des étiquettes de ressources Azure

Vous pouvez spécifier Azure balises de ressource qui s’appliquent à toutes les instances de machine virtuelle créées à l’aide d’une ressource AKSNodeClass particulière. Les étiquettes sont utiles pour le suivi des coûts, l’organisation des ressources et les exigences de conformité.

Limitations de balise

Azure balises de ressource ont une limite de 50 balises par ressource.
Les noms d’étiquette ne sont pas sensibles à la casse, alors que les valeurs d’étiquette le sont.
Azure réserve certains noms d'étiquettes qui ne peuvent pas être utilisés. Pour plus d’informations, consultez les instructions et les limites des balises.

Exemple de configuration des balises

spec:
  tags:
    Environment: "production"
    Team: "platform"
    Application: "web-service"
    CostCenter: "engineering"

Exemple de configuration complet `AKSNodeClass`

L’exemple suivant illustre une configuration complète AKSNodeClass qui inclut tous les paramètres abordés dans cet article :

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: comprehensive-example
---
apiVersion: karpenter.azure.com/v1beta1
kind: AKSNodeClass
metadata:
  name: comprehensive-example
spec:
  # Image family configuration
  # Default: Ubuntu
  # Valid values: Ubuntu, AzureLinux, AzureContainerLinux
  imageFamily: Ubuntu

  # FIPS compliant mode - allows support for FIPS-compliant node images
  # Default: Disabled
  # Valid values: FIPS, Disabled
  fipsMode: Disabled

  # Artifact Streaming- allows use of artifact streaming feature; To use this feature container images must also enable artifact streaming on ACR
  # Valid values: true, false; defaults to false if not specified
  artifactStreaming:
    enabled: true

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  # vnetDNSOverrides and kubeDNSOverrides are both required, even when mode is Disabled
  # Each list must include the "." and "cluster.local" zones, and each zone must set all nine fields
  localDNS:
    mode: Disabled
    # vnetDNSOverrides apply to DNS traffic from pods with dnsPolicy:default and from kubelet
    vnetDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: VnetDNS   # the "." zone can't forward to ClusterCoreDNS in vnetDNSOverrides
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS   # cluster.local can't forward to VnetDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
    # kubeDNSOverrides apply to DNS traffic from pods with dnsPolicy:ClusterFirst
    kubeDNSOverrides:
      - zone: "."
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: PreferUDP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"
      - zone: "cluster.local"
        cacheDuration: "3600s"
        forwardDestination: ClusterCoreDNS
        forwardPolicy: Sequential
        maxConcurrent: 1000
        protocol: ForceTCP
        queryLogging: Error
        serveStale: Immediate
        serveStaleDuration: "3600s"

  # Virtual network subnet configuration (optional)
  # If not specified, uses the default --vnet-subnet-id from Karpenter installation
  vnetSubnetID: "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/my-rg/providers/Microsoft.Network/virtualNetworks/my-vnet/subnets/my-subnet"

  # OS disk size configuration
  # Default: 128 GB
  # Minimum: 30 GB
  osDiskSizeGB: 128

  # Maximum pods per node configuration
  # Default behavior depends on network plugin:
  # - Azure CNI with standard networking: 30 pods
  # - Azure CNI with overlay networking: 250 pods
  # - Other configurations: 110 pods
  # Range: 10-250
  maxPods: 30

  # GPU driver installation (optional)
  # Default: driver - NAP manages gpu driver installation
  # none skips gpu driver installation
  # Valid values: driver, none
  gpu:
    mode: 
      driver

  # Azure resource tags (optional)
  # Applied to all VM instances created with this AKSNodeClass
  tags:
    Environment: "production"
    Team: "platform-team"
    Application: "web-service"
    CostCenter: "engineering"

  # Kubelet configuration (optional)
  # All fields are optional with sensible defaults
  kubelet:
    # CPU management policy
    # Default: "none"
    # Valid values: none, static
    cpuManagerPolicy: "static"

    # CPU CFS quota enforcement
    # Default: true
    cpuCFSQuota: true

    # CPU CFS quota period
    # Default: "100ms"
    cpuCFSQuotaPeriod: "100ms"

    # Image garbage collection thresholds
    # imageGCHighThresholdPercent must be greater than imageGCLowThresholdPercent
    # Range: 0-100
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

    # Topology manager policy
    # Default: "none"
    # Valid values: none, restricted, best-effort, single-numa-node
    topologyManagerPolicy: "best-effort"

    # Allowed unsafe sysctls (optional)
    # Comma-separated list of unsafe sysctls or patterns
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"

    # Container log configuration
    # containerLogMaxSize default: "50Mi"
    containerLogMaxSize: "50Mi"
    
    # containerLogMaxFiles default: 5, minimum: 2
    containerLogMaxFiles: 5

    # Pod process limits
    # Default: -1 (unlimited)
    podPidsLimit: 4096

  security:
  # Enables trusted lunch
  # Valid values: true, false; default(or if not specified): false  
     trustedLaunch:
      secureBoot: true
      vTPM: true
  # Encryption at host
     encryptionatHost: 
      # acceptable values: [true, false] default(or if not specified): false  
      false

Étapes suivantes

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

Commentaires

Cette page a-t-elle été utile ?

Dernière mise à jour : 2026-10-26

Configurer les ressources AKSNodeClass pour l’approvisionnement automatique de nœuds (NAP) dans Azure Kubernetes Service (AKS)

Vue d’ensemble des ressources AKSNodeClass

Configuration de la famille d’images

Familles d’images prises en charge

Exemple de configuration de la famille d’images

configuration Azure Container Linux

prise en charge de Windows OS (aperçu)

Configuration de l’image de nœud conforme FIPS

Configuration d’adresse IP publique au niveau de l’instance

Utiliser l’adresse IP publique au niveau de l’instance avec des préfixes

Utiliser une adresse IP publique au niveau de l’instance avec des balises IP et une préférence de routage Internet

Diffusion en continu d'artéfacts

Prerequisites

Activer le streaming d’artefacts dans les clusters NAP

Configuration du sous-réseau de réseau virtuel (VNet)

Exemple de configuration de sous-réseau

Configuration de la taille du disque du système d’exploitation

Exemple de configuration de taille de disque du système d’exploitation

Configuration du disque de système d’exploitation éphémère

Critères de sélection de disque éphémère

Types de disques éphémères et hiérarchisation

Exemple de configuration de disque éphémère

Configuration maximale des pods

Comportement par défaut pour maxPods

Exemple de configuration du nombre maximal de pods

Configuration LocalDNS

Exemple de configuration LocalDNS

Mettre à jour la configuration LocalDNS sur une classe AKSNodeClass existante

Au démarrage du remplacement

Comment NAP orchestre le remplacement

Réduire le risque d’indisponibilité lorsque vous activez LocalDNS

Configuration de kubelet

Gestion du processeur

Garbage collection d’images

Gestion de la topologie

Configuration système

Paramètres de configuration du système d’exploitation personnalisé Linux

Paramètres des limites de descripteurs de fichiers sous Linux

Paramètres de socket Linux et de paramétrage réseau

Paramètres de limite de travail Linux

Paramètres de mémoire virtuelle Linux

Paramètres GPU

GPU géré

Paramètres de sécurité

Chiffrement sur l’hôte

Clés gérées personnalisées et jeux de chiffrement de disque

Activer le lancement fiable dans les clusters NAP

configuration des étiquettes de ressources Azure

Limitations de balise

Exemple de configuration des balises

Exemple de configuration complet AKSNodeClass

Étapes suivantes

Commentaires

Ressources supplémentaires

Comportement par défaut pour `maxPods`

Exemple de configuration complet `AKSNodeClass`