Konfigurera AKSNodeClass-resurser för automatisk etablering av noder (NAP) i Azure Kubernetes Service (AKS)

Den här artikeln beskriver hur du konfigurerar AKSNodeClass resurser för att definiera Azure-specifika inställningar för automatisk nodetablering (NAP) i Azure Kubernetes Service (AKS) med Karpenter. AKSNodeClass gör att du kan anpassa olika aspekter av de noder som Karpenter etablerar, till exempel VM-avbildningen, operativsystemdiskstorleken (OS), maximalt antal poddar per nod och kubelet-konfigurationer.

Viktigt!

Från och med November 30, 2025 Azure Kubernetes Service (AKS) inte längre stöder eller tillhandahåller säkerhetsuppdateringar för Azure Linux 2.0. Azure Linux 2.0-nodbilden är fastlåst på versionen 202512.06.0. Från och med den 31 oktober 2026 tas nodbilder bort och du kan inte skala dina nodpooler. Migrera till en Azure Linux-version som stöds genom att uppgradera dina nodpooler till en Kubernetes-version som stöds eller migrera till osSku AzureLinux3. Mer information finns i pensionsfrågan på GitHub och pensionsmeddelandet från Azure Updates. För att hålla dig informerad om meddelanden och uppdateringar, följ AKS-versionsinformation.

Översikt över AKSNodeClass-resurser

AKSNodeClass resurser gör att du kan konfigurera Azure-specifika inställningar för NAP. Varje NodePool resurs måste hänvisa till en AKSNodeClass med spec.template.spec.nodeClassRef. Du kan ha flera NodePools som pekar på samma AKSNodeClass, så att du kan dela vanliga Azure konfigurationer i olika nodpooler.

Viktigt!

Om du ändrar en inställning på en befintlig AKSNodeClass omkonfigurerar det inte de noder som körs på plats. NAP markerar de noder som etablerades från den tidigare konfigurationen som i drift och ersätter dem, beroende på störningskontrollerna för de refererande resurserna NodePool. Fältet tags är det enda undantaget eftersom taggändringar gäller för befintliga Azure resurser utan att ersätta noden. Se Drift och avbrottsbudgetar. Innan du ändrar en AKSNodeClass som produktionsarbetsbelastningar använder bör du läsa den här vägledningen.

Konfiguration av bildfamilj

Fältet imageFamily anger standardlogik för vm-avbildning och bootstrapping för noder som etablerats via AKSNodeClass. Om du inte anger en avbildningsfamilj används standardversionen av operativsystemet enligt kubernetes-versionen. GPU:er stöds med båda avbildningsfamiljerna i kompatibla VM-storlekar. Mer information om standardversionen av operativsystemet per Kubernetes-version finns i dokumentationen om AKS OS-version.

Bildfamiljer som stöds

  • Ubuntu: Ubuntu är standarddistributionen av Linux för AKS-noder.
    • Os-versionen ändras som standard baserat på din Kubernetes-version. Ubuntu 22.04 är standard för Kubernetes version 1.25 till 1.33. Ubuntu 24.04 är standard för Kubernetes version 1.34 och senare.
  • AzureLinux: Azure Linux är Microsoft alternativa Linux-distribution för AKS-arbetsbelastningar. Mer information finns i dokumentationen om Azure Linux.

Exempel på konfiguration av bildfamilj

I följande exempel konfigureras AKSNodeClass att använda avbildningsfamiljen AzureLinux :

spec:
  imageFamily: AzureLinux

Konfiguration av FIPS-kompatibel nodbild

Du kan också aktivera FIPS-kompatibla nodbilder (Federal Information Processing Standards). Mer information om FIPS i AKS finns i FIPS-dokumentationen.

Fältet fipsMode är som standard inställt på Inaktiverad och kan ställas in på följande alternativ:

  • FIPS – välj FIPS-kompatibla nodbilder
  • Inaktiverad – använd inte FIPS-kompatibla nodbilder

I följande exempel konfigureras AKSNodeClass för att välja FIPS-kompatibla nodavbildningar genom att ange fipsMode till FIPS:

spec:
  fipsMode: FIPS

Artefaktströmning

