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

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

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

概要

ノードの自動プロビジョニングは、ユーザーに代わってノードプールのリストを自動的に管理します。ノードの自動プロビジョニングが有効でないと、GKE はユーザーの作成したノードプールからのみ新しいノードを開始します。ノードの自動プロビジョニングが有効な場合、新しいノードプールの作成と削除が自動的に行われます。

始める前に

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

Google Kubernetes Engine API が有効になっていることを確認します。

Google Kubernetes Engine API の有効化

Google Cloud CLI がインストールされていることを確認します。
次のいずれかの方法で、プロジェクトにデフォルトの Google Cloud CLI 設定をセットアップします。

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

gcloud init

gcloud init を実行して、次の操作を行います。
```
gcloud init
```
リモートサーバーで SSH を使用している場合は、--console-only フラグを指定して、コマンドがブラウザを起動しないようにします。
```
gcloud init --console-only
```
Google Cloud アカウントを使用できるように、gcloud CLI の承認手順を行います。
新しい構成を作成するか、既存の構成を選択します。
Google Cloud プロジェクトを選択します。
デフォルトの Compute Engine ゾーンを選択します。
デフォルトの Compute Engine リージョンを選択します。

注: これらのデフォルト設定をオーバーライドするには、gcloud CLI で --project、--zone、--region フラグを使用します。

gcloud config

デフォルトのプロジェクト ID を設定します。
```
gcloud config set project PROJECT_ID
```
デフォルトの Compute Engine リージョン（例: us-central1）を設定します。
```
gcloud config set compute/region COMPUTE_REGION
```
デフォルトの Compute Engine ゾーン（例: us-central1-c）を設定します。
```
gcloud config set compute/zone COMPUTE_ZONE
```
gcloud を最新バージョンに更新します。
```
gcloud components update
```

注: これらのデフォルト設定をオーバーライドするには、gcloud CLI で --project、--zone、--region フラグを使用します。

デフォルトの場所を設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。

要件

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

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

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

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

gvisor
Windows オペレーティングシステム。
予約アフィニティの制御。
ローカルの PersistentVolume の自動スケーリング。
エフェメラルストレージとしてローカル SSD を使用するノードの自動プロビジョニング。
変更されたフィルタを使用するカスタムスケジューリングによる自動プロビジョニング。
同時マルチスレッド（SMT）の構成。

オペレーション

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

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

CPU、メモリ、エフェメラルストレージのリソースリクエスト
GPU リクエスト
保留中の Pod のノードアフィニティとラベルセレクタ
保留中の Pod の Node Taints と容認機能

リソースの上限

ノードの自動プロビジョニングとクラスタオートスケーラーには、次の 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 の時点で、ノードの自動プロビジョニングでは、ノードプールを作成する際にすべてのマシンタイプが考慮されます。ただし、次の例外があります。

T2D マシンファミリーは、GKE バージョン 1.19.16-gke.7600 以降でサポートされています。
N1 マシンの場合、ノードの自動プロビジョニングでは、最大 64 個の vCPU を持つマシンのみが考慮されます。
デフォルトでは、次の場合を除き、E2 マシンファミリーが使用されます。
- ワークロードが、E2 マシンファミリーで利用できない機能をリクエストしている場合。たとえば、ワークロードで GPU がリクエストされた場合、新しいノードプールには N1 マシンファミリーが使用されます。
- ワークロードが machine-family ラベルを使用する場合。ワークロードリクエストを処理できない場合（上述の場合）は、オーバーライドされることがあります。詳細については、カスタムマシンファミリーの使用をご覧ください。

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

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

ノードの自動プロビジョニングによって、次のノードイメージのいずれかを使用してノードプールが作成されます。

Container-Optimized OS（cos または cos_containerd）。
Ubuntu（ubuntu または ubuntu_containerd）。

Spot VM のサポート

ノードの自動プロビジョニングでは、Spot VM に基づくノードプールの作成がサポートされています。

Spot VM に基づくノードプールの作成は、cloud.google.com/gke-spot="true":NoSchedule taint の容認機能を持つスケジューリングできない Pod が存在する場合にのみ考慮されます。Spot VM に基づいて自動プロビジョニングされたノードプール内のノードには、taint が自動的に適用されます。

容認機能を、nodeSelector や cloud.google.com/gke-spot="true" ノードラベルのノードアフィニティルールと組み合わせて使用し、Spot VM に基づくノードプールでのみワークロードが実行されるようにできます。

エフェメラルストレージをリクエストする 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

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

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

Google Kubernetes Engine に移動
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[編集] をクリックします。
[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
[保存] をクリックします。

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

ノードの自動プロビジョニングは、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

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

所定の構成のファイルを gcloud がアクセスできる場所に作成します。
次のコマンドを実行して、構成をクラスタに適用します。
```
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
- cos: Docker を含む Container-Optimized OS
- ubuntu_containerd: Containerd を含む Ubuntu
- ubuntu: Docker を含む Ubuntu

ファイル

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

YAML 構成を保存します。

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

構成を適用します。
```
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 クラスタのデフォルトのサービスアカウントとして 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,...）。

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

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

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

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: 鍵の名前。

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

gcloud がアクセスできる場所に CMEK 鍵を指定する構成ファイルを作成します。
次のコマンドを実行して、構成をクラスタに適用します。
```
gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- FILE_NAME: 構成ファイルの名前。

ノードの整合性

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

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

  shieldedInstanceConfig:
    enableSecureBoot: true
    enableIntegrityMonitoring: false

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

gcloud からアクセス可能な場所にあるファイルに上記の構成をコピーします。enableSecureBoot と enableIntegrityMonitoring の値を編集します。ファイルを保存します。
次のコマンドを実行して、構成をクラスタに適用します。
```
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

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

gcloud からアクセス可能な場所にあるファイルに上記の構成をコピーします。autoUpgrade と autoRepair の値を編集します。ファイルを保存します。
次のコマンドを実行して、構成をクラスタに適用します。

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

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

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

ノードのサージアップグレードの設定

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

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

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

gcloud からアクセス可能な場所にあるファイルに上記の構成をコピーします。maxSurgeUpgrade と maxUnavailableUpgrade の値を編集します。ファイルを保存します。
次のコマンドを実行して、構成をクラスタに適用します。

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-balanced（デフォルト）
- pd-standard
- pd-ssd

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

gcloud がアクセスできる場所に、所定のブートディスク構成を持つファイルを作成します。
次のコマンドを実行して、構成をクラスタに適用します。
```
gcloud container clusters update CLUSTER_NAME \
   --enable-autoprovisioning \
   --autoprovisioning-config-file FILE_NAME
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- FILE_NAME: 構成ファイルの名前。

GPU の上限の設定

ノードの自動プロビジョニングで GPU で使用する場合、gcloud CLI　または 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

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

gcloud からアクセス可能な場所にあるファイルに上記の構成をコピーします。cpu と memory の値を編集します。resourceType の値を必要な数だけ追加します。ファイルを保存します。
次のコマンドを実行して、構成をクラスタに適用します。

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

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

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

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

Console

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

Cloud Console で Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[編集] をクリックします。
[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
[ リソースの追加] をクリックします。
追加する GPU のタイプを選択します（たとえば、NVIDIA TESLA K80 など）。クラスタに追加する GPU の最小数と最大数を設定します。
GKE で GPU の制限事項に同意します。
[保存] をクリックします。

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

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

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

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 を使用してノードの自動プロビジョニングを無効にするには:

Cloud Console で Google Kubernetes Engine のページに移動します。

Google Kubernetes Engine に移動
クラスタの名前をクリックします。
[自動化] の [ノードの自動プロビジョニング] で、[編集] をクリックします。
[ノードの自動プロビジョニングを有効にする] チェックボックスをオフにします。
[保存] をクリックします。

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

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

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

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 プラットフォームは、ワークロードレベル（推奨）またはクラスタレベルで指定できます。

ワークロードレベルで最小 CPU プラットフォームを選択する

GKE バージョン 1.23 以降では、ワークロードに対して最小 CPU プラットフォームを選択できます。

ワークロードに対して最小 CPU プラットフォームを選択するには、必要な最小 CPU プラットフォームと互換性のあるマシンファミリーを指定し、次のいずれかの作業を行います。

key に「cloud.google.com/requested-min-cpu-platform」、operator に「In」、目的の最小 CPU プラットフォームの値にスペースをアンダースコアに置き換えた形（例: AMD_Milan）を指定したノードアフィニティルールを追加します。
key に「cloud.google.com/requested-min-cpu-platform」、必要な最小 CPU プラットフォームの値にスペースをアンダースコアに置き換えた形（例: AMD_Milan）を指定した nodeSelector を追加します。

次の例では、nodeAffinity を n2d ファミリーの最小 CPU プラットフォームである AMD Milan に設定します。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: cloud.google.com/machine-family
            operator: In
            values:
            - n2d
          - key: cloud.google.com/requested-min-cpu-platform
            operator: In
            values:
            - AMD_Milan

最小 CPU プラットフォームをリクエストするワークロードは、key が cloud.google.com/requested-min-cpu-platform の同じ値を持つ自動プロビジョニングされたノードプールでのみスケジュールできます。たとえば、ワークロードが cloud.google.com/requested-min-cpu-platform=Intel_Ice_Lake をリクエストし、ノード自動プロビジョニングが新しいノードプールを作成する場合、GKE は Intel_Ice_Lake をリクエストする後続のワークロードをそのノードプールでスケジュールします。しかし、Intel Ice Lake が実際には Intel Cascade Lake より上位のプラットフォームであっても、Intel_Cascade_Lake をリクエストするワークロードでは別のノードプールの作成がトリガーされます。

クラスタレベルで最小 CPU プラットフォームを選択する

新しく自動プロビジョニングされたノードプールには、gcloud CLI または構成ファイルを使用して、クラスタ全体にわたるデフォルトの最小 CPU プラットフォームを指定できます。

gcloud

デフォルトの最小 CPU プラットフォームを設定するには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
  --enable-autoprovisioning \
  --autoprovisioning-min-cpu-platform MIN_CPU_PLATFORM

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

CLUSTER_NAME: クラスタの名前。
MIN_CPU_PLATFORM: 目的の最小 CPU プラットフォーム。

ファイル

デフォルトの最小 CPU プラットフォームを設定するには、構成ファイルを使用します。次の YAML 構成では、デフォルトの最小 CPU プラットフォームが設定されています。

minCpuPlatform: MIN_CPU_PLATFORM

MIN_CPU_PLATFORM は、必要な最小 CPU プラットフォームに置き換えます。

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

gcloud がアクセスできる場所に、最小 CPU プラットフォームを指定する構成ファイルを作成します。

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

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

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

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

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

概要

始める前に

gcloud init

gcloud config

要件

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

オペレーション

リソースの上限

ノードプールの上限

クラスタの上限

ワークロードの分離

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

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

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

Spot VM のサポート

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

スケーラビリティの制限

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

gcloud

Console

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

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

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

gcloud

ファイル

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

gcloud

ファイル

顧客管理の暗号鍵（CMEK）

ノードの整合性

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

gcloud

ファイル

ノードのサージ アップグレードの設定

gcloud

ファイル

カスタム ブートディスク

GPU の上限の設定

gcloud

ファイル

Console

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

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

gcloud

Console

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

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

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

最小 CPU プラットフォーム

ワークロード レベルで最小 CPU プラットフォームを選択する

クラスタレベルで最小 CPU プラットフォームを選択する

gcloud

ファイル

次のステップ

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

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

ノードのサージアップグレードの設定

カスタムブートディスク

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

ワークロードレベルで最小 CPU プラットフォームを選択する