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


このページでは、Standard Google Kubernetes Engine(GKE)クラスタでノード自動プロビジョニングを使用する方法を説明します。

Autopilot クラスタを使用すると、ノードプールがノード自動プロビジョニングによって自動的にプロビジョニングされ、またワークロードの要件に合わせて自動的にスケーリングされるため、ノードのプロビジョニングやノードプールの管理について心配する必要はありません。

概要

ノードの自動プロビジョニングは、ユーザーに代わってノードプールのリストを自動的に管理します。ノードの自動プロビジョニング機能が有効でないと、GKE はユーザーの作成したノードプール セットに含まれるノードだけを新たな対象として扱います。ノードの自動プロビジョニング機能が有効な場合は、新しいノードプールの作成と削除が自動的に行われます。

始める前に

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

次のいずれかの方法で gcloud のデフォルトの設定を指定します。

  • gcloud init。デフォルトの設定全般を確認する場合に使用します。
  • gcloud config。プロジェクト ID、ゾーン、リージョンを個別に設定する場合に使用します。

gcloud init の使用

エラー One of [--zone, --region] must be supplied: Please specify location を受信した場合は、このセクションの内容を実施します。

  1. gcloud init を実行して、次の操作を行います。

    gcloud init

    リモート サーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。

    gcloud init --console-only
  2. 手順に従って gcloud を承認し、Google Cloud アカウントを使用します。
  3. 新しい構成を作成するか、既存の構成を選択します。
  4. Google Cloud プロジェクトを選択します。
  5. ゾーンクラスタの場合はデフォルトの Compute Engine ゾーン、リージョン クラスタまたは Autopilot クラスタの場合はデフォルトの Compute Engine リージョンを選択します。

gcloud config の使用

  • デフォルトのプロジェクト ID を設定します。
    gcloud config set project PROJECT_ID
  • ゾーンクラスタを使用する場合は、デフォルトのコンピューティング ゾーンを設定します。
    gcloud config set compute/zone COMPUTE_ZONE
  • Autopilot クラスタまたはリージョン クラスタを使用する場合は、デフォルトのコンピューティング リージョンを設定します。
    gcloud config set compute/region COMPUTE_REGION
  • gcloud を最新バージョンに更新します。
    gcloud components update

要件

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

  • バージョン 1.11.2-gke.25 以降(ゾーンクラスタ)。
  • バージョン 1.12.x 以降(リージョン クラスタ)。

サポートされていない機能

次の機能はノード自動プロビジョニングではサポートされていません。つまり、ノード自動プロビジョニングではこれらの機能を使用してノードプールをプロビジョニングすることはありませんが、既存のノードプールが自動スケーリングされます。

オペレーション

ノードの自動プロビジョニングはクラスタ オートスケーラーの仕組みの 1 つで、ノードプール単位でスケーリングを行います。ノードの自動プロビジョニング機能が有効になっていると、クラスタ オートスケーラーはスケジュール不可の Pod の仕様に基づいてノードプールを自動的に拡張します。

ノード自動プロビジョニングは、次の情報に基づいてノードプールを作成します。

リソースの上限

ノードの自動プロビジョニングとクラスタ オートスケーラーには、次の 2 つのレベルで上限が設定されています。

  • ノードプール レベル
  • クラスタレベル

ノードプールの上限

ノードの自動プロビジョニングによって作成されるノードプールは 1,000 ノードに制限されています。

クラスタの上限

定義した上限は、自動プロビジョニングされたプールだけでなく、クラスタ全体で使用される CPU リソースとメモリリソースの合計に基づいて適用されます。

クラスタ オートスケーラーは、設定した制限を超えない範囲で新しいノードを作成します。上限をすでに超えている場合でも、ノードは自動的に削除されません。

ワークロードの分離

保留中の Pod にノード アフィニティと容認機能が設定されている場合、ノードの自動プロビジョニングはラベルと taint が一致するようにノードをプロビジョニングできます。

次の条件をすべて満たすと、ノードの自動プロビジョニングはラベルと taints を持つノードプールを作成します。

  • 保留中の Pod のノードに特定のラベルキーと値が設定されている。
  • その Pod には同じキーを持つ taint の容認機能がある。
  • この容認機能が NoSchedule エフェクト、NoExecute エフェクト、またはすべてのエフェクトに対応している。

Pod の仕様は、特定のラベルを持つノードを必要とすることを、次の 2 つの方法で表現できます。

  • nodeSelector フィールドを使用する。
  • nodeAffinity フィールドで In 演算子と 1 つの値を指定する。

次に、ワークロードの分離リクエストとして解釈される Pod の仕様の一部を示します。この例では、クラスタ管理者がワークロードの分離に使用されるキーとして dedicated を選択しています。また、UI チームはワークロードに専用のノードが必要であると判断しています。

Pod には、dedicated=ui-team というラベルの付いたノードの容認能力があり、ノードの選択に nodeAffinity を使用しています。

spec:
  tolerations:
  - key: dedicated
    operator: Equal
    value: ui-team
    effect: NoSchedule
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: dedicated
            operator: In
            values:
            - ui-team

この Pod が存在する場合、dedicated=ui-team:NoSchedule という taint、dedicated=ui-team というレベルを有するノードは、ノード自動プロビジョニングによって作成されたと見なされます。

次の例では nodeSelector を使用していますが、結果は同じです。

spec:
  tolerations:
  - key: dedicated
    operator: Equal
    value: ui-team
    effect: NoSchedule
  nodeSelector:
    dedicated: ui-team

自動プロビジョニングされたノードプールの削除

自動プロビジョニングされたノードプールにノードが存在しない場合、GKE はそのノードプールを削除します。「自動プロビジョニングあり」とマークされていないノードプールは削除されません。

サポートされているマシンタイプ

GKE 1.19.7-gke.800 の時点で、ノード自動プロビジョニングによってノードプールが作成される際は、すべてのマシンタイプが考慮されますが、N1 マシンについてはその例外です。この場合、ノード自動プロビジョニングでは、最大で 64 個の vCPU を持つマシンのみが考慮されます。デフォルトでは、次の場合を除き、E2 マシン ファミリーが使用されます。

  • E2 マシン ファミリーがワークロード リクエストを処理できない。たとえば、ワークロードで GPU がリクエストされた場合、新しいノードプールには N1 マシン ファミリーが使用されます。
  • ワークロードがマシン ファミリー ラベルを使用している。ワークロード リクエストを処理できない場合(上述の場合)、これはオーバーライドされる可能性があります。詳細については、カスタムマシン ファミリーの使用をご覧ください。

GKE 1.19.7-gke.800 より前のバージョンでは、ノード自動プロビジョニングで考慮されるのは N1 マシンタイプ(最大 64 個の vCPU)のみです。

サポートされているノードイメージ

現在、ノードの自動プロビジョニングによるノードプールの作成には「Container-Optimized OS ノードイメージを使用する」という制限が課せられています。

プリエンプティブル VM のサポート

ノードの自動プロビジョニングでは、プリエンプティブル仮想マシン(VM)インスタンスに基づいてノードプールを作成できます。

プリエンプティブル VM に基づくノードプールの作成が検討されるのは、cloud.google.com/gke-preemptible="true":NoSchedule taint の容認機能を持つスケジュール不可の Pod が存在する場合に限ります。

プリエンプティブル VM に基づいて自動プロビジョニングされたノードプールによって作成されたノードには taint が適用されます。

エフェメラル ストレージをリクエストする Pod のサポート

ノード自動プロビジョニングでは、Pod がエフェメラル ストレージをリクエストした場合にノードプールを作成できます。ノードプールでプロビジョニングされたブートディスクのサイズは、新しく自動プロビジョニングされるすべてのノードプールに適用されます。ブートディスクのサイズはカスタマイズできます。デフォルトは 100 GiB です。ローカル SSD に基づくエフェメラル ストレージはサポートされていません。

ノード自動プロビジョニングは、指定したブートディスクを持つノードの割り当て可能エフェメラル ストレージが保留中の Pod のエフェメラル ストレージのリクエストより大きい場合にのみノードプールをプロビジョニングします。エフェメラル ストレージのリクエストが割り当て可能な値よりも大きい場合、ノード自動プロビジョニングはノードプールをプロビジョニングしません。ノードのディスクサイズが、保留中の Pod のエフェメラル ストレージのリクエストに基づいて動的に構成されることはありません。

この Pod のエフェメラル ストレージ サポートは、GKE バージョン 1.19.7-gke.800 以降と 1.18.12-gke.1210 以降でサポートされています。

スケーラビリティの制限

ノードの自動プロビジョニングには、クラスタ オートスケーラーと同じ制限事項のほかに、次の制限があります。

分離されたワークロード数の上限
ノードの自動プロビジョニングでは、分離されたワークロードが最大 100 個までサポートされます。
ノードプール数の上限
ノードの自動プロビジョニングでは、プール数が 100 に近づくと、新しいノードプールの作成の優先度が低くなります。100 を超えるノードプールは、保留中の Pod のスケジュールを設定する方法が他にない場合のみ作成できます。

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

クラスタでノードの自動プロビジョニングを有効にするには、gcloud または Google Cloud Console を使用します。

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

Console

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

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

Google Kubernetes Engine のメニューに移動

  1. 目的のクラスタを選択します。
  2. アイコンをクリックします。
  3. [ノードの自動プロビジョニング] までスクロールし、[有効] を選択します。
  4. クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
  5. [保存] をクリックします。GKE がクラスタを更新します。

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

ノードの自動プロビジョニングは、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-k80'
   maximum: 4
management:
  autoRepair: true
  autoUpgrade: true
shieldedInstanceConfig:
  enableSecureBoot: true
  enableIntegrityMonitoring: true
diskSizeGb: 100

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

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

  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 によって直接指定されません。これらの設定のデフォルト値を設定できます。これは、新しく作成されたすべてのノードプールに適用されます。

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

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

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

gcloud

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

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

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

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

次のサンプルセットでは、dev-cluster クラスタのデフォルトのサービス アカウントとして test-service-account@google.com を設定しています。

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 がアクセスできる場所に 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 がアクセスできる場所に 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 からアクセス可能な場所にあるファイルに上記の構成をコピーします。enableSecureBootenableIntegrityMonitoring の値を編集します。ファイルを保存します。

  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 からアクセス可能な場所にあるファイルに上記の構成をコピーします。autoUpgradeautoRepair の値を編集します。ファイルを保存します。

  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 \
    --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 からアクセス可能な場所にあるファイルに上記の構成をコピーします。maxSurgeUpgrademaxUnavailableUpgrade の値を編集します。ファイルを保存します。

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

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

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

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

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

カスタム ブートディスク

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

構成ファイルを使用してブートディスクの設定をカスタマイズできます。次の YAML 構成では、ノードの自動プロビジョニングによって 100 GB の SSD ディスクで構成されるノードプールが作成されます。

  diskSizeGb: 100
  diskType: pd-ssd

以下を指定します。

  • diskSizeGb: ディスクのサイズ(GB)。
  • diskType: ディスクのタイプ。次のいずれかの値になります。
    • pd-standard: 標準の永続ディスク(デフォルト)。
    • pd-ssd: SSD 永続ディスク。

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

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

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

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

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

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

GPU の上限の構成

ノードの自動プロビジョニングで GPU で使用する場合、gcloud ツールまたは Google Cloud Console を使用して、クラスタ内の各 GPU タイプに上限を設定できます。複数のタイプの 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-k80 GPU アクセラレータに GPU の上限を設定しています。

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

ファイル

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

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

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

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

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

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

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

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

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

Console

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

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

Google Kubernetes Engine のメニューに移動

  1. 目的のクラスタを選択します。
  2. 編集)アイコンをクリックします。
  3. [ノードの自動プロビジョニング] までスクロールし、[有効] を選択します。
  4. クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
  5. [ リソースの追加] をクリックします。
  6. 追加する GPU のタイプを選択します(たとえば、NVIDIA TESLA K80 など)。 クラスタに追加する GPU の最小数と最大数を設定します。
  7. GKE で GPU の制限事項に同意します。
  8. [保存] をクリックします。GKE がクラスタを更新します。

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

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

ノード自動プロビジョニングで新しいノードプールを作成できるロケーションを設定するには、次のコマンドを実行します。

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

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

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

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

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

gcloud

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

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

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

Console

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

  1. Cloud Console で Google Kubernetes Engine のメニューに移動します。

Google Kubernetes Engine のメニューに移動

  1. 目的のクラスタを選択します。
  2. 編集)アイコンをクリックします。
  3. [ノードの自動プロビジョニング] までスクロールし、[無効] を選択します。

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

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

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

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 以降では、ワークロードのマシン ファミリーを選択できます。それには、次のいずれかの操作を行います。

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

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

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

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

次のステップ