Azure Kubernetes Service (AKS) でノード自動プロビジョニング (NAP) 用に AKSNodeClass リソースを構成する

この記事では、AKSNodeClass リソースを構成して、Karpenter を使用してAzure Kubernetes Service (AKS)でノード自動プロビジョニング (NAP) のAzure固有の設定を定義する方法について説明します。 AKSNodeClass を使用すると、仮想マシン (VM) イメージ、オペレーティング システム (OS) ディスク サイズ、ノードあたりの最大ポッド数、kubelet 構成など、Karpenter がプロビジョニングするノードのさまざまな側面をカスタマイズできます。

AKSNodeClass リソースの概要

AKSNodeClass リソースを使用すると、NAP のAzure固有の設定を構成できます。 各NodePool リソースは、AKSNodeClassを使用してspec.template.spec.nodeClassRefを参照する必要があります。 同じNodePoolsを指す複数のAKSNodeClassを使用して、異なるノード プール間で共通のAzure構成を共有できます。

イメージ ファミリの構成

imageFamily フィールドは、AKSNodeClassを介してプロビジョニングされたノードの既定の VM イメージとブートストラップ ロジックを設定します。 イメージ ファミリを指定しない場合は、Kubernetes のバージョンに従った既定の OS バージョンが使用されます。 GPU は、互換性のある VM サイズの両方のイメージ ファミリでサポートされています。 Kubernetes バージョンごとの既定の OS バージョンの詳細については、 AKS OS バージョンのドキュメントを参照してください。

サポートされているイメージ グループ

• Ubuntu: Ubuntu は、AKS ノードの既定の Linux ディストリビューションです。
  • OS バージョンの既定値は、Kubernetes のバージョンに基づいて変更されます。 Ubuntu 22.04 は、Kubernetes バージョン 1.25 から 1.33 の既定です。 Ubuntu 24.04 は、Kubernetes バージョン 1.34 以降の既定です。
• AzureLinux: Azure Linux は、Microsoft の AKS ワークロード用の代替 Linux ディストリビューションです。 詳細については、Azure Linux のドキュメント

イメージ ファミリ構成の例

次の例では、AKSNodeClass イメージ ファミリを使用するようにAzureLinuxを構成します。

spec:
  imageFamily: AzureLinux

FIPS 準拠ノード イメージの構成

Federal Information Processing Standards (FIPS) 準拠のノード イメージを有効にすることもできます。 AKS の FIPS の詳細については、 FIPS のドキュメントを参照してください。

fipsMode フィールドは既定で [無効] に設定され、次のオプションに設定できます。

• FIPS - FIPS 準拠ノード イメージの選択
• 無効 - FIPS 準拠のノード イメージを使用しない

次の例では、 fipsMode を FIPS に設定して、FIPS 準拠のノード イメージを選択するように 'AKSNodeClass' を構成します。

spec:
  fipsMode: FIPS

仮想ネットワーク (VNet) サブネットの構成

vnetSubnetID フィールドは、ノード ネットワーク インターフェイスのプロビジョニングに使用する VNet サブネットAzure指定します。 このフィールドは省略可能です。 サブネットを指定しない場合、NAP は Karpenter のインストール時に構成された既定のサブネットを使用します。 詳細については、「 NAP のサブネット構成」を参照してください。

サブネット構成の例

次の例に示すように、サブネット ID は完全な Azure Resource Manager (ARM) 形式である必要があります。

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

OS ディスク サイズの構成

osDiskSizeGB フィールドは、OS ディスクのサイズをギガバイト単位で指定します。 既定値は 128 GB、最小値は 30 GB です。

次のようなワークロードでは、より大きな OS ディスク サイズを検討してください。

• 重要なデータをローカルに格納します。
• コンテナー イメージに余分な領域が必要です。
• ディスク I/O 要件が高い。

OS ディスク サイズ構成の例

spec:
  osDiskSizeGB: 256  # 256 GB OS disk

エフェメラル OS ディスクの構成

NAP では、使用可能で、要求されたディスク サイズに適した エフェメラル OS ディスク が自動的に使用されます。 エフェメラル OS ディスクは、マネージド ディスクと比較してパフォーマンスが向上し、コストが低くなります。

エフェメラル ディスクの選択基準

次のシナリオでは、エフェメラル ディスクが自動的に選択されます。

• VM インスタンスの種類では、エフェメラル OS ディスクがサポートされます。
• エフェメラルディスク容量は、要求されたosDiskSizeGB値以上である。
• VM には十分なエフェメラル ストレージ容量があります。

これらの条件が満たされていない場合、システムはマネージド ディスクの使用にフォールバックします。

エフェメラル ディスクの種類と優先順位付け

Azure VM は、さまざまな種類のエフェメラル ストレージを持つことができます。 システムでは、次の優先順位が使用されます。

• NVMe ディスク (最高のパフォーマンス)
• キャッシュ ディスク (バランスの取れたパフォーマンス)
• リソース ディスク (基本パフォーマンス)

一時的ディスク構成の例

次の例に示すように、ノード プールの要件を使用して、ノードに十分なエフェメラル ディスク容量があることを確認できます。

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

この構成により、128 GB を超えるエフェメラル ディスクを持つ VM インスタンスの種類のみが選択され、指定された OS ディスク サイズに対するエフェメラル ディスクの使用が保証されます。

ポッドの最大構成

maxPods フィールドは、ノードでスケジュールできるポッドの最大数を指定します。 この設定は、クラスター密度とネットワーク構成の両方に影響します。

maxPodsの最小値は 10 で、最大値は 250 です。

の既定の動作 maxPods

maxPodsの既定の動作は、ネットワーク プラグインの構成によって異なります。 次の表は、既定値をまとめたものです。

