Configuración de recursos de AKSNodeClass para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS)

Este artículo explica cómo configurar los recursos AKSNodeClass para definir la configuración específica de Azure para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS) mediante Karpenter. AKSNodeClass permite personalizar varios aspectos de los nodos que Karpenter aprovisiona, como la imagen de la máquina virtual( VM), el tamaño del disco del sistema operativo (SO), el número máximo de pods por nodo y las configuraciones de kubelet.

Importante

A partir de November 30, 2025, Azure Kubernetes Service (AKS) ya no admite ni proporciona actualizaciones de seguridad para Azure Linux 2.0. La imagen de nodo de Azure Linux 2.0 queda congelada en la versión 202512.06.0. A partir del 31 de octubre de 2026, se quitarán las imágenes de nodo y no podrá escalar los grupos de nodos. Migre a una versión de Linux de Azure compatible actualizando los grupos de nodos a una versión de Kubernetes compatible o migrando a osSku AzureLinux3. Para obtener más información, consulte la Incidencia de retirada de GitHub y el Anuncio de la retirada de las actualizaciones de Azure. Para mantenerse informado sobre los anuncios y actualizaciones, siga las notas de lanzamiento de AKS.

Información general sobre los recursos de AKSNodeClass

AKSNodeClass los recursos le permiten configurar configuraciones específicas de Azure para NAP. Cada NodePool recurso debe hacer referencia a un AKSNodeClass usando spec.template.spec.nodeClassRef. Puede tener varios NodePools que apunten al mismo AKSNodeClass, lo que le permite compartir configuraciones de Azure comunes en distintos grupos de nodos.

Importante

Cambiar un parámetro en un AKSNodeClass existente no reconfigura los nodos que se están ejecutando en ese momento. NAP marca los nodos aprovisionados a partir de la configuración anterior como desviados y los sustituye, siempre que se respeten los controles de interrupción de los NodePool recursos de referencia. El tags campo es la única excepción, ya que los cambios de etiqueta se aplican a los recursos de Azure existentes sin reemplazar el nodo. Para obtener más información, consulte Desviación y Presupuestos de interrupción. Antes de modificar un AKSNodeClass que usan las cargas de trabajo de producción, revise esta guía.

Configuración de la familia de imágenes

El imageFamily campo establece la imagen de máquina virtual predeterminada y la lógica de arranque para los nodos aprovisionados a través de AKSNodeClass. Si no especifica una familia de imágenes, se usa la versión predeterminada del sistema operativo según la versión de Kubernetes. Las GPU se admiten con ambas familias de imágenes en tamaños de máquina virtual compatibles. Para más información sobre la versión predeterminada del sistema operativo por versión de Kubernetes, consulte la documentación de la versión del sistema operativo de AKS.

Familias de imágenes admitidas

Ubuntu: Ubuntu es la distribución predeterminada de Linux para los nodos de AKS.
- Los valores predeterminados de la versión del sistema operativo cambian en función de la versión de Kubernetes. Ubuntu 22.04 es el valor predeterminado para las versiones de Kubernetes 1.25 a 1.33. Ubuntu 24.04 es el valor predeterminado para las versiones 1.34 y posteriores de Kubernetes.
AzureLinux: Azure Linux es la distribución alternativa de Linux de Microsoft para cargas de trabajo de AKS. Para más información, consulte la documentación de Azure Linux.

Configuración de familia de imágenes de ejemplo

En el ejemplo siguiente se configura el AKSNodeClass para usar la familia de imágenes AzureLinux.

spec:
  imageFamily: AzureLinux

Configuración de imagen de nodo compatible con FIPS

También puede habilitar imágenes de nodo compatibles con los estándares federales de procesamiento de información (FIPS). Para obtener más información sobre FIPS en AKS, consulte la documentación de FIPS.

El fipsMode campo se establece de forma predeterminada en Deshabilitado y se puede establecer en las siguientes opciones:

FIPS: selección de imágenes de nodo compatibles con FIPS
Deshabilitado: no usar imágenes de nodo compatibles con FIPS

En el ejemplo siguiente se configura "AKSNodeClass" para seleccionar imágenes de nodo compatibles con FIPS estableciendo fipsMode en FIPS.

spec:
  fipsMode: FIPS

Streaming de artefactos

Artifact Streaming permite transmitir imágenes de contenedor de Azure Container Registry (ACR) a Azure Kubernetes Service (AKS). AKS solo extrae las capas necesarias para el inicio inicial del pod, lo que reduce el tiempo que se tarda en implementar las cargas de trabajo.

Prerequisites

Artifact Streaming requiere que tenga un ACR de nivel Premium integrado con el clúster de AKS.
Artifact Streaming debe estar habilitado en ACR.

Consulte la documentación de Artifact Streaming para obtener instrucciones sobre cómo habilitar Artifact Streaming en ACR.

Habilitar la transmisión de artefactos en clústeres NAP

Los clústeres con aprovisionamiento automático de nodos (NAP) habilitado pueden habilitar la transmisión de artefactos mediante el campo spec.artifactStreaming.enabled de la CRD AKSNodeClass. Establezca este campo en true para habilitar la transmisión de artefactos para cualquier nodo administrado por NAP, ya sea nuevo o existente, asociado a esta 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

Nota:

Para usar el streaming de artefactos en nodos administrados de NAP de AKS, también debe habilitar el streaming de artefactos en Azure Container Registry (ACR). Si no establece esta opción en ACR, el campo tiene como valor predeterminado false.

Configuración de subred de red virtual (VNet)

El campo vnetSubnetID especifica qué subred de Azure VNet se debe utilizar para aprovisionar las interfaces de red de nodo. Este campo es opcional. Si no especifica una subred, NAP usa la subred predeterminada configurada durante la instalación de Karpenter. Para obtener más información, consulte Configuraciones de subred para NAP.

Configuración de subred de ejemplo

El identificador de subred debe estar en el formato completo del Azure Resource Manager (ARM), como se muestra en el ejemplo siguiente:

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

Configuración del tamaño del disco del sistema operativo

El osDiskSizeGB campo especifica el tamaño del disco del sistema operativo en gigabytes. El valor predeterminado es 128 GB y el valor mínimo es 30 GB.

Considere los tamaños de disco del sistema operativo más grandes para las cargas de trabajo que:

Almacene datos significativos localmente.
Requerir espacio adicional para las imágenes de contenedor.
Tiene requisitos elevados de E/S de disco.

Configuración de tamaño de disco del sistema operativo de ejemplo

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Configuración del disco del sistema operativo efímero

NAP usa automáticamente discos del sistema operativo efímeros cuando están disponibles y adecuados para el tamaño de disco solicitado. Los discos del sistema operativo efímeros proporcionan un mejor rendimiento y un menor costo en comparación con los discos administrados.

Criterios de selección de disco efímero

El sistema elige automáticamente discos efímeros en los escenarios siguientes:

El tipo de instancia de máquina virtual admite discos de sistema operativo efímeros.
La capacidad del disco efímero es mayor o igual que la solicitada osDiskSizeGB.
La máquina virtual tiene suficiente capacidad de almacenamiento efímero.

Si no se cumplen estas condiciones, el sistema vuelve al uso de discos administrados.

Tipos de disco efímeros y priorización

Azure máquinas virtuales pueden tener diferentes tipos de almacenamiento efímero. El sistema usa el siguiente orden de prioridad:

Discos NVMe (rendimiento más alto)
Discos de caché (rendimiento equilibrado)
Discos de recursos (rendimiento básico)

Ejemplo de configuración de disco efímero

Puede usar los requisitos del grupo de nodos para asegurarse de que los nodos tienen suficiente capacidad de disco efímero, como se muestra en el ejemplo siguiente:

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

