Configurare le risorse AKSNodeClass per il provisioning automatico dei nodi in servizio di Azure Kubernetes (AKS)

Questo articolo illustra come configurare le risorse AKSNodeClass per definire le impostazioni specifiche di Azure per il provisioning automatico dei nodi su Servizio Azure Kubernetes (AKS) utilizzando Karpenter. AKSNodeClass consente di personalizzare vari aspetti dei nodi di cui Karpenter esegue il provisioning, ad esempio l'immagine della macchina virtuale ( VM), le dimensioni del disco del sistema operativo , il numero massimo di pod per nodo e le configurazioni kubelet.

Importante

A partire da November 30, 2025, Servizio Azure Kubernetes (AKS) non supporta più o fornisce aggiornamenti della sicurezza per Azure Linux 2.0. L'immagine del nodo Linux 2.0 di Azure è bloccata alla versione 202512.06.0. A partire dal 31 ottobre 2026, le immagini dei nodi verranno rimosse e non sarà possibile ridimensionare i pool di nodi. Effettuare la migrazione a una versione supportata di Linux su Azure aggiornando i pool di nodi a una versione supportata di Kubernetes o effettuando la migrazione a osSku AzureLinux3. Per altre informazioni, vedere Retirement GitHub issue e annuncio di ritiro degli aggiornamenti di Azure. Per rimanere informati sugli annunci e sugli aggiornamenti, segui le note di rilascio di AKS.

Panoramica delle risorse AKSNodeClass

AKSNodeClass Le risorse consentono di configurare impostazioni specifiche di Azure per NAP. Ogni NodePool risorsa deve fare riferimento a un AKSNodeClass usando spec.template.spec.nodeClassRef. È possibile avere più NodePools che puntano allo stesso AKSNodeClass, consentendo di condividere configurazioni di Azure comuni tra pool di nodi diversi.

Importante

La modifica di un'impostazione su un AKSNodeClass esistente non riconfigura sul posto i nodi in esecuzione. NAP contrassegna i nodi di cui è stato effettuato il provisioning dalla configurazione precedente come in stato di drift e li sostituisce, in base ai controlli di interruzione sulle risorse NodePool che vi fanno riferimento. Il tags campo è l'unica eccezione, perché le modifiche ai tag si applicano alle risorse Azure esistenti senza sostituire il nodo. Per altre informazioni, vedere Deriva e Budget di interruzione. Prima di modificare un AKSNodeClass oggetto usato dai carichi di lavoro di produzione, esaminare queste indicazioni.

Configurazione della famiglia di immagini

Il imageFamily campo imposta l'immagine della macchina virtuale predefinita e la logica di bootstrap per i nodi di cui è stato effettuato il provisioning tramite .AKSNodeClass Se non si specifica una famiglia di immagini, viene usata la versione predefinita del sistema operativo in base alla versione di Kubernetes. Le GPU sono supportate con entrambe le famiglie di immagini in macchine virtuali compatibili. Per ulteriori informazioni sulla versione predefinita del sistema operativo per ciascuna versione di Kubernetes, vedere la documentazione sulla versione del sistema operativo di AKS.

Famiglie di immagini supportate

  • Ubuntu: Ubuntu è la distribuzione Linux predefinita per i nodi del servizio Azure Kubernetes.
    • Le impostazioni predefinite della versione del sistema operativo cambiano in base alla versione di Kubernetes. Ubuntu 22.04 è l'impostazione predefinita per Kubernetes versioni da 1.25 a 1.33. Ubuntu 24.04 è l'impostazione predefinita per Kubernetes 1.34 e versioni successive.
  • AzureLinux: Azure Linux è la distribuzione Linux alternativa di Microsoft per i carichi di lavoro di AKS. Per altre informazioni, vedere la documentazione di Azure Linux.

Configurazione della famiglia di immagini di esempio

L'esempio seguente configura il AKSNodeClass per utilizzare la famiglia di immagini AzureLinux.

spec:
  imageFamily: AzureLinux

Configurazione dell'immagine del nodo conforme a FIPS

È anche possibile abilitare immagini dei nodi conformi a FIPS (Federal Information Processing Standards). Per ulteriori informazioni su FIPS in AKS, vedere la documentazione di FIPS.

Il fipsMode campo è impostato per impostazione predefinita su Disabilitato e può essere impostato sulle opzioni seguenti:

  • FIPS: selezionare immagini dei nodi conformi a FIPS
  • Disabilitato: non usare immagini dei nodi conformi a FIPS