Med Artefaktströmning kan du strömma containeravbildningar från Azure Container Registry (ACR) till Azure Kubernetes Service (AKS). AKS hämtar bara de nödvändiga lagren för den första poddstarten, vilket minskar den tid det tar att distribuera dina arbetsbelastningar.

Förutsättningar

  • Artefaktströmning kräver att du har en Premium-nivå-ACR integrerad med ditt AKS-kluster.
  • Artefaktströmning måste vara aktiverat i ACR.

Mer information om hur du aktiverar artefaktströmning i ACR finns i dokumentationen för artefaktströmning .

Aktivera artefaktströmning i NAP-kluster

Kluster med NAP (Node Auto Provisioning) aktiverat kan aktivera artefaktströmning med hjälp spec.artifactStreaming.enabled av fältet i AKSNodeClass CRD. Ange det här fältet till true för att aktivera artefaktströmning för alla nya eller befintliga NAP-hanterade noder som är associerade med denna AKSNodeClass CRD.

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

Om du vill använda artefaktströmning på AKS NAP-hanterade noder måste du även aktivera artefaktströmning i Azure Container Registry (ACR). Om du inte anger det här alternativet i ACR är fältet som standard falskt.

Konfiguration av virtuellt nätverk (VNet) undernät

Fältet vnetSubnetID anger vilka Azure VNet-undernät som ska användas för etablering av nodnätverksgränssnitt. Det här fältet är valfritt. Om du inte anger något undernät använder NAP det standardundernät som konfigurerades under Karpenter-installationen. Mer information finns i Undernätskonfigurationer för NAP.

Exempel på konfiguration av undernät

Undernäts-ID:t måste vara i fullständigt Azure Resource Manager (ARM)-format, som du ser i följande exempel:

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

Konfiguration av os-diskstorlek

Fältet osDiskSizeGB anger storleken på OS-disken i gigabyte. Standardvärdet är 128 GB och minimivärdet är 30 GB.

Överväg större os-diskstorlekar för arbetsbelastningar som:

  • Lagra betydande data lokalt.
  • Kräv extra utrymme för containeravbildningar.
  • Har höga I/O-krav för diskar.

Exempel på konfiguration av os-diskstorlek

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

Tillfälliga os-diskkonfigurationer

NAP använder automatiskt tillfälliga OS-diskar när de är tillgängliga och lämpliga för den begärda diskstorleken. Tillfälliga OS-diskar ger bättre prestanda och lägre kostnad jämfört med hanterade diskar.

Tillfälliga urvalsvillkor för diskar

Systemet väljer automatiskt tillfälliga diskar i följande scenarier:

  • Vm-instanstypen stöder tillfälliga OS-diskar.
  • Den tillfälliga diskkapaciteten är större än eller lika med den begärda osDiskSizeGB.
  • Den virtuella datorn har tillräckligt med tillfällig lagringskapacitet.

Om dessa villkor inte uppfylls återgår systemet till att använda hanterade diskar.

Tillfälliga disktyper och prioritering

Azure virtuella datorer kan ha olika typer av tillfällig lagring. Systemet använder följande prioritetsordning:

  • NVMe-diskar (högsta prestanda)
  • Cachediskar (balanserade prestanda)
  • Resursdiskar (grundläggande prestanda)

Exempel på tillfällig diskkonfiguration

Du kan använda nodpoolkrav för att säkerställa att noderna har tillräcklig tillfällig diskkapacitet, som du ser i följande exempel:

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

Den här konfigurationen säkerställer att endast vm-instanstyper med tillfälliga diskar som är större än 128 GB väljs, vilket garanterar tillfällig diskanvändning för den angivna os-diskstorleken.

Maximal konfiguration för pods

Fältet maxPods anger det maximala antalet poddar som kan schemaläggas på en nod. Den här inställningen påverkar både klusterdensitet och nätverkskonfiguration.

Minimivärdet för maxPods är 10 och det maximala värdet är 250.

Standardbeteende för maxPods

Standardbeteendet för maxPods beror på nätverkskonfigurationen för plugin-programmet. I följande tabell sammanfattas standardvärdena:

Konfiguration av plugin-program för nätverk Standard maxPods per nod
Azure CNI med standardnätverk (v1 eller NodeSubnet) 30
Azure CNI med överläggsnätverk 250
Ingen (inget plugin-program för nätverk) 250
Andra konfigurationer 110 (standardinställning för Kubernetes)

