Partager via

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

Cet article explique comment configurer AKSNodeClass des ressources 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

Depuis le 30 novembre 2025, Azure Kubernetes Service (AKS) ne prend plus en charge ou fournit des 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 mars 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 Kubernetes prise en charge ou en migrant vers osSku AzureLinux3. Pour plus d’informations, consultez [Retrait] Pools de nœuds Azure Linux 2.0 sur AKS.

Vue d’ensemble des ressources AKSNodeClass

AKSNodeClass les 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 communes Azure entre différents pools de nœuds.

Configuration de la famille d’images

Le imageFamily champ détermine l’image de machine virtuelle par défaut et la logique de démarrage pour les nœuds provisionnés via le AKSNodeClass. Si vous ne spécifiez pas de famille d’images, la valeur par défaut est Ubuntu2204. Les GPU sont pris en charge avec les deux familles d’images sur les tailles de machine virtuelle compatibles.

Familles d’images prises en charge

  • Ubuntu: Ubuntu 22.04 Long Term Support (LTS) est la distribution Linux par défaut pour les nœuds AKS.
  • 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

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 du sous-réseau de réseau virtuel (VNet)

Le vnetSubnetID champ spécifie quel sous-réseau de réseau virtuel Azure doit être utilisé pour l’approvisionnement des interfaces réseau de nœud. 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 ARM (Azure Resource Manager), 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

Les machines virtuelles Azure 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:
        apiVersion: karpenter.azure.com/v1beta1
        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 de superposition 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 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 à 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.

Configuration des étiquettes de ressources Azure

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

Limitations de balise

  • Les étiquettes de ressources Azure 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:
        apiVersion: karpenter.azure.com/v1beta1
        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
  imageFamily: Ubuntu

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

  # 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

  # 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

Étapes suivantes

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

  • Last updated on