L'esempio seguente configura "AKSNodeClass" per selezionare immagini di nodi conformi a FIPS impostando fipsMode su FIPS:

spec:
  fipsMode: FIPS

Streaming degli artefatti

Artifact Streaming consente di trasmettere immagini del contenitore da Registro Azure Container (ACR) a Servizio Azure Kubernetes (AKS). AKS scarica solo i layer necessari per l'avvio iniziale dei pod, riducendo il tempo necessario per distribuire i carichi di lavoro.

Prerequisiti

  • Artifact Streaming richiede la disponibilità di un'istanza di Registro Azure Container di livello Premium integrata con il cluster AKS.
  • Artifact Streaming deve essere abilitato in ACR.

Consultare la documentazione di Artifact Streaming per istruzioni su come abilitare Artifact Streaming in ACR.

Abilitare lo streaming degli artefatti nei cluster NAP

I cluster con Node Auto Provisioning (NAP) abilitato possono abilitare lo streaming degli artefatti utilizzando il campo spec.artifactStreaming.enabled del CRD AKSNodeClass. Impostare questo campo su true per abilitare lo streaming degli artefatti per qualsiasi nodo nuovo o esistente gestito da NAP associato a questa 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

Per usare lo streaming degli artefatti nei nodi gestiti di AKS NAP, è necessario abilitare anche lo streaming degli artefatti in Registro Azure Container (ACR). Se non si imposta questa opzione in ACR, il campo è impostato su false per impostazione predefinita.

Configurazione della subnet della rete virtuale

Il campo vnetSubnetID specifica quale subnet VNet della rete virtuale di Azure deve essere utilizzata per il provisioning delle interfacce di rete del nodo. Questo campo è facoltativo. Se non si specifica una subnet, NAP usa la subnet predefinita configurata durante l'installazione di Karpenter. Per ulteriori informazioni, vedere Configurazioni della subnet per NAP.

Configurazione di subnet di esempio

L'ID subnet deve essere nel formato completo Azure Resource Manager (ARM), come illustrato nell'esempio seguente:

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

Configurazione delle dimensioni del disco del sistema operativo

Il campo osDiskSizeGB specifica le dimensioni del disco del sistema operativo in gigabyte. Il valore predefinito è 128 GB e il valore minimo è 30 GB.

Prendere in considerazione dimensioni del disco del sistema operativo maggiori per i carichi di lavoro che:

  • Archiviare dati significativi in locale.
  • Richiedi spazio aggiuntivo per le immagini del contenitore.
  • Requisiti elevati di I/O del disco.

Configurazione delle dimensioni del disco del sistema operativo di esempio

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Configurazione temporanea del disco del sistema operativo

NAP usa automaticamente dischi del sistema operativo temporanei se disponibili e se adatti alle dimensioni del disco richieste. I dischi temporanei del sistema operativo offrono prestazioni migliori e costi inferiori rispetto ai dischi gestiti.

Criteri di selezione dei dischi temporanei

Il sistema sceglie automaticamente i dischi temporanei negli scenari seguenti:

  • Il tipo di istanza di macchina virtuale supporta i dischi temporanei del sistema operativo.
  • La capacità del disco effimero è maggiore o uguale alla richiesta osDiskSizeGB.
  • La macchina virtuale ha una capacità di archiviazione temporanea sufficiente.

Se queste condizioni non vengono soddisfatte, il sistema esegue il fallback per l'uso di dischi gestiti.

Tipi di disco temporanei e definizione delle priorità

Azure le macchine virtuali possono avere tipi diversi di archiviazione temporanea. Il sistema usa l'ordine di priorità seguente:

  • Dischi NVMe (prestazioni più elevate)
  • Dischi della cache (prestazioni bilanciate)
  • Dischi delle risorse (prestazioni di base)

Esempio di configurazione temporanea del disco

È possibile usare i requisiti del pool di nodi per garantire che i nodi dispongano di capacità temporanea del disco sufficiente, come illustrato nell'esempio seguente:

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

Questa configurazione garantisce che vengano selezionati solo i tipi di istanza di VM con dischi temporanei di dimensioni superiori a 128 GB, garantendo l'utilizzo temporaneo del disco per le dimensioni del disco del sistema operativo specificate.

Configurazione massima dei pod

Il campo maxPods specifica il numero massimo di pod che possono essere pianificati in un nodo. Questa impostazione influisce sia sulla densità del cluster che sulla configurazione di rete.

Il valore minimo per maxPods è 10 e il valore massimo è 250.