Esta configuración garantiza que solo se seleccionan los tipos de instancia de máquina virtual con discos efímeros de más de 128 GB, lo que garantiza el uso de disco efímero para el tamaño de disco del sistema operativo especificado.

Configuración máxima de pods

El campo maxPods especifica el número máximo de pods que se pueden programar en un nodo. Esta configuración afecta tanto a la densidad del clúster como a la configuración de red.

El valor mínimo de maxPods es 10 y el valor máximo es 250.

Comportamiento predeterminado para `maxPods`

El comportamiento predeterminado de maxPods depende de la configuración del complemento de red. En la tabla siguiente se resumen los valores predeterminados:

Configuración del complemento de red	Valor predeterminado `maxPods` por nodo
Azure CNI con redes estándar (v1 o NodeSubnet)	30
Azure CNI con redes superpuestas	250
Ninguno (sin complemento de red)	250
Otras configuraciones	110 (valor predeterminado estándar de Kubernetes)

Ejemplo de configuración máxima de pods

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

Configuración de LocalDNS

LocalDNS implementa un proxy DNS de nivel de nodo que resuelve las consultas DNS más cercanas a las cargas de trabajo, lo que reduce la latencia de las consultas y mejora la resistencia durante las interrupciones transitorias de DNS. Para obtener más información, consulte la documentación de LocalDNS. De forma predeterminada, LocalDNS se establece en Deshabilitado y se puede configurar en las siguientes opciones:

Disabled (valor predeterminado): deshabilita la característica LocalDNS. Las consultas DNS no se resuelven localmente en el nodo.
Preferred - AKS administra la habilitación de LocalDNS en función de la versión de Kubernetes del grupo de nodos. La configuración siempre se valida e incluye, pero LocalDNS no está habilitada a menos que se use la versión correcta de Kubernetes.
Required - LocalDNS se aplica en el grupo de nodos si se cumplen todos los requisitos previos. Si no se cumplen los requisitos, se produce un error en la implementación.

Configuración de LocalDNS de ejemplo

Puede personalizar las configuraciones de LocalDNS, como vnetDNSOverrides y kubeDNSOverrides. Para obtener más información sobre los complementos admitidos, consulte Personalización de 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"

Actualiza la configuración de LocalDNS en una clase AKSNodeClass existente

La configuración localDNS participa en la detección de desviaciones al igual que otras configuraciones AKSNodeClass. Cuando se modifica spec.localDNS en un AKSNodeClass al que ya hacen referencia los nodos existentes, NAP aplica el cambio a través del mecanismo estándar Desviación. NAP no vuelve a crear la imagen de los nodos existentes.

El siguiente comportamiento se aplica al cambiar el modo LocalDNS o las anulaciones, como cambiar mode de Disabled a Required:

Nuevos nodos: todos los nodos que NAP aprovisione después de actualizar el AKSNodeClass utilizan la nueva configuración de LocalDNS.
Nodos existentes: NAP marca los objetos NodeClaim existentes como desviados porque su configuración registrada ya no coincide con el AKSNodeClass. NAP inicia un nodo de sustitución que utiliza la nueva configuración de LocalDNS y, a continuación, aísla, vacía y elimina el nodo desviado.
Sin restablecimiento de la imagen: Al habilitar LocalDNS en un grupo de nodos administrado por AKS, se vuelve a crear la imagen de todos los nodos del grupo. NAP reemplaza el nodo en su lugar. En cualquier caso, los pods de los nodos afectados se expulsan y se vuelven a programar, por lo que prevea el mismo impacto en la carga de trabajo.

Importante

Establecer mode en Preferred o Disabled también cambia la AKSNodeClass configuración resuelta y provoca desviaciones en los nodos existentes. Cualquier cambio dentro de la sección localDNS, incluidos los valores vnetDNSOverrides y kubeDNSOverrides, provoca el reemplazo del nodo.

Cuando se inicia el reemplazo

La evaluación de desviaciones y la sustitución comienzan tan pronto como se aplica el AKSNodeClass actualizado. La sustitución sigue el ciclo de vida estándar de interrupciones de NAP, por lo que la frecuencia y el momento dependen de los controles de interrupción que se configuren en los recursos NodePool que hacen referencia a AKSNodeClass.

Cómo NAP organiza el reemplazo

La desviación provocada por un cambio en LocalDNS respeta los controles de interrupción estándar de NAP descritos en la siguiente tabla:

Control	Efecto en el reemplazo inducido por LocalDNS
Presupuestos de interrupción (`spec.disruption.budgets`)	La frecuencia limita el número de nodos que NAP sustituye a la vez. Si no se definen presupuestos, NAP establece por defecto un presupuesto de `nodes: 10%`, por lo que interrumpe simultáneamente un máximo del 10 por ciento de los nodos del conjunto de nodos.
Presupuesto `schedule` y `duration`	Limita el reemplazo a una ventana de mantenimiento. Establezca `nodes: "0"` fuera de la ventana para bloquear la sustitución.
presupuesto de interrupción de pods (PDB)	Aplíquelo durante el drenaje de nodos. NAP espera en lugar de desalojar pods que infringen una PDB.
`karpenter.sh/do-not-disrupt` anotación	Excluye los pods y nodos anotados de la interrupción voluntaria, incluida la desviación.
`terminationGracePeriod`	Limita el tiempo de drenaje. Esta configuración omite los archivos PDB y la `karpenter.sh/do-not-disrupt` anotación cuando transcurre el período.

El reemplazo no es totalmente en serie ni totalmente en paralelo. NAP aprovisiona capacidad de sustitución antes de eliminar un nodo desviado, pero puede sustituir simultáneamente varios nodos que hagan referencia al mismo AKSNodeClass, hasta el límite establecido por sus presupuestos de interrupción.

Warning

Si no define presupuestos de interrupciones en los grupos de nodos y no define presupuestos de interrupciones de pods para las cargas de trabajo, cambiar localDNS en un AKSNodeClass con mucha actividad puede interrumpir hasta el 10 % de los nodos a la vez sin protección en el nivel de aplicación, lo que puede provocar tiempo de inactividad de la carga de trabajo. Defina archivos PDB para cargas de trabajo críticas y establezca un presupuesto de interrupción conservador antes de cambiar localDNS en un clúster de producción.

Reducir el riesgo de disponibilidad al habilitar LocalDNS

Confirme que sus servidores DNS personalizados responden a las consultas tanto a través de UDP como del puerto TCP 53 desde la subred de nodos. Para obtener más información, consulte Validar DNS personalizado antes de habilitar LocalDNS.
Defina los presupuestos de interrupción de pods para cada carga de trabajo crítica.
Establezca un presupuesto de interrupción conservador en los recursos NodePool afectados antes de cambiar el AKSNodeClass, tal y como se muestra en el siguiente ejemplo:
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
    - nodes: "1"   # Replace one node at a time
```
Aplique primero el localDNS cambio a un entorno no productivo AKSNodeClass. Como alternativa, cree un AKSNodeClass que tenga LocalDNS habilitado y migre cargas de trabajo a un NodePool que haga referencia a él.

Supervisa el progreso de la sustitución enumerando las reclamaciones de los nodos. La sustitución se completa cuando ninguna reclamación de nodo informa de la condición de estado 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>

Confirme que LocalDNS está activo en los nodos de reemplazo. Para obtener más información, consulte Comprobación de la operación LocalDNS.

Configuración de kubelet

La sección kubelet permite configurar varios parámetros de kubelet que afectan al comportamiento del nodo. Estos parámetros son argumentos de kubelet típicos, por lo que el proveedor de Azure simplemente los pasa al kubelet en el nodo.

Importante

Configure los valores de kubelet cuidadosamente y pruebe primero los cambios en entornos que no son de producción.

Administración de CPU

La siguiente configuración controla el comportamiento de administración de CPU para kubelet:

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

cpuManagerPolicy: controla cómo el kubelet asigna recursos de CPU. Establézcalo en "static" para la asignación de CPU en cargas de trabajo sensibles a la latencia.
cpuCFSQuota: habilita la aplicación de cuotas del programador completamente justo (CFS) de CPU para contenedores que especifican límites de CPU.
cpuCFSQuotaPeriod: establece el período de cuota CFS de CPU.

Recolección de elementos no utilizados de imagen

Los valores siguientes controlan el comportamiento de la recolección de elementos no utilizados de la imagen para kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Estos controles de configuración controlan cuando kubelet realiza la recolección de elementos no utilizados de imágenes de contenedor:

imageGCHighThresholdPercent: Porcentaje de uso de disco que desencadena la recolección de basura de imágenes.
imageGCLowThresholdPercent: porcentaje de uso del disco objetivo después de la recolección de basura.

Administración de topologías

La siguiente configuración controla la directiva del administrador de topologías para kubelet:

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

El administrador de topologías ayuda a coordinar la asignación de recursos para cargas de trabajo sensibles a la latencia entre recursos de CPU y dispositivo (como GPU).

Configuración del sistema

Las siguientes opciones permiten configurar parámetros de sistema adicionales para kubelet:

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

allowedUnsafeSysctls: lista de sysctls no seguros permitidos que los pods pueden usar.
containerLogMaxSize: tamaño máximo de los archivos de registro de contenedor antes de la rotación.
containerLogMaxFiles: número máximo de archivos de registro de contenedor que se van a conservar.
podPidsLimit: número máximo de procesos permitidos en cualquier pod.

Opciones de configuración del sistema operativo personalizado de Linux

La sección LinuxOSConfig permite configurar varios parámetros de kubelet que afectan al comportamiento del nodo. Estos parámetros son argumentos típicos del sistema operativo personalizado, por lo que NAP simplemente los pasa al kubelet en el nodo.

Para obtener más información sobre las opciones de configuración del sistema operativo Linux personalizadas, los valores predeterminados y las consideraciones, consulte la referencia de parámetros de configuración del nodo personalizado.

Importante

Configure cuidadosamente las opciones del sistema operativo Linux y pruebe primero los cambios en entornos que no sean de producción.

Configuración de límites de control de archivos de Linux

Use la siguiente configuración para establecer la configuración del sistema de archivos.

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

Configuración del socket de Linux y la optimización de red

Use la siguiente configuración para establecer la configuración TCP y de red.

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

Configuración del límite de trabajo de Linux

Use la siguiente configuración para establecer la configuración del kernel.

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

Configuración de memoria virtual linux

Use las siguientes opciones para ajustar el funcionamiento del subsistema de memoria virtual Linux del kernel de Linux y la escritura de datos sucios en el disco.

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

Configuración de GPU

Use el siguiente campo para habilitar la instalación personalizada del controlador de GPU, como con el operador de 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

Configuración de seguridad

Cifrado en el host

El campo siguiente especifica si el cifrado de nivel de host está habilitado para los nodos aprovisionados. Cuando establece este campo en true, NAP solo incluye opciones de instancia que admiten el cifrado en el host.

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

Para obtener más información sobre el cifrado basado en host, consulte la documentación sobre cifrado en host.

Conjuntos de cifrado de discos y claves administradas personalizadas

NAP admite clústeres que usan claves administradas por el cliente y conjuntos de cifrado de disco. Habilite estas opciones en el nivel de clúster. No tienen AKSNodeClass campos que necesite establecer. Asegúrese de que la identidad del clúster tenga el control de acceso basado en rol (RBAC) adecuado:

La identidad del clúster tiene acceso Reader al conjunto de cifrado de disco.
El recurso de conjunto de cifrado de disco tiene acceso Key Vault Crypto Service Encryption User a Azure Key Vault.

Para obtener información sobre las claves administradas por el cliente y los conjuntos de cifrado de disco habilitados durante la creación del clúster, consulte la documentación sobre claves administradas por el cliente.

Habilitar trusted launch en clústeres NAP

Los clústeres con aprovisionamiento automático de nodos (NAP) habilitados pueden habilitar el inicio de confianza mediante el spec.security.trustedLaunch campo de LA CRD de AKSNodeClass. Establezca los campos vTPM y true en secureBoot para habilitar el inicio de confianza para los nodos administrados por NAP nuevos o existentes asociados a este CRD AKSNodeClass.

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

configuración de etiquetas de recursos de Azure

Puede especificar etiquetas de recursos de Azure que se aplican a todas las instancias de máquina virtual creadas mediante un determinado recurso de AKSNodeClass. Las etiquetas son útiles para el seguimiento de costos, la organización de recursos y los requisitos de cumplimiento.

Limitaciones de etiquetas

Azure etiquetas de recursos tienen un límite de 50 etiquetas por recurso.
Los nombres de las etiquetas no distinguen mayúsculas ye minúsculas, pero sus valores sí.
Azure reserva algunos nombres de etiqueta que no se pueden usar. Para obtener más información, consulte Guía y límites de etiquetas.

Configuración de etiquetas de ejemplo

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

Ejemplo de configuración completo `AKSNodeClass`

En el ejemplo siguiente se muestra una configuración completa AKSNodeClass que incluye todas las opciones descritas en este artículo:

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

Pasos siguientes

Para obtener más información sobre el aprovisionamiento automático de nodos en AKS, consulte los siguientes artículos:

Comentarios

¿Le ha resultado útil esta página?

Se actualizó por última vez el 2026-10-12

Configuración de recursos de AKSNodeClass para el aprovisionamiento automático de nodos (NAP) en Azure Kubernetes Service (AKS)

Información general sobre los recursos de AKSNodeClass

Configuración de la familia de imágenes

Familias de imágenes admitidas

Configuración de familia de imágenes de ejemplo

Configuración de imagen de nodo compatible con FIPS

Streaming de artefactos

Prerequisites

Habilitar la transmisión de artefactos en clústeres NAP

Configuración de subred de red virtual (VNet)

Configuración de subred de ejemplo

Configuración del tamaño del disco del sistema operativo

Configuración de tamaño de disco del sistema operativo de ejemplo

Configuración del disco del sistema operativo efímero

Criterios de selección de disco efímero

Tipos de disco efímeros y priorización

Ejemplo de configuración de disco efímero

Configuración máxima de pods

Comportamiento predeterminado para maxPods

Ejemplo de configuración máxima de pods

Configuración de LocalDNS

Configuración de LocalDNS de ejemplo

Actualiza la configuración de LocalDNS en una clase AKSNodeClass existente

Cuando se inicia el reemplazo

Cómo NAP organiza el reemplazo

Reducir el riesgo de disponibilidad al habilitar LocalDNS

Configuración de kubelet

Administración de CPU

Recolección de elementos no utilizados de imagen

Administración de topologías

Configuración del sistema

Opciones de configuración del sistema operativo personalizado de Linux

Configuración de límites de control de archivos de Linux

Configuración del socket de Linux y la optimización de red

Configuración del límite de trabajo de Linux

Configuración de memoria virtual linux

Configuración de GPU

Configuración de seguridad

Cifrado en el host

Conjuntos de cifrado de discos y claves administradas personalizadas

Habilitar trusted launch en clústeres NAP

configuración de etiquetas de recursos de Azure

Limitaciones de etiquetas

Configuración de etiquetas de ejemplo

Ejemplo de configuración completo AKSNodeClass

Pasos siguientes

Comentarios

Recursos adicionales

Comportamiento predeterminado para `maxPods`

Ejemplo de configuración completo `AKSNodeClass`