ポッドの最大構成の例

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

LocalDNS の構成

LocalDNS は、ワークロードに近い場所で DNS クエリを解決し、クエリの待機時間を短縮し、一時的な DNS 中断時の回復性を向上させるノード レベルの DNS プロキシをデプロイします。 詳細については、 LocalDNS のドキュメントを参照してください。 既定では、LocalDNS は無効に設定され、次のオプションに構成できます。

• Disabled (既定値) - LocalDNS 機能を無効にします。 DNS クエリは、ノード上でローカルに解決されません。
• Preferred - AKS は、ノード プールの Kubernetes バージョンに基づいて LocalDNS 有効化を管理します。 構成は常に検証され包含されていますが、正しい Kubernetes バージョンが使用されていない限り、LocalDNS は有効になりません。
• Required - すべての前提条件が満たされている場合、ノード プールに LocalDNS が適用されます。 要件が満たされていない場合、デプロイは失敗します。

LocalDNS 構成の例

vnetDNSOverridesやkubeDNSOverridesなどの LocalDNS 構成をカスタマイズできます。 サポートされているプラグインの詳細については、「 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"

Kubelet の構成

kubeletセクションでは、ノードの動作に影響を与えるさまざまな kubelet パラメーターを構成できます。 これらのパラメーターは一般的な kubelet 引数であるため、Azure プロバイダーはノード上の kubelet に渡すだけです。

CPU 管理

次の設定は、kubelet の CPU 管理動作を制御します。

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

• cpuManagerPolicy: kubelet が CPU リソースを割り当てる方法を制御します。 待機時間の影響を受けやすいワークロードでの CPU ピン留めを "static" に設定します。
• cpuCFSQuota: CPU の制限を指定するコンテナーに対して CPU Completely Fair Scheduler (CFS) クォータの適用を有効にします。
• cpuCFSQuotaPeriod: CPU CFS クォータ期間を設定します。

イメージ ガベージ コレクション

次の設定は、kubelet のイメージ ガベージ コレクションの動作を制御します。

spec:
  kubelet:
    imageGCHighThresholdPercent: 85
    imageGCLowThresholdPercent: 80

これらの設定は、kubelet がコンテナー イメージのガベージ コレクションを実行するタイミングを制御します。

• imageGCHighThresholdPercent: イメージ ガベージ コレクションをトリガーするディスク使用率。
• imageGCLowThresholdPercent: ガベージ コレクション後のターゲット ディスク使用率。

トポロジ管理

次の設定は、kubelet のトポロジ マネージャー ポリシーを制御します。

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

トポロジ マネージャーは、CPU とデバイス (GPU など) リソース全体の待機時間に依存するワークロードのリソース割り当てを調整するのに役立ちます。

システム構成

次の設定を使用すると、kubelet の追加のシステム パラメーターを構成できます。

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

• allowedUnsafeSysctls: ポッドが使用できる許可された不安全な sysctl の一覧。
• containerLogMaxSize: ローテーション前のコンテナー ログ ファイルの最大サイズ。
• containerLogMaxFiles: 保持するコンテナー ログ ファイルの最大数。
• podPidsLimit: 任意のポッドで許可されるプロセスの最大数。

Linux カスタム OS 構成設定

LinuxOSConfigセクションでは、ノードの動作に影響を与えるさまざまな kubelet パラメーターを構成できます。 これらのパラメーターは一般的なカスタム OS 引数であるため、NAP は単にノード上の kubelet に渡します。

カスタム Linux OS 構成設定の詳細、既定値の詳細、および考慮事項については、 カスタム ノード構成のドキュメントを参照してください。

Linux のファイルハンドルの上限設定

次の設定を使用して、ファイル システムの設定を設定します。

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

Linux ソケットとネットワーク チューニングの設定

TCP とネットワークの設定を設定するには、次の設定を使用します。

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 

Linux worker の制限設定

カーネル設定を設定するには、次の設定を使用します。

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

Linux 仮想メモリの設定

Linux カーネルの Linux 仮想メモリ サブシステムの操作と、ダーティ データのディスクへの書き出しを調整するには、次のオプションを使用します。

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 設定

次のフィールドを使用すると、ユーザーは NVIDIA GPU オペレーターなどのカスタム GPU ドライバーのインストールを許可できます。

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

Azure リソース タグの構成

特定AzureAKSNodeClass リソースを使用して作成されたすべての VM インスタンスに適用されるリソース タグを指定できます。 タグは、コストの追跡、リソースの編成、コンプライアンスの要件に役立ちます。

タグの制限事項

• Azureリソース タグには、リソースあたり 50 個のタグの制限があります。
• タグ名では大文字と小文字は区別されませんが、タグ値では大文字と小文字が区別されます。
• Azureは、使用できないタグ名をいくつか予約します。 詳細については、「 タグのガイダンスと制限」を参照してください。

タグ構成の例

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

包括的な AKSNodeClass 構成の例

次の例では、この記事で説明されているすべての設定を含む包括的な AKSNodeClass 構成を示します。

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

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

  # LocalDNS mode - allows use of LocalDNS feature
  # Default: Disabled
  # Valid values: Preferred, Required, Disabled
  LocalDNS:
    mode: Disabled
    # additional details on vnetDNSOverrides and kubeDNSOverrides can be added here

  # 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

次のステップ

AKS でのノード自動プロビジョニングの詳細については、次の記事を参照してください。

• カスタム仮想ネットワークでノードの自動プロビジョニングを使用する
• AKS でのノード自動プロビジョニング用にノード プールを構成する
• AKS でのノード自動プロビジョニングの中断ポリシーの構成