Comportamento predefinito per maxPods

Il comportamento predefinito per maxPods dipende dalla configurazione del plug-in di rete. La tabella seguente riepiloga le impostazioni predefinite:

Configurazione del plug-in di rete Impostazione predefinita maxPods per nodo
Azure CNI con rete standard (v1 o NodeSubnet) 30
Azure CNI con rete sovrapposta 250
Nessuno (nessun plug-in di rete) 250
Altre configurazioni 110 (impostazione predefinita di Kubernetes standard)

Configurazione di esempio per il numero massimo di pod

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

Configurazione localDNS

LocalDNS distribuisce un proxy DNS a livello di nodo che risolve le query DNS più vicine ai carichi di lavoro, riducendo la latenza delle query e migliorando la resilienza durante le interruzioni DNS temporanee. Per altre informazioni, vedere la documentazione di LocalDNS. Per impostazione predefinita, LocalDNS è impostato su Disabilitato e può essere configurato per le opzioni seguenti:

  • Disabled (impostazione predefinita): disabilita la funzionalità LocalDNS. Le query DNS non vengono risolte localmente nel nodo.
  • Preferred, AKS gestisce l'abilitazione di LocalDNS in base alla versione Kubernetes del pool di nodi. La configurazione viene sempre convalidata e inclusa, ma LocalDNS non è abilitata a meno che non venga usata la versione corretta di Kubernetes.
  • Required - LocalDNS viene applicato al pool di nodi se tutti i prerequisiti sono soddisfatti. Se i requisiti non sono soddisfatti, la distribuzione ha esito negativo.

Esempio di configurazione LocalDNS

È possibile personalizzare le configurazioni LocalDNS, vnetDNSOverrides ad esempio e kubeDNSOverrides. Per altri dettagli sui plug-in supportati, vedere Personalizzare 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"

Aggiornare la configurazione LocalDNS in un AKSNodeClass esistente

L'impostazione localDNS partecipa al rilevamento della deriva come altre AKSNodeClass impostazioni. Quando si cambia spec.localDNS su un AKSNodeClass a cui fanno già riferimento nodi esistenti, NAP applica la modifica tramite il meccanismo Drift standard. NAP non ricrea l'immagine dei nodi esistenti.

Il comportamento seguente si applica quando si modifica la modalità LocalDNS o gli override, ad esempio passando mode da Disabled a Required:

  • Nuovi nodi: ogni nodo di cui NAP esegue il provisioning dopo l'aggiornamento di AKSNodeClass usa la nuova configurazione LocalDNS.
  • Nodi esistenti: NAP contrassegna gli oggetti NodeClaim esistenti come in deriva perché la configurazione registrata non corrisponde più a AKSNodeClass. NAP avvia un nodo sostitutivo che usa la nuova configurazione LocalDNS, quindi isola, drena e rimuove il nodo in drift.
  • Nessuna ricreazione dell'immagine: l'attivazione di LocalDNS in un pool di nodi gestito di AKS ricrea l'immagine di ogni nodo nel pool. NAP sostituisce invece il nodo. In entrambi i casi, i pod nei nodi interessati vengono rimossi e ripianificati, quindi pianificare lo stesso impatto sul carico di lavoro.

Importante

L'impostazione di mode su Preferred o Disabled modifica anche la configurazione AKSNodeClass risolta e causa la deriva dei nodi esistenti. Qualsiasi modifica all'interno della localDNS sezione, inclusi i vnetDNSOverrides valori e kubeDNSOverrides , causa la sostituzione del nodo.

All'avvio della sostituzione

La valutazione della deriva e la sostituzione iniziano non appena viene applicato il valore AKSNodeClass aggiornato. La sostituzione segue il ciclo di vita standard delle interruzioni NAP, quindi la frequenza e la tempistica dipendono dai controlli delle interruzioni configurati nelle risorse NodePool che fanno riferimento a AKSNodeClass.

Modalità con cui NAP orchestra la sostituzione

La deriva causata da una modifica di LocalDNS rispetta i controlli standard delle interruzioni NAP descritti nella tabella seguente:

Controllo Effetto sulla sostituzione indotta da LocalDNS
Budget di interruzione (spec.disruption.budgets) Limita la frequenza con cui NAP sostituisce contemporaneamente i nodi. Se non si definiscono budget, NAP viene impostato per impostazione predefinita su un budget di nodes: 10%, quindi interrompe contemporaneamente un massimo del 10% dei nodi del pool di nodi.
Budget schedule e duration Limita la sostituzione a una finestra di manutenzione. Impostare nodes: "0" all'esterno della finestra per bloccare la sostituzione.
Budget di interruzione dei pod (PDB) Si applica durante lo svuotamento del nodo. NAP attende invece di espellere i pod che violano un PDB.
karpenter.sh/do-not-disrupt annotazione Esclude pod e nodi con annotazioni dall'interruzione volontaria, inclusa la deriva.
terminationGracePeriod Limita il tempo di svuotamento. Questa impostazione ignora i PDB e l'annotazione karpenter.sh/do-not-disrupt alla scadenza del periodo.

La sostituzione non è né completamente seriale né completamente parallela. NAP effettua il provisioning della capacità di sostituzione prima di rimuovere un nodo con drift, ma può sostituire più nodi che fanno riferimento contemporaneamente allo stesso AKSNodeClass, fino al limite impostato dai budget di disruption.

Warning

Se non si definiscono budget di interruzione nei pool di nodi e non si definiscono budget di interruzione dei pod per i carichi di lavoro, la modifica di localDNS in un AKSNodeClass occupato può interrompere fino al 10% dei nodi alla volta senza protezione a livello di applicazione, con possibili tempi di inattività del carico di lavoro. Definire i PDB per i carichi di lavoro critici e impostare un budget di interruzione conservativo prima di modificare localDNS in un cluster di produzione.

Ridurre il rischio di indisponibilità quando si abilita LocalDNS

  1. Verificare che i server DNS personalizzati rispondano alle query sia sulla porta UDP 53 sia sulla porta TCP 53 dalla subnet del nodo. Per altre informazioni, vedere Convalidare il DNS personalizzato prima di abilitare LocalDNS.

  2. Definire budget di interruzione dei pod per ogni carico di lavoro critico.

  3. Impostare un budget di interruzione conservativo per le risorse interessate NodePool prima di modificare il AKSNodeClass, come illustrato nell'esempio seguente:

    apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    budgets:
    - nodes: "1"   # Replace one node at a time

  4. Applicare prima la modifica localDNS a un AKSNodeClass non di produzione. In alternativa, creare un oggetto AKSNodeClass con LocalDNS abilitato ed eseguire la migrazione dei carichi di lavoro a un NodePool oggetto che vi fa riferimento.

  5. Monitorare lo stato della sostituzione elencando i NodeClaim. La sostituzione viene completata quando nessuna attestazione del nodo segnala la Drifted condizione di stato.

    # 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>

  6. Verificare che LocalDNS sia attivo nei nodi sostitutivi. Per altre informazioni, vedere Verificare l'operazione LocalDNS.

Configurazione del kubelet

La sezione kubelet consente di configurare vari parametri kubelet che influiscono sul comportamento del nodo. Questi parametri sono argomenti kubelet tipici, quindi il provider Azure li passa semplicemente al kubelet nel nodo.

Importante

Configurare attentamente le impostazioni kubelet e testare prima le modifiche apportate agli ambienti non di produzione.

Gestione della CPU

Le impostazioni seguenti controllano il comportamento di gestione della CPU per kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"
  • cpuManagerPolicy: controlla il modo in cui kubelet alloca le risorse della CPU. Impostare su "static" per l'associazione della CPU nei carichi di lavoro sensibili alla latenza.
  • cpuCFSQuota: abilita la tutela della quota di Utilità di pianificazione completamente equa (CFS) della CPU per i contenitori che specificano i limiti della CPU.
  • cpuCFSQuotaPeriod: imposta il periodo di quota di CPU CFS.

GC delle immagini

Le impostazioni seguenti controllano il comportamento della raccolta dei rifiuti delle immagini per il kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

Queste impostazioni controllano quando kubelet esegue la GC delle immagini del contenitore:

  • imageGCHighThresholdPercent: percentuale di utilizzo del disco che attiva l'operazione di GC delle immagini.
  • imageGCLowThresholdPercent: Percentuale di utilizzo del disco di destinazione dopo la raccolta dei rifiuti.

Gestione della topologia

L'impostazione seguente controlla i criteri di gestione della topologia per kubelet:

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

Il gestore della topologia consente di coordinare l'allocazione delle risorse per i carichi di lavoro sensibili alla latenza tra le risorse della CPU e del dispositivo (ad esempio GPU).

Configurazione del sistema

