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

この記事では、SKU セレクター、リソース制限、優先度の重み付けなど、Azure Kubernetes Service (AKS)でノード自動プロビジョニング (NAP) 用にノードプールを構成する方法について説明します。また、作業の開始に役立つ例も示します。

AKS Automatic には、既定で NAP が含まれています。 AKS Standard クラスターの場合は、ノードプールを構成する前に NAP を有効にする必要があります。

NAP がノードプールの VM を選択する方法

NAP では、仮想マシン (VM) SKU の要件を使用して、保留中のワークロードに最適な VM を決定します。利用できる構成は、次のとおりです。

SKU ファミリと特定のインスタンスの種類。
リソースの制限と優先順位。
スポットインスタンスまたはオンデマンドインスタンス。
アーキテクチャ、GPU、およびその他の機能の要件。

NodePool リソースは、NAP によって作成されるノードと、それらのノードで実行されるポッドに制約を設定します。既定のノードプール構成を Auto に設定して NAP を有効にすると、既定の NodePool リソースが作成されます。これらのノードプールを変更したり、ワークロードの要件に合わせて追加のノードプールを作成したりできます。

NAP がノードプールを評価して選択する方法

NAP の NodePools を構成する場合は、次の動作に注意してください。

NAP を機能させるには、少なくとも 1 つの NodePool が必要です。
NAP は、構成された各 NodePoolを評価します。
NAP は、ポッドで許容されないテイントを含む NodePools をスキップします。
NAP は、プロビジョニングされたノードにスタートアップテイントを適用しますが、ポッドの容認は必要ありません。
NAP は、相互に排他的な NodePools を使用する場合に最も効果を発揮します。つまり、それぞれの要件が重複しないため、各ポッドは 1 つのプールにのみ一致します。複数の NodePools が一致する場合、NAP は最も高い重みを持つものを使用します。

既定のノードプール構成を確認する

NAP によって作成された名前がNodePoolの既定のの構成は次のとおりです。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      nodeClassRef:
        group: karpenter.azure.com
        kind: AKSNodeClass
        name: default
      expireAfter: Never
      # Requirements that constrain the parameters of provisioned nodes.
      # These requirements are combined with pod.spec.affinity.nodeAffinity rules.
      # Operators { In, NotIn, Exists, DoesNotExist, Gt, and Lt } are supported.
      # https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#operators
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values:
        - amd64
      - key: kubernetes.io/os
        operator: In
        values:
        - linux
      - key: karpenter.sh/capacity-type
        operator: In
        values:
        - on-demand
      - key: karpenter.azure.com/sku-family
        operator: In
        values:
        - D

NAP では、重要なシステムアドオンにオンデマンドの Linux AMD64 容量を提供する system-surge ノードプールも作成されます。保留状態の Pod が CriticalAddonsOnly=true:NoSchedule taint を許容し、プールの要件に一致する場合、NAP はこのプールからノードをプロビジョニングできます。プールによって作成されたノードには、 kubernetes.azure.com/mode: system ラベルがあります。

既定のノードプールを制御する

Azure CLIを使用して NAP が有効になっている新しい AKS クラスターを作成する場合は、--node-provisioning-default-pools フラグを含めて、AKS が既定の NAP NodePoolsを作成するかどうかを制御します。既存のクラスターで NAP を有効にする場合は、このフラグを az aks update と共に使用することもできます。

--node-provisioning-default-pools フラグは、次の値を受け入れます。

Auto (既定値): すぐに使用するために 2 つの標準 NodePools を作成します。
None: NodePoolsを作成しません。独自のものを定義する必要があります。

Warnung

AutoからNoneへの変更: 既存のクラスターで設定を Auto から None に変更した場合、既定のNodePoolsは自動的に削除されません。削除する前に、重要なシステムアドオンに適した交換容量を定義します。既定の NodePools は、不要になった場合は手動で削除する必要があります。

ノードプールの構成オプション

次のセクションでは、既知のNodePools、ノードプールの制限、ノードプールの重みなど、NAP でのさまざまな構成オプションについて説明します。

既知のラベルと SKU セレクター

Kubernetes では、Azure による実装のために既知のラベルを定義します。これらのラベルは、spec.requirements API の NodePool セクションで定義できます。 NAP では、より高度なスケジュール設定のためにAzure固有のラベルもサポートされています。

次の表に、spec.requirements API の NodePool セクションでノードの VM 特性を定義するために使用できるラベルを示します。

Selector	Description	Example
`karpenter.sh/capacity-type`	VM の割り当ての種類 (スポット/オンデマンド)	スポット
`karpenter.azure.com/sku-family`	VM SKU ファミリ	D、F、L など
`karpenter.azure.com/sku-series`	VM SKU シリーズ	Dpls_v6
`karpenter.azure.com/sku-name`	明示的な SKU 名	Standard_A1_v2
`karpenter.azure.com/sku-version`	SKU バージョン ("v" を使用しない場合は 1 を使用できます)	1、2
`karpenter.azure.com/sku-cpu`	VM 内の CPU の数	16
`karpenter.azure.com/sku-memory`	MiB の VM 内のメモリ	131072
`karpenter.azure.com/sku-gpu-name`	GPU 名	A100
`karpenter.azure.com/sku-gpu-manufacturer`	GPU の製造元	nvidia
`karpenter.azure.com/sku-gpu-count`	VM あたりの GPU 数	2
`karpenter.azure.com/sku-networking-accelerated`	VM が高速ネットワークを使用しているかどうか	[真, 偽]
`karpenter.azure.com/sku-storage-premium-capable`	VM が Premium IO ストレージをサポートしているかどうか	[真, 偽]
`karpenter.azure.com/sku-storage-ephemeralos-maxsize`	一時オペレーティングシステム (OS) ディスクのサイズ制限 (GB)	92
`kubernetes.azure.com/sku-cpu`	VM 内の CPU の数	16
`kubernetes.azure.com/sku-memory`	MiB の VM 内のメモリ	131072
`kubernetes.azure.com/cluster`	AKS クラスター名	my-cluster
`kubernetes.azure.com/mode`	ノードプールモード	[システム、ユーザー]
`kubernetes.azure.com/priority`	優先度	[スポット、通常]
`kubernetes.azure.com/os-sku`	オペレーティングシステム SKU	[Ubuntu, AzureLinux]
`kubernetes.azure.com/fips_enabled`	FIPS が有効かどうか	真実
`topology.kubernetes.io/zone`	可用性ゾーン	[uksouth-1,uksouth-2,uksouth-3]
`kubernetes.io/os`	オペレーティングシステム	linux
`kubernetes.io/arch`	CPU アーキテクチャ (AMD64 または ARM64)	[amd64, arm64]

この表のメモリセレクター値は、NAP で作成されたノードで報告される MiB 値です。セレクターを追加する前に、ノードのラベルを調べて、クラスターで使用される値を確認します。

SKU ファミリの例

karpenter.azure.com/sku-family セレクターを使用すると、特定の VM ファミリをターゲットにできます。

ファミリ	Description
D シリーズ	CPU とメモリのバランスの取れた汎用 VM
F シリーズ	CPU とメモリの比率が高いコンピューティング最適化 VM
E シリーズ	メモリ集中型アプリケーション用のメモリ最適化 VM
L シリーズ	高いディスクスループットを持つストレージ最適化 VM
N シリーズ	コンピューティング集中型ワークロード用の GPU 対応 VM

SKU ファミリを使用した構成例:

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - D
  - F

GPU SKU の例

NAP を使用して NVIDIA GPU ノードをプロビジョニングするには、GPU 対応の VM サイズを選択する NodePool を作成します。次の例では、NAP で N シリーズ NVIDIA GPU SKU を選択できます。

requirements:
- key: karpenter.azure.com/sku-family
  operator: In
  values:
  - N
- key: karpenter.azure.com/sku-gpu-manufacturer
  operator: In
  values:
  - nvidia

AKS で NVIDIA GPU ドライバー、デバイスプラグイン、Data Center GPU Manager (DCGM) メトリックエクスポーター、および GPU 正常性シグナルを NAP プロビジョニング GPU ノードにインストールして管理する場合は、参照先の AKSNodeClassでマネージド GPU を構成します。詳細については、「 AKS マネージド GPU ノードプールの作成」を参照してください。

SKU 名の例

karpenter.azure.com/sku-name セレクターを使用すると、正確な VM インスタンスの種類を指定できます。

requirements:
- key: karpenter.azure.com/sku-name
  operator: In
  values:
  - Standard_D4s_v3
  - Standard_F8s_v2

SKU バージョンの例

karpenter.azure.com/sku-version セレクターは、特定の世代の VM SKU を対象とします。

requirements:
- key: karpenter.azure.com/sku-version
  operator: In
  values:
  - "3"  # v3 generation
  - "5"  # v5 generation

可用性ゾーンの例

topology.kubernetes.io/zone セレクターを使用すると、ノードの可用性ゾーンを指定できます。

requirements:
- key: topology.kubernetes.io/zone
  operator: In
  values:
  - eastus-1
  - eastus-2

注

リージョン内の可用性ゾーンをサポートする VM サイズを一覧表示するには、--location <region> --zone --output table パラメーターで az vm list-skus コマンドを使用します。選択した VM サイズが、 NodePool 要件のゾーンをサポートしていることを確認します。

アーキテクチャの例

kubernetes.io/arch セレクターを使用すると、ノードの CPU アーキテクチャを指定できます。 NAP では、 amd64 ノードと arm64 ノードの両方がサポートされます。

requirements:
- key: kubernetes.io/arch
  operator: In
  values:
  - amd64
  - arm64

OS の例

kubernetes.io/os セレクターを使用すると、ノードのオペレーティングシステムを指定できます。

requirements:
- key: kubernetes.io/os
  operator: In
  values:
  - linux

容量の種類の例

karpenter.sh/capacity-type セレクターを使用すると、スポットインスタンスとオンデマンドインスタンスのどちらを使用するかを指定できます。

注

スポットとオンデマンドの両方が指定されている場合、NAP はスポットインスタンスに優先順位を付けます。

requirements:
- key: karpenter.sh/capacity-type
  operator: In
  values:
  - spot
  - on-demand

ノードプールの制限

既定では、NAP は使用可能なAzure クォータ内でワークロードのスケジュールを設定しようとします。動的ノードプールの場合は、そのプールによってプロビジョニングされたすべてのノードの集計リソース制限を指定できます。次の例では、 cpu: "1000" はプールを 1,000 vCPU コアに制限し、 memory: 1000Gi では 1,000 ギビバイトのメモリに制限しています。

spec:
  # Resource limits constrain the total size of the node pool.
  # Limits prevent Node Auto Provisioning from creating new instances once the limit is exceeded.
  limits:
    cpu: "1000"
    memory: 1000Gi

ノードプールの重み

複数のノードプールが定義されている場合は、ノードプール定義で相対的な重みを定義することで、ワークロードをスケジュールする場所を設定できます。 weight フィールドは 1 から 100 までの整数を受け取り、値を大きくするとノードプールの優先度が高くなります。 weightを省略すると、その値は実質的に 0 になります。例えば次が挙げられます。

spec:
  # Priority given to the node pool when the scheduler considers which to select. 
  # Higher weights indicate higher priority when comparing node pools.
  # Specifying no weight is equivalent to specifying a weight of 0.
  weight: 10

静的ノードプール

静的ノードプールは、ポッドの需要に関係なく、 replicas フィールドで指定された固定数の NAP プロビジョニングノードを保持します。ノード数を変更するには、nodepool static-node-pool --replicas=7でkubectl scaleを使用するなどして、NodePoolを明示的にスケーリングします。オプションの limits.nodes 値は、ノードの交換中に作成される明示的なスケーリングと一時的な容量を制限します。静的ノードプールの場合、limitsでサポートされているフィールドは nodes のみです。CPU またはメモリの制限を設定することはできません。

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: static-node-pool
spec:
  replicas: 5
  template:
    spec:
      requirements:
      - key: karpenter.azure.com/sku-name
        operator: In
        values:
          - Standard_D4s_v3
          - Standard_F8s_v2
      - key: topology.kubernetes.io/zone
        operator: In
        values:
          - eastus-1
          - eastus-2
          - eastus-3
  limits:
    nodes: 10

注

静的ノードプールの場合は、limits フィールドにnodesのみを設定できます。リソースの制限や weightを設定することはできません。中断の統合は適用されません。 NodePoolを作成した後は、replicas フィールドを追加または削除して、静的モードと動的モードを切り替えることはできません。

次のステップ

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

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-09-18

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

NAP がノード プールの VM を選択する方法

NAP がノード プールを評価して選択する方法

既定のノード プール構成を確認する

既定のノード プールを制御する

ノード プールの構成オプション