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

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

NAP でのノード プールの概要

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

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

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

NAP での NodePools の主な動作

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

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

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

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

apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
  template:
    spec:
      nodeClassRef:
        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

また、 system-surge ノード プールも作成され、システム プール ノードの自動スケーリングに役立ちます。

クラスターの作成時に既定のノード プールの構成を制御する

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

--node-provisioning-default-pools フラグは、既定の NAP NodePool構成を制御し、次の値を受け入れます。

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

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

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

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

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

karpenter.azure.com SKU セレクター

次の表に、karpenter.azure.com API の spec.requirements セクションでノードの VM 特性を定義するために使用できるNodePool SKU セレクターの一覧を示します。

kubernetes.io 既知のラベル

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

SKU ファミリの例

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

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

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

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

アーキテクチャの例

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 セレクターを使用すると、スポット インスタンスとオンデマンド インスタンスのどちらを使用するかを指定できます。

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

ノード プールの制限

既定では、NAP は使用可能なAzure クォータ内でワークロードのスケジュールを設定しようとします。 ノード プール スペック内の制限を指定することで、ノード プールが使用するリソースの上限を指定することもできます。例えば：

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

ノード プールの重み

複数のノード プールが定義されている場合は、ノード プール定義で相対的な重みを定義することで、ワークロードをスケジュールする場所を設定できます。 例えば次が挙げられます。

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 フィールドを使用して固定数のノードを作成できます。 静的ノード プールでは、保留中のポッドの負荷に関係なく、ノードの数は常に少なくとも replicas フィールドの値になります。 nodes フィールドにlimitsを設定することで、このノード プールがスケールアップできるノードの最大数を設定することもできます。

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  # Maximum number of nodes this node pool can scale up to

次のステップ

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

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