Exempel på maximal poddkonfiguration

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

LocalDNS-konfiguration

LocalDNS distribuerar en DNS-proxy på nodnivå som löser DNS-frågor närmare arbetsbelastningar, vilket minskar frågesvarstiden och förbättrar återhämtning under tillfälliga DNS-avbrott. Mer information finns i LocalDNS-dokumentationen. Som standard är LocalDNS inställt på Inaktiverad och kan konfigureras till följande alternativ:

  • Disabled (standard) – Inaktiverar funktionen LocalDNS. DNS-frågor löses inte upp lokalt på noden.
  • Preferred – AKS hanterar LocalDNS-aktivering baserat på Kubernetes-versionen av nodpoolen. Konfigurationen verifieras och ingår alltid, men LocalDNS är inte aktiverat om inte rätt Kubernetes-version används.
  • Required – LocalDNS tillämpas på nodpoolen om alla krav är uppfyllda. Om kraven inte uppfylls misslyckas distributionen.

Exempel på LocalDNS-konfiguration

Du kan anpassa LocalDNS-konfigurationer som vnetDNSOverrides och kubeDNSOverrides. Mer information om plugin-program som stöds finns i Anpassa 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"

Uppdatera LocalDNS-konfigurationen på en befintlig AKSNodeClass

Inställningen localDNS deltar i driftavkänning som andra AKSNodeClass inställningar. När du ändrar spec.localDNS på en AKSNodeClass som befintliga noder redan refererar till tillämpar NAP ändringen via standardmekanismen Drift. NAP installerar inte om avbildningen på befintliga noder.

Följande beteende gäller när du ändrar LocalDNS-läget eller åsidosättningar, till exempel ändra mode från Disabled till Required:

  • Nya noder: Varje nod som NAP etablerar när du har uppdaterat AKSNodeClass använder den nya LocalDNS-konfigurationen.
  • Befintliga noder: NAP markerar de befintliga NodeClaim objekten som avvikande eftersom deras registrerade konfiguration inte längre matchar AKSNodeClasskonfigurationen. NAP startar en ersättningsnod som använder den nya LocalDNS-konfigurationen, sedan spärrar, dränerar och tar bort noden som har drivit iväg.
  • Ingen ominstallation: Om du aktiverar LocalDNS i en AKS-hanterad nodpool ominstalleras varje nod i poolen. NAP ersätter noden i stället. Hur som helst vräks poddar på de berörda noderna och schemaläggs om, så planera för samma arbetsbelastningspåverkan.

Viktigt!

Att ställa in mode till Preferred eller Disabled ändrar även den lösta AKSNodeClass-konfigurationen och får befintliga noder att drifta. Alla ändringar i localDNS-avsnittet, inklusive vnetDNSOverrides-värdena och kubeDNSOverrides-värdena, orsakar nodbyte.

När ersättningen startar

Driftutvärderingen och ersättningen börjar så snart du tillämpar den uppdaterade AKSNodeClass. Ersättningen följer som standard NAP-störningslivscykeln, så takten och tidpunkten beror på de avbrottskontroller som du konfigurerar på de NodePool resurser som refererar till AKSNodeClass.

Hur NAP hanterar samordningen av ersättning

Drift som orsakas av en LocalDNS-ändring följer standardkontrollerna för NAP-avbrott som beskrivs i följande tabell:

Control Effekt på LocalDNS-inducerad ersättning
Avbrottsbudgetar (spec.disruption.budgets) Frekvensbegränsning begränsar hur många noder NAP ersätter samtidigt. Om du inte definierar budgetar är standardvärdet för NAP en budget på nodes: 10%, så det stör högst 10 procent av nodpoolens noder samtidigt.
Budget schedule och duration Begränsar utbytet till en underhållsperiod. Placera nodes: "0" utanför fönstret för att blockera utbyte.
störningsbudgetar för poddar (PDB:er) Används vid noddränering. NAP väntar i stället för att avlägsna poddar som bryter mot ett PDB.
karpenter.sh/do-not-disrupt anteckning Undantar annoterade pods och noder från frivilliga avbrott, inklusive drift.
terminationGracePeriod Dräneringstid för kapslar Den här inställningen kringgår PDB:er och anteckningen karpenter.sh/do-not-disrupt när punkten passeras.