Le impostazioni seguenti consentono di configurare parametri di sistema aggiuntivi per kubelet:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096
  • allowedUnsafeSysctls: elenco di sysctls non sicuri consentiti che i pod possono usare.
  • containerLogMaxSize: dimensione massima dei file di log del contenitore prima della rotazione.
  • containerLogMaxFiles: numero massimo di file di log del contenitore da conservare.
  • podPidsLimit: numero massimo di processi consentiti in qualsiasi pod.

Impostazioni di configurazione del sistema operativo personalizzate per Linux

La sezione LinuxOSConfig consente di configurare vari parametri kubelet che influiscono sul comportamento del nodo. Questi parametri sono tipici argomenti personalizzati del sistema operativo, quindi il NAP si limita a passarli al kubelet sul nodo.

Per altre informazioni sulle impostazioni di configurazione personalizzate del sistema operativo Linux, sui valori predefiniti e sulle considerazioni, vedere le informazioni di riferimento sui parametri di configurazione dei nodi personalizzati.

Importante

Configurare attentamente le impostazioni del sistema operativo Linux e testare prima le modifiche negli ambienti non di produzione.

Impostazioni relative ai limiti dell'handle di file Linux

Usare le impostazioni seguenti per impostare le impostazioni del file system.

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

Impostazioni di ottimizzazione del socket e della rete Linux

Usare le impostazioni seguenti per impostare l'impostazione TCP e di rete.

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

Impostazioni del limite del ruolo di lavoro Linux

Usare le impostazioni seguenti per impostare l'impostazione del kernel.

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

Impostazioni della memoria virtuale Linux

Utilizzare le opzioni seguenti per regolare il funzionamento del sottosistema di memoria virtuale del kernel Linux e la scrittura su disco dei dati modificati.

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

Impostazioni GPU

Usare il campo seguente per abilitare l'installazione personalizzata del driver GPU, ad esempio con l'operatore 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

Impostazioni di sicurezza

Crittografia a livello di host

Il campo seguente specifica se la crittografia a livello di host è abilitata per i nodi di cui è stato effettuato il provisioning. Quando si imposta questo campo su true, NAP include solo le opzioni di istanza che supportano la crittografia a livello host.

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

Per altre informazioni sulla crittografia basata su host, vedere Crittografia nella documentazione dell'host.

Chiavi gestite personalizzate e set di crittografia del disco

NAP supporta i cluster che usano chiavi gestite dal cliente e set di crittografia dei dischi. Abilitare queste opzioni a livello di cluster. Non hanno AKSNodeClass campi che è necessario impostare. Verificare che per l'identità del cluster sia configurato il controllo degli accessi in base al ruolo (RBAC) appropriato:

  • L'identità del cluster dispone del ruolo Reader per il set di crittografia dischi.
  • Alla risorsa del set di crittografia dischi è assegnato il ruolo Key Vault Crypto Service Encryption User per Azure Key Vault.

Per informazioni sulle chiavi gestite dal cliente e sui set di crittografia dei dischi abilitati durante la creazione del cluster, vedere la documentazione relativa alle chiaviCustomer-Managed.

Abilitare l'avvio attendibile nei cluster NAP

I cluster con Node Auto Provisioning (NAP) abilitato possono abilitare l'avvio attendibile usando il campo spec.security.trustedLaunch del CRD AKSNodeClass. Impostare i campi vTPM e true su secureBoot per abilitare l'avvio attendibile per tutti i nodi nuovi o esistenti gestiti da NAP associati a questo CRD AKSNodeClass.

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

configurazione dei tag delle risorse Azure

È possibile specificare Azure tag di risorsa che si applicano a tutte le istanze di macchina virtuale create usando una determinata risorsa AKSNodeClass. I tag sono utili per tenere traccia di costi, organizzazione delle risorse e requisiti di conformità.

Limitazioni dei tag

  • Azure tag di risorsa hanno un limite di 50 tag per risorsa.
  • I nomi dei tag non fanno distinzione tra maiuscole e minuscole, mentre i valori dei tag distinguono maiuscole e minuscole.
  • Azure riserva alcuni nomi di tag che non possono essere usati. Per altre informazioni, vedere Linee guida e limiti per i tag.

Configurazione dei tag di esempio

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

Esempio di configurazione completo AKSNodeClass

L'esempio seguente illustra una configurazione completa AKSNodeClass che include tutte le impostazioni descritte in questo articolo:

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

Passaggi successivi

Per altre informazioni sul provisioning automatico dei nodi in AKS (Azure Kubernetes Service), vedere gli articoli seguenti:

  • Ultimo aggiornamento: