ノードの自動プロビジョニングを使用する

このページでは、Google Kubernetes Engine（GKE）Standard クラスタでノード自動プロビジョニングを使用する方法を説明します。このページを読む前に、ノードの自動プロビジョニングについて理解しておいてください。

始める前に

始める前に、次の作業が完了していることを確認してください。

  • Google Kubernetes Engine API を有効にする。
    • Google Kubernetes Engine API の有効化
  • このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。

要件

ノード自動プロビジョニングは次の GKE リリースで利用できます。

  • バージョン 1.11.2-gke.25 以降（ゾーンクラスタ）。
  • バージョン 1.12.x 以降（リージョン クラスタ）。
  • バージョン 1.27.6 以降または 1.28 以降（Cloud TPU v4 と v5e の場合）。
  • バージョン 1.28.7-gke.1020000 以降と 1.29.2-gke.1035000 以降（Cloud TPU v5p の場合）。

ノードの自動プロビジョニングを有効にする

クラスタの自動プロビジョニングは、gcloud CLI または Google Cloud コンソールを使用して有効にできます。

ノードの自動プロビジョニングには次のリソース制限があります。

ノードの IP アドレス範囲は慎重に計画する必要があります。クラスタの作成後に、ノードの IP アドレス範囲を拡張できます。ただし、新しい範囲を送信元として含めるようにファイアウォール ルールを更新する必要があるため、クラスタの作成後にノードの IP アドレス範囲を拡張しないことをおすすめします。ノードの自動プロビジョニングで不連続マルチ Pod CIDR を使用すると、Pod の IP アドレス範囲を拡張できます。

gcloud

ノード自動プロビジョニング機能を有効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --min-cpu MINIMUM_CPU \
    --min-memory MIMIMUM_MEMORY \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only

次のように置き換えます。

  • CLUSTER_NAME: ノード自動プロビジョニングを有効にするクラスタの名前。
  • MINIMUM_CPU: クラスタの最小コア数。
  • MINIMUM_MEMORY: クラスタの最小メモリ量（GB）。
  • MAXIMUM_CPU: クラスタの最大コア数。
  • MAXIMUM_MEMORY: クラスタの最大メモリ量（GB）。

次の例では、dev-cluster でノードの自動プロビジョニングを有効にし、1 個の CPU と 1 GB のメモリから構成されるクラスタから、最大 10 個の CPU と 64 GB のメモリから構成されるクラスタまでのスケーリングを可能にしています。

gcloud container clusters update dev-cluster \
    --enable-autoprovisioning \
    --min-cpu 1 \
    --min-memory 1 \
    --max-cpu 10 \
    --max-memory 64

コンソール

ノードの自動プロビジョニングを有効にするには、次の操作を行います。

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタの名前をクリックします。

  3. [自動化] セクションの [ノードの自動プロビジョニング] で、[編集] をクリックします。

  4. [ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。

  5. クラスタの CPU とメモリの最小使用量と最大使用量を設定します。

  6. [変更を保存] をクリックします。

自動プロビジョニング構成ファイルを使用する

ノードの自動プロビジョニングは、YAML 構成ファイルを使用して構成できます。1 つの設定を変更するために使用する場合、構成ファイルの中身は 1 行で済みます。1 つの構成ファイルで複数の設定を指定できます。この場合、構成ファイルが適用されると、それら複数の設定がすべて変更されます。

一部の詳細設定は、構成ファイルを使用してのみ指定できます。

例 1: 次の構成ファイルを適用すると、ノード自動プロビジョニングによって作成された新しいノードプールのノードの自動修復と自動アップグレードが有効になります。

management:
  autoRepair: true
  autoUpgrade: true

例 2: 次の構成ファイルを適用すると、次の設定が変更されます。

  • CPU、メモリ、GPU のリソース上限を設定します。クラスタの合計サイズが指定のリソース上限を超えた場合、ノードの自動プロビジョニングによるノードの作成は行われません。
  • ノード自動プロビジョニングによって作成された新しいノードプールに対して、ノードの自動修復と自動アップグレードを有効にします。
  • ノード自動プロビジョニングによって作成された新しいノードプールに対して、セキュアブートと整合性モニタリングを有効にします。
  • ノード自動プロビジョニングによって作成された新しいノードプールのブートディスク サイズを 100 GB に設定します。
resourceLimits:
  - resourceType: 'cpu'
    minimum: 4
    maximum: 10
  - resourceType: 'memory'
    maximum: 64
  - resourceType: 'nvidia-tesla-t4'
    maximum: 4
management:
  autoRepair: true
  autoUpgrade: true
shieldedInstanceConfig:
  enableSecureBoot: true
  enableIntegrityMonitoring: true
diskSizeGb: 100

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud CLI からアクセスできる場所に、必要な構成のファイルを作成します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

    gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルの名前。

    詳細については、gcloud container clusters update のドキュメントをご覧ください。

自動プロビジョニングのデフォルト

ノード自動プロビジョニングは、クラスタ内の Pod の要件を確認して、その Pod に最適なノードの種類を決定します。ただし、一部のノードプール設定（たとえば、ノードのアップグレードに関連する設定など）は Pod によって直接指定されません。これらの設定のデフォルト値を設定できます。これは、新しく作成されたすべてのノードプールに適用されます。

デフォルトのノードイメージ タイプの設定

gcloud CLI または構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールに使用するノードイメージ タイプを指定できます。この設定は、GKE クラスタ バージョン 1.20.6-gke.1800 以降でのみ使用できます。

gcloud

デフォルトのノードイメージ タイプを設定するには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --autoprovisioning-image-type IMAGE_TYPE

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。

  • IMAGE_TYPE: ノードイメージ タイプ。次のいずれかになります。

    • cos_containerd: containerd を含む Container-Optimized OS
    • ubuntu_containerd: Containerd を含む Ubuntu

ファイル

新しく自動プロビジョニングされたすべてのノードプールについて、使用するノードイメージ タイプを構成ファイルで指定できます。次の YAML 構成では、新しく自動プロビジョニングされたノードプールに対して、イメージタイプが cos_containerd であり、CPU とメモリのリソース上限を関連付けていることを指定しています。自動プロビジョニングを有効にするには、CPU とメモリの最大値を指定する必要があります。

  1. YAML 構成を保存します。

    resourceLimits:
  - resourceType: 'cpu'
    minimum: 4
    maximum: 10
  - resourceType: 'memory'
    maximum: 64
imageType: 'cos_containerd'

  2. 構成を適用します。

    gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルの名前。

自動プロビジョニングされたノードプールの ID のデフォルトの設定

Google Cloud リソースの権限は ID によって提供されます。

gcloud CLI または構成ファイルを使用して、新しく自動プロビジョニングされたノードプールのデフォルト ID（サービス アカウントまたは 1 つ以上のスコープ）を指定できます。

gcloud

ノードの自動プロビジョニングで使用するデフォルトの IAM サービス アカウントを指定するには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning --autoprovisioning-service-account=SERVICE_ACCOUNT

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • SERVICE_ACCOUNT: デフォルトのサービス アカウントの名前。

次のサンプルセットでは、dev-cluster クラスタのデフォルトのサービス アカウントとして [email protected] を設定しています。

gcloud container clusters update dev-cluster \
    --enable-autoprovisioning --autoprovisioning-service-account=test-service-account@google.com

ノードの自動プロビジョニングで使用するデフォルトのスコープを指定するには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning --autoprovisioning-scopes=SCOPE

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • SCOPE: 自動プロビジョニングされたノードプールで使用される Google Cloud スコープ。複数のスコープを指定するには、各スコープをカンマで区切ります（例: SCOPE1, SCOPE2,...）。

次の例では、dev-cluster クラスタのデフォルト スコープを devstorage.read_only に設定しています。

gcloud container clusters update dev-cluster \
    --enable-autoprovisioning \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/pubsub,https://www.googleapis.com/auth/devstorage.read_only

ファイル

構成ファイルを使用して、ノード自動プロビジョニングで使用する ID のデフォルトを指定できます。次の YAML 構成は、IAM サービス アカウントを設定します。

  serviceAccount: SERVICE_ACCOUNT

SERVICE_ACCOUNT は、デフォルトのサービス アカウントの名前に置き換えます。

または、次の YAML 構成を使用して、ノード自動プロビジョニングで使用するデフォルトのスコープを指定することもできます。

  scopes: SCOPE

SCOPE は、自動プロビジョニングされたノードプールで使用される Google Cloud スコープに置き換えます。複数のスコープを指定するには、各スコープをカンマで区切ります（例: SCOPE1, SCOPE2,...）。

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud CLI がアクセスできる場所に、ID のデフォルトを指定する構成ファイルを作成します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

    gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • FILE_NAME: 構成ファイルの名前。

顧客管理の暗号鍵（CMEK）

新しく自動プロビジョニングされたノードプールで使用される顧客管理の暗号鍵（CMEK）を指定できます。

構成ファイルを使用して、ブートドライブの顧客管理の暗号化を有効にできます。次の YAML 構成では、CMEK の鍵を設定します。

  bootDiskKmsKey: projects/KEY_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME

次のように置き換えます。

  • KEY_PROJECT_ID: 鍵プロジェクト ID。
  • LOCATION: キーリングのロケーション。
  • KEY_RING: キーリングの名前。
  • KEY_NAME: 鍵の名前。

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud CLI からアクセスできる場所に CMEK 鍵を指定する構成ファイルを作成します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

    gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルの名前。

ノードの整合性

ノードの自動プロビジョニングでは、セキュアブートと完全性モニタリングを有効にしてノードプールを作成できます。

セキュアブートと整合性モニタリングは、構成ファイルを使用して有効にできます。次の YAML 構成では、セキュアブートが有効、整合性モニタリングが無効になります。

  shieldedInstanceConfig:
    enableSecureBoot: true
    enableIntegrityMonitoring: false

自動プロビジョニングの構成ファイルを使用するには:

  1. 上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。enableSecureBoot と enableIntegrityMonitoring の値を編集します。ファイルを保存します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

    gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルの名前。

ノードの自動修復と自動アップグレード

ノードの自動プロビジョニングでは、ノードの自動修復とノードの自動アップグレードを有効にしたノードプールの作成がサポートされます。

gcloud

自動プロビジョニングされたすべての新しいノードプールに対して自動修復と自動アップグレードを有効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning --enable-autoprovisioning-autorepair \
    --enable-autoprovisioning-autoupgrade

CLUSTER_NAME はクラスタの名前で置き換えます。

すべての自動プロビジョニングされたノードプールの自動修復と自動アップグレードを無効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning --no-enable-autoprovisioning-autorepair \
    --no-enable-autoprovisioning-autoupgrade

CLUSTER_NAME はクラスタの名前で置き換えます。

ファイル

ノードの自動修復と自動アップグレードは、構成ファイルを使用して有効または無効にできます。次の YAML 構成では、自動修復が有効で、自動アップグレードが無効です。

  management:
    autoRepair: true
    autoUpgrade: false

自動プロビジョニングの構成ファイルを使用するには:

  1. 上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。autoUpgrade と autoRepair の値を編集します。ファイルを保存します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-config-file FILE_NAME

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • FILE_NAME: 構成ファイルの名前。

自動プロビジョニングされた新しいノードプールにサージ アップグレードを使用する

gcloud CLI または構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールでサージ アップグレードの設定を指定できます。GKE のデフォルトでは、ノードのアップグレード戦略がサージ アップグレードに設定されます。

gcloud

自動プロビジョニングされた新しいすべてのノードプールに対してサージ アップグレードを指定するには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-max-surge-upgrade MAX_SURGE \
    --autoprovisioning-max-unavailable-upgrade MAX_UNAVAILABLE

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • MAX_SURGE: アップグレード中にノードプールに追加できるノードの最大数。
  • MAX_UNAVAILABLE: アップグレード中に同時に使用不可になることが許容される、ノードプール内のノードの最大数。

ファイル

次のように、構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールのサージ アップグレード設定を指定できます。

  upgradeSettings:
    maxSurgeUpgrade: 1
    maxUnavailableUpgrade: 2

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud からアクセス可能な場所にあるファイルに上記の構成をコピーします。maxSurgeUpgrade と maxUnavailableUpgrade の値を編集します。ファイルを保存します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-config-file FILE_NAME

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • FILE_NAME: 構成ファイルの名前。

詳細については、gcloud container clusters update のドキュメントをご覧ください。

新しく自動プロビジョニングされたノードプールでサージ アップグレードを使用するように戻すには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --enable-autoprovisioning-surge-upgrade

CLUSTER_NAME はクラスタの名前で置き換えます。

前のコマンドと同様に、特定の設定に対するフラグを指定することもできます。設定されている場合、GKE は以前の構成をアップグレード戦略に再利用します。

自動プロビジョニングされた新しいノードプールに Blue/Green アップグレードを使用する

gcloud CLI を使用すると、新しく自動プロビジョニングされたすべてのノードプールに Blue/Green アップグレードを使用できます。Blue/Green アップグレードでは、デフォルト設定を使用できます。または、環境に合わせて最適化されるように設定することもできます。Blue/Green アップグレードの詳細については、Blue/Green アップグレードをご覧ください。

既存の自動プロビジョニングされたノードプールのノード アップグレード戦略を更新するには、既存のノードプールのサージ アップグレードをオンまたはオフにすると既存のノードプールの Blue/Green アップグレード戦略の更新をご覧ください。

後述するコマンドでは、次の変数を使用しています。

  • CLUSTER_NAME: ノードプールのクラスタの名前。
  • COMPUTE_ZONE: クラスタのゾーン。
  • NODE_POOL_NAME: ノードプールの名前。
  • NUMBER_NODES: クラスタの各ゾーンにあるノードプール内のノード数。
  • BATCH_NODE_COUNT: Blue のプールドレイン フェーズでバッチにドレインする Blue ノードの数。デフォルトは 1 です。0 に設定した場合、Blue のプールドレイン フェーズはスキップされます。
  • BATCH_PERCENT: Blue のプールドレイン フェーズでバッチにドレインする Blue ノードの割合。[0.0, 1.0] の範囲内にしてください。
  • BATCH_SOAK_DURATION: 各バッチドレインの後に待機する時間（秒）。デフォルトは 0 です。
  • NODE_POOL_SOAK_DURATION: すべてのバッチのドレインが完了した後に待機する時間（秒）。デフォルトは 3,600 秒です。

Blue/Green アップグレードのデフォルトの設定は次のとおりです。

  • BATCH_NODE_COUNT = 1
  • BATCH_SOAK_DURATION = 0 秒
  • NODE_POOL_SOAK_DURATION = 3,600 秒（1 時間）

自動プロビジョニングされた新しいノードプールに Blue/Green アップグレードを使用するようにクラスタを更新する

次のコマンドは、gcloud container clusters update を使用して、新しく自動プロビジョニングされたノードプールに対してノードのアップグレード戦略を更新します。

これらのフラグは、次の場合にも使用できます。

自動プロビジョニングされた新しいノードプールのデフォルト設定で Blue/Green アップグレードを使用するようにクラスタを更新するには、次のコマンドを使用します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --enable-autoprovisioning-blue-green-upgrade

自動プロビジョニングされた新しいノードプールに特定の設定で Blue/Green アップグレードを使用するようにクラスタを更新できます。これらのコマンドは、--enable-autoprovisioning-blue-green-upgrade フラグなしで使用して設定を更新することもできます。

次のコマンドは、BATCH_NODE_COUNT を使用して絶対ノード数のバッチサイズを設定します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --enable-autoprovisioning-blue-green-upgrade \
  --autoprovisioning-node-pool-soak-duration=NODE_POOL_SOAK_DURATION \
  --autoprovisioning-standard-rollout-policy=batch-node-count=BATCH_NODE_COUNT,batch-soak-duration=BATCH_SOAK_DURATION

また、BATCH_PERCENT を使用して割合ベースのバッチサイズを設定することもできます。最後のコマンドの batch-node-count は batch-percent に置き換え、0～1 の小数を使用します（例: 25% は 0.25）。割合ベースのバッチサイズの設定方法については、割合ベースのバッチサイズを使用して Blue/Green アップグレードでノードプールを更新するをご覧ください。

カスタム ブートディスク

ノード自動プロビジョニングは、カスタム ブートディスクを使用したノードプールの作成をサポートします。

構成ファイルを使用してブートディスクの設定をカスタマイズできます。GKE は、kubelet 関数用にノード ブートディスクの一部を予約します。詳細については、ノード ブートディスクを基盤とするエフェメラル ストレージをご覧ください。

次の YAML 構成では、ノードの自動プロビジョニングによって 100 GB の SSD ディスクで構成されるノードプールが作成されます。

  diskSizeGb: 100
  diskType: pd-ssd

以下を指定します。

  • diskSizeGb: ディスクのサイズ（GB）。
  • diskType: ディスクのタイプ。次のいずれかの値になります。
    • pd-balanced（デフォルト）
    • pd-standard
    • pd-ssd。 GKE バージョン 1.22 以前では、pd-ssd を指定すると、ノードの自動プロビジョニングはノードプールの作成時に N1 マシンタイプのみを考慮します。

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud CLI がアクセスできる場所に、目的のブートディスク構成を持つファイルを作成します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

    gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルの名前。

GKE マネージド Pod をワークロードから分離する

クラスタ管理者は、GKE が管理する Pod をワークロードから分離できます。この分離により、システム Pod が実行されている使用率の低いノードがクラスタにある場合に、スケールダウンの問題を回避できます。

次の例は、ノードの自動プロビジョニングと Kubernetes の taint と Toleration を組み合わせて、マネージド Pod をワークロードから分離する方法を示しています。

  1. e2-standard-2 VM のデフォルト ノードプールを持つクラスタを作成し、それらのノードでのみ GKE システム ワークロードを実行できるようにノード taint を適用します。

    gcloud container clusters create test-cluster \
    --machine-type=e2-standard-2 \
    --node-taints=components.gke.io/gke-managed-components=true:NoSchedule

  2. クラスタのノードの自動プロビジョニングを有効にします。

    gcloud container clusters update test-cluster \
    --enable-autoprovisioning \
    --min-cpu 1 \
    --min-memory 1 \
    --max-cpu 10 \
    --max-memory 64

    クラスタは、クラスタの合計サイズを 1 CPU と 1 GB のメモリから、最大 10 CPU と 64 GB のメモリまでスケーリングできます。

  3. この構成をテストするには、次のサンプル マニフェストを nginx.yaml として保存します。

    apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: dedicated
    operator: Equal
    value: ui-team
    effect: NoSchedule
  nodeSelector:
    dedicated: ui-team

    このマニフェストは、nodeSelector ラベルと dedicated: ui-team のノード taint を設定したクラスタにテスト ワークロード Pod をデプロイします。ノードの自動プロビジョニング機能を使用しない場合、ノードプールに適切なラベルと taint がないため、このワークロード Pod をスケジュールできません。

  4. マニフェストをクラスタに適用します。

    kubectl apply -f nginx.yaml

    出力は次のようになります。

    pod/nginx created

  5. ui-team ラベルに適合する新しいノードプールを確認します。

    kubectl get node --selector=dedicated=ui-team

    出力は次のようになります。

    NAME                                            STATUS   ROLES    AGE   VERSION
gke-test-nap-e2-medium-14b723z1-19f89fa8-jmhr   Ready    <none>   14s   v1.21.11-gke.900

クラスタは、ワークロードをマネージド GKE Pod から分離します。

自動プロビジョニングされた新しいノードプールにアクセラレータを使用する

ノードの自動プロビジョニングを有効にして、GPU または Cloud TPU アクセラレータを自動的にプロビジョニングするように GKE を構成すると、AI / ML ワークロードのスケジューリングに必要な容量を確保できます。

GPU の上限の構成

ノードの自動プロビジョニングで GPU で使用する場合、gcloud CLI または Google Cloud コンソールを使用して、クラスタ内の各 GPU タイプに上限を設定できます。GPU の上限数は GPU の最大数です。たとえば、GPU が 16 個の VM は、この上限では 1 個ではなく 16 個としてカウントされます。複数のタイプの GPU を構成するには、構成ファイルを使用する必要があります。

使用可能な resourceTypes の一覧を取得するには、gcloud compute accelerator-types list を実行します。

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --max-cpu MAXIMUM_CPU \
    --max-memory MAXIMUM_MEMORY \
    --min-accelerator type=GPU_TYPE,count=MINIMUM_ACCELERATOR \
    --max-accelerator type=GPU_TYPE,count=MAXIMUM_ACCELERATOR

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • MAXIMUM_CPU: クラスタの最大コア数。
  • MAXIMUM_MEMORY: クラスタの最大メモリ量（GB）。
  • GPU_TYPE: GPU タイプ。
  • MINIMUM_ACCELERATOR: クラスタ内の GPU アクセラレータの最小数。
  • MAXIMUM_ACCELERATOR: クラスタ内の GPU アクセラレータの最大数。

次の例では、dev-cluster クラスタ内の nvidia-tesla-t4 GPU アクセラレータに GPU の上限を設定しています。

gcloud container clusters update dev-cluster \
    --enable-autoprovisioning \
    --max-cpu 10 \
    --max-memory 64 \
    --min-accelerator type=nvidia-tesla-t4,count=1 \
    --max-accelerator type=nvidia-tesla-t4,count=4

ファイル

構成ファイルを使用すると、複数のタイプの GPU の上限を読み込むことが可能です。 次の YAML 構成では、2 種類の GPU を設定しています。

  resourceLimits:
    - resourceType: 'cpu'
      minimum: 4
      maximum: 10
    - resourceType: 'memory'
      maximum: 64
    - resourceType: 'nvidia-tesla-t4'
      maximum: 4
    - resourceType: 'nvidia-tesla-v100'
      maximum: 2

自動プロビジョニングの構成ファイルを使用するには:

  1. 上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。cpu と memory の値を編集します。resourceType の値を必要な数だけ追加します。ファイルを保存します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-config-file FILE_NAME

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • FILE_NAME: 構成ファイルの名前。

詳細については、gcloud container clusters update のドキュメントをご覧ください。

コンソール

GPU リソースでノードの自動プロビジョニングを有効にするには、次の操作を行います。

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタの名前をクリックします。

  3. [自動化] セクションの [ノードの自動プロビジョニング] で、[編集] をクリックします。

  4. [ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。

  5. クラスタの CPU とメモリの最小使用量と最大使用量を設定します。

  6. [ リソースの追加] をクリックします。

  7. 追加する GPU のタイプ（NVIDIA T4 など）を選択します。クラスタに追加する GPU の最小数と最大数を設定します。

  8. GKE で GPU の制限事項に同意します。

  9. [変更を保存] をクリックします。

インストールするドライバのバージョンを選択する

GKE バージョン 1.29.2-gke.1108000 以降では、自動プロビジョニングされた GPU ノードに自動的にインストールする、GKE の GPU ドライバ バージョンを選択できます。マニフェストに次のフィールドを追加します。

spec:
  nodeSelector:
    cloud.google.com/gke-gpu-driver-version: "DRIVER_VERSION"

DRIVER_VERSION は次のいずれかの値に置き換えます。

  • default - ノードの GKE バージョンに対応するデフォルトの安定版ドライバ。マニフェストで nodeSelector を省略した場合、これがデフォルトのオプションになります。
  • latest - ノードの GKE バージョンに対応する最新のドライバ バージョン。

Cloud TPU の構成

TPU でのノード自動プロビジョニングの仕組みについて詳しくは、サポートされている ML アクセラレータをご覧ください。

gcloud CLI を使用してクラスタを作成し、Pod が TPU リソースを使用するように構成します。複数のタイプの TPU を構成するには、構成ファイルを使用する必要があります。

gcloud

  1. クラスタを作成して TPU の上限を定義します。

    gcloud container clusters create CLUSTER_NAME \
    --enable-autoprovisioning \
    [--min-cpu  MINIMUM_CPU ] \
    --max-cpu MAXIMUM_CPU \
    [--min-memory MINIMUM_MEMORY ] \
    --max-memory MAXIMUM_MEMORY \
    [--min-accelerator=type=TPU_TYPE,count= MINIMUM_ACCELERATOR ] \
    --max-accelerator=type=TPU_TYPE,count= MAXIMUM_ACCELERATOR

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • MINIMUM_CPU: クラスタの最小 vCPU 数。
    • MAXIMUM_CPU: クラスタの最大 vCPU 数。
    • MINIMUM_MEMORY: クラスタの最小メモリ量（GB）。
    • MAXIMUM_MEMORY: クラスタの最大メモリ量（GB）。
    • TPU_TYPE: 選択する TPU のタイプ。TPU v4 を選択する場合は、tpu-v4-podslice を使用します。マシンタイプが ct5lp- で始まる TPU v5e を選択する場合は、tpu-v5-lite-podslice を使用します。マシンタイプが ct5l- で始まる TPU v5e を選択する場合は、tpu-v5-lite-device を使用します。
    • MINIMUM_ACCELERATOR: クラスタ内の TPU チップの最小数。
      • MINIMUM_ACCELERATOR を使用すると、count がスライス内の TPU チップの数より少ない場合でも、マルチホスト TPU スライスのスケールダウンがブロックされる可能性があります。
    • MAXIMUM_ACCELERATOR: クラスタ内の TPU チップの最大数。
      • Pod 構成でマルチホスト TPU スライスがリクエストされた場合、GKE は対象のスライスをアトミックに作成します。指定したトポロジのすべての TPU チップをプロビジョニングできるよう十分に高いカウント値を設定します。各 TPU スライス内のチップの数は、トポロジの積に等しくなります。たとえば、マルチホスト TPU スライスのトポロジが 2x2x2 の場合、TPU チップの数は 8 に等しいため、MAXIMUM_ACCELERATOR は 8 より大きくする必要があります。

    次の例では、dev-cluster クラスタ内の ct5lp-hightpu-1t、ct5lp-hightpu-4t、ct5lp-hightpu-8t のマシンタイプに TPU の上限を設定しています。たとえば、それぞれ 4 個の TPU チップ、112 個の vCPU、192 GiB のメモリを搭載した ct5lp-hightpu-4t マシンを最大 10 個までプロビジョニングできます。

    gcloud container clusters create dev-cluster-inference \
      --enable-autoprovisioning \
      --min-cpu 0 \
      --max-cpu 1120 \
      --min-memory 0 \
      --max-memory 1920 \
      --min-accelerator=type=tpu-v5-lite-podslice,count=0 \
      --max-accelerator=type=tpu-v5-lite-podslice,count=40

  2. Pod が TPU リソースをリクエストする Deployment 仕様を作成します。たとえば、次のマニフェストでは、GKE が 4 つの ct5lp-hightpu-4t ノードをプロビジョニングします。

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: tpu-workload
  labels:
    app: tpu-workload
spec:
  replicas: 4
  selector:
    matchLabels:
      app: nginx-tpu
  template:
    metadata:
      labels:
        app: nginx-tpu
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice
        cloud.google.com/gke-tpu-topology:  2x2
        cloud.google.com/reservation-name: my-reservation
      containers:
      - name: nginx
        image: nginx:1.14.2
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4
        ports:
        - containerPort: 80

    nodeSelector フィールドで、TPU タイプ、TPU トポロジ、アクセラレータ数を定義します。ここで、

    • cloud.google.com/gke-tpu-accelerator: TPU タイプを定義します。例: tpu-v4-podslice
    • cloud.google.com/gke-tpu-topology: TPU トポロジを定義します（例: 2x2x1 または 4x4x8）。

    ワークロードで既存の予約を消費するには、nodeSelector フィールドに追加のラベルを指定します。 * cloud.google.com/reservation-name: GKE がノードの自動プロビジョニングに使用する予約の名前を定義します。

    limits: google.com/tpu で、ノードあたりの TPU チップの数を定義します。

ファイル

構成ファイルを使用して、複数のタイプの TPU に上限を割り当てることができます。次の YAML 構成では、2 種類の TPU を構成しています。

  resourceLimits:
    - resourceType: 'cpu'
      maximum: 10000
    - resourceType: 'memory'
      maximum: 10000
    - resourceType: 'tpu-v4-podslice'
      maximum: 32
    - resourceType: 'tpu-v5-lite'
      maximum: 64

自動プロビジョニングの構成ファイルを使用するには:

  1. 上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。resourceType と maximum の値を編集します。resourceType の値を必要な数だけ追加します。ファイルを保存します。

  2. 次のコマンドを実行して、構成をクラスタに適用します。

gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-config-file FILE_NAME

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • FILE_NAME: 構成ファイルの名前。

詳細については、gcloud container clusters update のドキュメントをご覧ください。

ノード自動プロビジョニングのロケーション

ノードの自動プロビジョニングで新しいノードプールを作成できるゾーンを設定します。リージョンのロケーションはサポートされていません。ゾーンは、クラスタと同じリージョンに属している必要がありますが、クラスタレベルで定義されているノードの場所には限定されません。ノードの自動プロビジョニングの場所を変更しても、既存のノードプールに影響はありません。

ノードの自動プロビジョニングで新しいノードプールを作成できるロケーションを設定するには、gcloud CLI または構成ファイルを使用します。

gcloud

次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning --autoprovisioning-locations=ZONE

次のように置き換えます。

  • CLUSTER_NAME: クラスタの名前。
  • ZONE: ノード自動プロビジョニングで新しいノードプールを作成できるゾーン。複数のゾーンを指定するには、各ゾーンをカンマで区切ります（例: ZONE1, ZONE2,...）。

ファイル

ノードの自動プロビジョニングで新しいノードプールを作成できるロケーションを設定するには、構成ファイルを使用します。

次の YAML 構成を追加して、新しいノードプールのロケーションを設定します。

    autoprovisioningLocations:
      - ZONE

ZONE は、ノード自動のプロビジョニングで新しいノードプールを作成できるゾーンに置き換えます。複数のゾーンを指定するには、リストにゾーンを追加します。ファイルを保存します。

自動プロビジョニングの構成ファイルを使用するには:

  1. gcloud CLI がアクセスできるロケーションに構成ファイルを作成します。

  2. クラスタに構成ファイルを適用します。

    gcloud container clusters update CLUSTER_NAME \
    --enable-autoprovisioning \
    --autoprovisioning-config-file FILE_NAME

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前。
    • FILE_NAME: 構成ファイルのパス。

コンパクト プレースメントにより物理的に近接したノード

GKE バージョン 1.25 以降では、ノードの自動プロビジョニングでコンパクト プレースメント ポリシーがサポートされています。コンパクト プレースメント ポリシーを使用すると、ゾーン内で相互により近接したノードプールを作成するよう GKE に指示できます。

コンパクト プレースメント ポリシーを定義するには、次のキーを使用して nodeSelector を Pod 仕様に追加します。

次の例では、プレースメント グループ ID が placement-group-1、マシン ファミリーが c2 のコンパクト プレースメント ポリシーを設定します。

apiVersion: v1
kind: Pod
metadata:
  ...
spec:
  ...
  nodeSelector:
    cloud.google.com/gke-placement-group: placement-group-1
    cloud.google.com/machine-family: c2

詳細については、GKE ノードのコンパクト プレースメントを定義する方法をご覧ください。

ノード自動プロビジョニング機能を無効にする

特定のクラスタのノード自動プロビジョニング機能を無効にすると、ノードプールが自動プロビジョニングされなくなります。

gcloud

クラスタのノードの自動プロビジョニングを無効にするには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
  --no-enable-autoprovisioning

CLUSTER_NAME は、使用するクラスタの名前に置き換えます。

ファイル

Google Cloud コンソールを使用してノードの自動プロビジョニングを無効にするには:

  1. Google Cloud コンソールで Google Kubernetes Engine のページに移動します。

    Google Kubernetes Engine に移動

  2. クラスタの名前をクリックします。

  3. [自動化] の [ノードの自動プロビジョニング] で、[編集] をクリックします。

  4. [ノードの自動プロビジョニングを有効にする] チェックボックスをオフにします。

  5. [変更を保存] をクリックします。

ノードプールを「自動プロビジョニングあり」とマークする

クラスタでノードの自動プロビジョニングを有効にすると、自動プロビジョニングするノードプールを指定できます。ワークロードが使用されていない場合、自動プロビジョニングされたノードプールは自動的に削除されます。

ノードプールを自動プロビジョニングとしてマークするには、次のコマンドを実行します。

gcloud container node-pools update NODE_POOL_NAME \
  --enable-autoprovisioning

NODE_POOL_NAME は、ノードプールの名前に置き換えます。

ノードプールを自動プロビジョニングなしとマークする

ノードプールを自動プロビジョニングなしとマークするには、次のコマンドを実行します。

gcloud container node-pools update NODE_POOL_NAME \
  --no-enable-autoprovisioning

NODE_POOL_NAME は、ノードプールの名前に置き換えます。

カスタムマシン ファミリーの使用

GKE 1.19.7-gke.800 以降では、ワークロードにマシン ファミリーを選択できます。T2D マシン ファミリーは、GKE バージョン 1.22 以降でサポートされています。

ワークロードにマシン ファミリーを選択するには、次のいずれかの準備作業を行います。

  • cloud.google.com/machine-family のキー、演算子 In、および目的のマシン ファミリー（n2 など）を使用してノード アフィニティを設定する。
  • キーが cloud.google.com/machine-family で、値が目的のマシン ファミリーである nodeSelector を追加する。

次の例では、nodeAffinity を n2 のマシン ファミリーに設定しています。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/machine-family
            operator: In
            values:
            - n2

変更を適用すると、ノードの自動プロビジョニングにより、指定したマシン ファミリー内のマシンタイプを使用する最適なノードプールが選択されます。一致式に複数の値が使用されている場合、そのうちの 1 つの値が任意に選択されます。

最小 CPU プラットフォーム

ノードの自動プロビジョニングでは、最小 CPU プラットフォームを指定してノードプールを作成できます。最小 CPU プラットフォームは、ワークロード レベル（推奨）またはクラスタレベルで指定できます。

次のステップ