Ersättningen är varken helt seriell eller helt parallell. NAP etablerar ersättningskapacitet innan den tar bort en nod med konfigurationsavvikelse, men den kan ersätta flera noder som refererar till samma AKSNodeClass samtidigt, upp till den gräns som dina disruption budgets anger.

Varning

Om du inte definierar avbrottsbudgetar för dina nodpooler och inte definierar poddavbrottsbudgetar för dina arbetsbelastningar kan det, om du ändrar localDNS i en upptagen AKSNodeClass, störa upp till 10 procent av noderna samtidigt utan skydd på applikationsnivå, vilket kan orsaka avbrott i arbetsbelastningen. Definiera PDB:er för kritiska arbetsbelastningar och ange en konservativ avbrottsbudget innan du ändrar localDNS i ett produktionskluster.

Minska tillgänglighetsrisken när du aktiverar LocalDNS

  1. Bekräfta att dina anpassade DNS-servrar svarar på frågor över både UDP- och TCP-port 53 från nodundernätet. Mer information finns i Verifiera anpassad DNS innan du aktiverar LocalDNS.

  2. Definiera poddstörningsbudgetar för varje kritisk arbetsbelastning.

  3. Ange en konservativ avbrottsbudget för de berörda NodePool resurserna innan du ändrar AKSNodeClass, som du ser i följande exempel:

    apiVersion: karpenter.sh/v1
    kind: NodePool
    metadata:
      name: default
    spec:
      disruption:
        budgets:
        - nodes: "1"   # Replace one node at a time
    
  4. Tillämpa ändringen på en icke-produktionsmiljö localDNSAKSNodeClass först. Du kan också skapa en AKSNodeClass som har LocalDNS aktiverat och migrera arbetsbelastningar till en NodePool som refererar till den.

  5. Övervaka ersättningsstatusen genom att lista nodanspråken. Ersättningen är klar när inget NodeClaim rapporterar statusvillkoret med namnet 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>
    
  6. Bekräfta att LocalDNS är aktivt på ersättningsnoderna. Mer information finns i Verifiera att LocalDNS fungerar.

Kubelet-konfiguration

I kubelet avsnittet kan du konfigurera olika kubelet-parametrar som påverkar nodbeteendet. Dessa parametrar är typiska kubelet-argument, så Azure-providern skickar dem helt enkelt till kubeleten på noden.

Viktigt!

Konfigurera kubelet-inställningar noggrant och testa eventuella ändringar i icke-produktionsmiljöer först.

CPU-hantering

Följande inställningar styr cpu-hanteringsbeteendet för kubelet:

spec:
  kubelet:
    cpuManagerPolicy: "static"  # or "none"
    cpuCFSQuota: true
    cpuCFSQuotaPeriod: "100ms"
  • cpuManagerPolicy: Styr hur kubelet allokerar CPU-resurser. Ange till "static" för CPU-pinning i svarstidskänsliga arbetsbelastningar.
  • cpuCFSQuota: Aktiverar kvottillämpning av CPU Completely Fair Scheduler (CFS) för containrar som anger CPU-gränser.
  • cpuCFSQuotaPeriod: Ställer in CPU CFS kvotperioden.

Avbildningsavfallsinsamling

Följande inställningar styr beteendet för skräpinsamling av avbildningar för kubelet:

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

De här inställningarna styr när kubelet utför skräpinsamling av containeravbildningar:

  • imageGCHighThresholdPercent: Diskanvändningsprocent som utlöser skräpinsamling av avbildningar.
  • imageGCLowThresholdPercent: Måldiskanvändning i procent efter skräpinsamling.

Topologihantering

Följande inställning styr topologihanterarens princip för kubelet:

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

Topologihanteraren hjälper till att samordna resursallokering för svarstidskänsliga arbetsbelastningar mellan processor- och enhetsresurser (till exempel GPU).

Systemkonfiguration

Med följande inställningar kan du konfigurera extra systemparametrar för kubelet:

spec:
  kubelet:
    allowedUnsafeSysctls:
      - "kernel.msg*"
      - "net.ipv4.route.min_pmtu"
    containerLogMaxSize: "50Mi"
    containerLogMaxFiles: 5
    podPidsLimit: 4096
  • allowedUnsafeSysctls: Lista över tillåtna osäkra sysctls som poddar kan använda.
  • containerLogMaxSize: Maximal storlek på containerloggfiler före rotation.
  • containerLogMaxFiles: Maximalt antal containerloggfiler som ska behållas.
  • podPidsLimit: Maximalt antal processer som tillåts i alla poddar.

Konfigurationsinställningar för anpassade Linux-operativsystem

I LinuxOSConfig avsnittet kan du konfigurera olika kubelet-parametrar som påverkar nodbeteendet. Dessa parametrar är typiska anpassade OS-argument, så NAP skickar dem helt enkelt till kubeleten på noden.

Mer information om anpassade konfigurationsinställningar för Linux-operativsystem, standardvärden och överväganden finns i referensen för anpassade nodkonfigurationsparametrar.

Viktigt!

Konfigurera inställningarna för Linux-operativsystemet noggrant och testa eventuella ändringar i icke-produktionsmiljöer först.

Inställningar för gränser för Linux-filhandtag

Använd följande inställningar för att ange inställningarna för filsystemet.

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

Inställningar för Linux-socket och nätverksjustering

Använd följande inställningar för att ange TCP- och nätverksinställningen.

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 

Inställningar för Gränsen för Linux-arbetare

Använd följande inställningar för att ange kernelinställningen.

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

Inställningar för virtuellt Linux-minne

Använd följande alternativ för att justera driften av linux-undersystemet för virtuellt minne i Linux-kerneln och skrivning av smutsiga data till disk.

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

GPU-inställningar

Använd följande fält för att aktivera anpassad GPU-drivrutinsinstallation, till exempel med NVIDIA GPU-operatorn.

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

Säkerhetsinställningar

Kryptering på värd

Följande fält anger om kryptering på värdnivå är aktiverat för etablerade noder. När du anger det här fältet till true, tas bara instanstyper som stöder kryptering på värdnivå med i NAP.

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

Mer information om värdbaserad kryptering finns i Dokumentation om kryptering på värd.

Kundhanterade nycklar och diskkrypteringsuppsättningar

NAP stöder kluster som använder kundhanterade nycklar och diskkrypteringsuppsättningar. Aktivera dessa alternativ på klusternivå. De har AKSNodeClass inte fält som du behöver ange. Se till att klusteridentiteten har rätt rollbaserad åtkomstkontroll (RBAC):

  • Klusteridentiteten har Reader åtkomst till diskkrypteringsuppsättningen.
  • Diskkrypteringsuppsättningsresursen har Key Vault Crypto Service Encryption User åtkomst till Azure Key Vault.

Mer information om kundhanterade nycklar och diskkrypteringsuppsättningar som aktiveras när klustret skapas finns i dokumentationen om kundhanterade nycklar.

Aktivera Trusted launch i NAP-kluster

Kluster med NAP (Node Auto Provisioning) aktiverat kan aktivera betrodd start med hjälp av fältet spec.security.trustedLaunch i AKSNodeClass CRD. Ange true i fälten secureBoot och vTPM för att aktivera betrodd start för alla nya eller befintliga NAP-hanterade noder som är associerade med denna AKSNodeClass CRD.

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

Azure konfiguration av resurstaggar

Du kan ange Azure resurstaggar som gäller för alla VM-instanser som skapats med hjälp av en viss AKSNodeClass resurs. Taggar är användbara för kostnadsspårning, resursorganisation och efterlevnadskrav.

Taggbegränsningar

  • Azure resurstaggar har en gräns på 50 taggar per resurs.
  • Taggnamn är inte skiftlägeskänsliga, men taggvärden är skiftlägeskänsliga.
  • Azure reserverar vissa taggnamn som inte kan användas. Mer information finns i Taggvägledning och begränsningar.

Konfiguration av exempeltaggar

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

Omfattande AKSNodeClass konfigurationsexempel

I följande exempel visas en omfattande AKSNodeClass konfiguration som innehåller alla inställningar som beskrivs i den här artikeln:

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

Nästa steg

Mer information om automatisk nodetablering i AKS finns i följande artiklar: