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

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

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

概要

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

始める前に

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

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

Google Kubernetes Engine API を有効にする

Cloud SDK がインストール済みであることを確認します。

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

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

gcloud init の使用

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

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

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

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
```

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

要件

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

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

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

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

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

オペレーション

ノードの自動プロビジョニングはクラスタオートスケーラーの仕組みの 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 の時点で、ノード自動プロビジョニングによってノードプールが作成される際は、すべてのマシンタイプが考慮されますが、N1 マシンについてはその例外です。この場合、ノード自動プロビジョニングでは、最大で 64 個の vCPU を持つマシンのみが考慮されます。デフォルトでは、次の場合を除き、E2 マシンファミリーが使用されます。

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

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

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

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

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

プリエンプティブル 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

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

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

Google Kubernetes Engine に移動
目的のクラスタを選択します。
アイコンをクリックします。
[ノードの自動プロビジョニング] までスクロールし、[有効] を選択します。
クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
[保存] をクリックします。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

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

所定の構成のファイルを 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 ツールまたは構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールに使用するノードイメージタイプを指定できます。この設定は、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 ツールまたは構成ファイルを使用して、新しく自動プロビジョニングされたノードプールのデフォルト 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 ツールまたは構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールでサージアップグレードの設定を指定できます。

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-standard: 標準の永続ディスク（デフォルト）。
- pd-ssd: SSD 永続ディスク。

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

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

最小 CPU プラットフォーム

ノードの自動プロビジョニングは、最小 CPU プラットフォームを使用したノードプールの作成をサポートします。

gcloud ツールまたは構成ファイルを使用すると、新しく自動プロビジョニングされたノードプールのデフォルトの最小 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: 構成ファイルの名前。

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

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

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 の制限事項に同意します。
[保存] をクリックします。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 を使用してノードの自動プロビジョニングを無効にするには:

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

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 つの値が任意に選択されます。

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

概要

始める前に

gcloud init の使用

gcloud config の使用

要件

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

オペレーション

リソースの上限

ノードプールの上限

クラスタの上限

ワークロードの分離

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

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

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

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

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

スケーラビリティの制限

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

gcloud

Console

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

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

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

gcloud

ファイル

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

gcloud

ファイル

顧客管理の暗号鍵（CMEK）

ノードの整合性

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

gcloud

ファイル

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

gcloud

ファイル

カスタム ブートディスク

最小 CPU プラットフォーム

gcloud

ファイル

GPU の上限の構成

gcloud

ファイル

Console

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

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

gcloud

Console

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

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

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

次のステップ

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

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

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

カスタムブートディスク

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