ノードプールの自動作成を構成する

Standard

Google Kubernetes Engine（GKE）Standard クラスタで、保留中の Pod のノードプールを GKE が自動的に作成するようにすることで、手動によるインフラストラクチャ管理の量を減らすことができます。このドキュメントでは、クラスタとワークロードのノードプールの自動作成を有効にする方法、自動作成されたノードのデフォルト値を設定する方法、一般的なユースケースで自動作成をトリガーする方法について説明します。

このドキュメントは、Standard クラスタでインフラストラクチャを管理し、ワークロードをデプロイするクラスタ管理者、オペレーター、デベロッパーを対象としています。ノードプールの自動作成の仕組みと、さまざまな有効化方法（ComputeClass やクラスタレベルのノード自動プロビジョニングなど）について詳しくは、ノードプールの自動作成についてをご覧ください。

制限事項

ノードプールの自動作成には次の制限があります。

• クラスタ オートスケーラーの制限事項はすべて、ノードプールの自動作成にも適用されます。
• ノードプールの合計数が 200 を超えるクラスタでは、自動スケーリング中にレイテンシが増加する可能性があります。ワークロードの分離や複数の ComputeClass の使用など、新しいノードプールの作成をトリガーする構成を行うと、この数が増加します。クラスタの上限の詳細については、「大規模なクラスタの計画」の上限とベスト プラクティスをご覧ください。
• ノードの自動プロビジョニングを有効にしたときにクラスタに設定したリソース上限は、GKE が ComputeClass 用に作成するノードプールにも適用されます。
• 次の設定は、ComputeClass でサポートされていません。
  • サージ アップグレードまたは Blue/Green アップグレード。
  • ノードの整合性とセキュアブート。
• 1.33.3-gke.1136000 より前の GKE バージョンで ComputeClass のノードプールの自動作成を有効にするには、クラスタレベルのノード自動プロビジョニングも有効にする必要があります。この制限は、GKE バージョン 1.33.3-gke.1136000 以降には適用されません。

始める前に

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

• Google Kubernetes Engine API を有効にする。
Google Kubernetes Engine API の有効化
• このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update コマンドを実行して最新のバージョンを取得します。以前のバージョンの gcloud CLI では、このドキュメントのコマンドを実行できない場合があります。
  注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

要件

ノードの自動プロビジョニング機能を使用すると、任意の GKE バージョンでクラスタ全体のノードプールの自動作成を有効にできます。ComputeClass を使用してワークロード レベルでノードプールの自動作成を有効にし、ノード自動プロビジョニングを有効にしない場合は、クラスタが次の要件を満たしている必要があります。

• GKE バージョン 1.33.3-gke.1136000 以降を使用します。
• Rapid リリース チャンネルを使用します。

特定のノード構成のノードプールの自動作成をトリガーするには、対応するバージョン要件を満たす必要があります。さまざまな構成のバージョン サポートの詳細については、GKE リリースノート（新機能）またはユースケースのドキュメントをご覧ください。

ワークロード レベルの自動作成を有効にする

ComputeClass を使用すると、クラスタ内の特定のワークロードに対してノードプールの自動作成を有効にできます。ComputeClass 仕様の nodePoolAutoCreation フィールドは、その ComputeClass を選択する Pod の新しいノードプールを GKE が作成できるかどうかを制御します。GKE バージョン 1.33.3-gke.1136000 以降では、クラスタでノードの自動プロビジョニングが有効になっていない場合でも、ComputeClass のノードプールの自動作成を有効にできます。1.33.3-gke.1136000 より前のバージョンでは、クラスタレベルのノード自動プロビジョニングを有効にする必要もあります。

ComputeClass のノードプールの自動作成を有効にするには、次の操作を行います。

1. 次の要件を満たす新規または既存の Standard クラスタを使用します。

   • GKE バージョン 1.33.3-gke.1136000 以降を使用します。
   • Rapid リリース チャンネルを使用します。

   必要に応じて、新しい Standard クラスタを作成できます。

2. クラスタが前の手順の要件を満たしていない場合は、クラスタレベルのノードの自動プロビジョニングを有効にします。

3. 次の ComputeClass の例を YAML ファイルとして保存します。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     -  machineFamily: n4
     -  machineFamily: n2
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

   COMPUTE_CLASS は、新しい ComputeClass の名前に置き換えます。ComputeClass で使用可能なフィールドの詳細については、ComputeClass CustomResourceDefinition をご覧ください。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

5. ComputeClass を選択する次の Deployment の例を helloweb-deploy.yaml として保存します。

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: helloweb
     labels:
       app: hello
   spec:
     selector:
       matchLabels:
         app: hello
     template:
       metadata:
         labels:
           app: hello
       spec:
         nodeSelector:
           # Replace with the name of a compute class
           cloud.google.com/compute-class: COMPUTE_CLASS 
         containers:
         - name: hello-app
           image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
           ports:
           - containerPort: 8080
           resources:
             requests:
               cpu: "250m"
               memory: "1Gi"

6. クラスタに Deployment を作成します。

   kubectl apply -f helloweb-deploy.yaml
   

7. GKE が Pod の新しいノードプールを作成したことを確認するには、クラスタ内のノードプールのリストを取得します。

   gcloud container node-pools list \
       --cluster=CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION
   

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

   • CLUSTER_NAME: クラスタの名前。
   • CONTROL_PLANE_LOCATION: クラスタ コントロール プレーンのリージョンまたはゾーン（例: us-central1、us-central1-a）。

クラスタレベルのノード自動プロビジョニングを有効にする

GKE クラスタ全体でノードプールの自動作成を有効にするには、ノードの自動プロビジョニング設定を使用します。ノードの自動プロビジョニングを使用すると、GKE は Pod 仕様または ComputeClass の構成に基づいて、クラスタ全体で保留中のワークロード用に新しいノードプールを作成できます。新規または既存のクラスタでノード自動プロビジョニングを有効にできます。

ノード自動プロビジョニングを有効にする前に、VPC サブネットのプライマリ IPv4 アドレス範囲のサイズを計画します。GKE は、この IP アドレス範囲をプライマリ ノードの IP アドレス範囲として使用します。クラスタのサイズとスケールによっては、デフォルトのノード IP アドレス範囲に、新しいノードに割り当てるのに十分な IP アドレスがない場合があります。クラスタの作成後にノードの IP アドレス範囲のサイズを更新する場合は、新しい IP アドレスからのトラフィックを許可するように GKE クラスタのファイアウォール ルールを更新する必要があります。

1.33.3-gke.1136000 より前の GKE バージョンで自動作成されたノードプールを取得するには、このセクションの手順を行う必要があります。 Google Cloud コンソールでクラスタ構成を編集して、既存のクラスタのノード自動プロビジョニングを有効にすることもできます。

注意: 既存のクラスタでノード自動プロビジョニングを有効にすると、互換性のあるノードセレクタまたは ComputeClass 構成を持つ保留中のワークロードによって、ノードプールの自動作成がトリガーされることがあります。既存のワークロード仕様を検証して、意図しない自動スケーリングのリスクを最小限に抑えます。

新しいクラスタを作成するときにノードの自動プロビジョニングを有効にするには、次のいずれかのオプションを選択します。

コンソール

1. Google Cloud コンソールで、[Kubernetes クラスタを作成する] ページに移動します。

   [Kubernetes クラスタの作成] に移動

2. [クラスタの基本] ページで、新しいクラスタの名前とロケーションを指定します。

3. ナビゲーション メニューで [自動化] をクリックします。

4. [ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。[上限] セクションが表示されます。

5. CPU とメモリの上限を指定します。

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

gcloud

gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-autoprovisioning \
    --min-cpu=MINIMUM_CPU \
    --min-memory=MINIMUM_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: ノード自動プロビジョニングを有効にするクラスタの名前。
• CONTROL_PLANE_LOCATION: クラスタ コントロール プレーンのリージョンまたはゾーン（例: us-central1、us-central1-a）。
• MINIMUM_CPU: クラスタの最小コア数。
• MINIMUM_MEMORY: クラスタの最小メモリ容量（GiB）。
• MAXIMUM_CPU: クラスタの最大コア数。この上限は、手動で作成されたノードプールを含め、クラスタ内の新規および既存のすべてのノードの CPU コア数の合計に適用されます。
• MAXIMUM_MEMORY: クラスタの最大メモリ容量（GiB）。この上限は、手動で作成されたノードプールを含め、クラスタ内の新しいノードプールと既存のノードプールすべてのメモリ容量の合計に適用されます。

ノード自動プロビジョニング構成ファイルを使用して設定を構成する

YAML 構成ファイルを使用して、ノードの自動プロビジョニングのリソースの上限とノード構成の設定を構成できます。構成ファイルを使用すると、自動作成されたノードプールのデフォルト値を宣言的に指定し、ノードの自動修復の有効化などの詳細構成を実行できます。このファイルは、Kubernetes カスタム リソースである ComputeClass に関連していません。代わりに、構成ファイルは、コマンドライン フラグを使用してノードの自動プロビジョニングの設定を指定するよりも拡張性の高い代替手段として存在します。詳細については、構成ファイルを使用したクラスタレベルのデフォルト設定をご覧ください。

構成ファイルを作成して使用する手順は次のとおりです。

1. テキスト エディタで、Google Cloud CLI がアクセスできるパスに YAML ファイルを作成します。

2. 次の例のように、設定または変更する構成を追加します。

   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
   

   この例では、ノードの自動プロビジョニングに次の設定があります。

   • resourceLimits: クラスタ内の CPU、メモリ容量、NVIDIA T4 GPU のリソース上限を設定します。これらの上限は、手動で作成されたノードプールも含め、クラスタ内のリソース容量の合計に適用されます。
   • management: クラスタ内の自動作成されたすべての新しいノードプールに対して、ノードの自動修復とノードの自動アップグレードを有効にします。
   • shieldedInstanceConfig: クラスタ内の自動作成されたすべての新しいノードプールに対して、セキュアブートとノードの整合性モニタリングを有効にします。

3. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

構成ファイルをクラスタに適用すると、GKE は、クラスタ内の自動作成された新しいノードプールにファイルの設定を使用します。これらの設定は、GKE がクラスタに作成した既存のノードプールには適用されません。

ノードの自動プロビジョニングのリソース上限を構成する

クラスタレベルのノード自動プロビジョニングを使用する場合は、クラスタのすべてのノードプールで使用できるリソースの合計量の上限を構成する必要があります。クラスタでノード自動プロビジョニングを有効にするには、クラスタの CPU とメモリ容量の上限を指定する必要があります。また、GPU や TPU などの他のタイプのアタッチされたリソースを使用するには、それらのリソースの上限を指定する必要があります。これらの上限は、クラスタのノード自動プロビジョニング設定を有効にする場合にのみ必要です。ComputeClass のみを使用して自動作成されたノードプールを取得する場合は、リソース上限を構成する必要はありません。

ノードプールの自動作成のリソース上限を追加または変更するには、次のいずれかの方法を使用します。

• Google Cloud コンソール
• gcloud CLI フラグ
• クラスタレベルの構成ファイル

既存のクラスタのリソース上限を構成するには、次のいずれかのオプションを選択します。

コンソール

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. クラスタの名前をクリックします。 [クラスタの詳細] ページが開きます。

3. [詳細] タブをクリックします。

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

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

6. [上限] セクションで、クラスタの CPU 容量とメモリ容量の最小値と最大値を指定します。

7. GPU や TPU などの別のリソースの上限を構成する手順は次のとおりです。

   1. [Add resource] をクリックします。
   2. [リソースタイプ] プルダウン リストから、GPU モデルまたは TPU マシンタイプ（NVIDIA A100 80 GB や ct5p など）を選択します。
   3. リソースの最小値と最大値を指定します。

8. 省略可: [ノードプールのロケーション] セクションで、GKE がノードを作成する特定のゾーンを選択します。たとえば、GPU ワークロードを実行する場合は、選択した GPU タイプの高可用性を備えたゾーンを選択します。

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

gcloud

次のいずれかのコマンドを実行します。

• CPU とメモリのリソース上限を指定します。

  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY
  

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

  • MINIMUM_CPU: クラスタの最小コア数。
  • MINIMUM_MEMORY: クラスタの最小メモリ容量（GiB）。
  • MAXIMUM_CPU: クラスタの最大コア数。この上限は、手動で作成されたノードプールを含む、クラスタ内のすべてのノードプールの CPU コア数の合計に適用されます。
  • MAXIMUM_MEMORY: クラスタの最大メモリ容量（GiB）。この上限は、手動で作成されたノードプールを含む、クラスタ内のすべてのノードプールのメモリ容量の合計に適用されます。

• GPU リソースの上限を指定します。

  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=GPU_TYPE,count=MINIMUM_GPU_COUNT \
      --max-accelerator=type=GPU_TYPE,count=MAXIMUM_GPU_COUNT
  

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

  • GPU_TYPE: 上限を設定する GPU のタイプ（nvidia-l4 など）。
  • MINIMUM_GPU_COUNT: クラスタが持つことができる指定されたタイプの GPU の最小数。
  • MAXIMUM_GPU_COUNT: クラスタが使用できる指定されたタイプの GPU の最大数。

• TPU リソースの上限を指定します。

  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --min-cpu=MINIMUM_CPU \
      --min-memory=MINIMUM_MEMORY \
      --max-cpu=MAXIMUM_CPU \
      --max-memory=MAXIMUM_MEMORY \
      --min-accelerator=type=TPU_TYPE,count=MINIMUM_TPU_COUNT \
      --max-accelerator=type=TPU_TYPE,count=MAXIMUM_TPU_COUNT
  

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

  • TPU_TYPE: 制限を設定する TPU のタイプ。次の値を使用できます。
    • tpu-v4-podslice: TPU v4。
    • tpu-v5-lite-podslice: ct5lp- で始まるマシンタイプを使用する TPU v5e。
    • tpu-v5p-slice: ct5p- で始まるマシンタイプを使用する TPU v5e。
    • tpu-v6e-slice: TPU Trillium。
  • MINIMUM_TPU_COUNT: クラスタが持つことができる指定されたタイプの TPU チップの最小数。指定した値がマルチホスト TPU スライス内の TPU チップの数より大きい場合、TPU スライスがスケールダウンされないことがあります。
  • MAXIMUM_TPU_COUNT: クラスタに含めることができる指定されたタイプの TPU チップの最大数。マルチホスト TPU スライスの場合、GKE がスライスをアトミックにスケーリングできるように、各スライスのチップ数より大きい値を指定します。スライス内のチップの数は、TPU トポロジの積です。たとえば、トポロジが 2x2x2 の場合、スライスのチップ数は 8 です。つまり、MAXIMUM_TPU_COUNT の値は 8 より大きくする必要があります。

構成ファイル

1. 構成ファイルの resourceLimits フィールドで、次のフィールドのいずれかのセットを指定します。

   • CPU とメモリのリソース上限を指定します。

     resourceLimits:
       - resourceType: 'cpu'
         minimum: MINIMUM_CPU
         maximum: MAXIMUM_CPU
       - resourceType: 'memory'
         minimum: MINIMUM_MEMORY
         maximum: MAXIMUM_MEMORY
     

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

     • MINIMUM_CPU: クラスタの最小コア数。
     • MINIMUM_MEMORY: クラスタの最小メモリ容量（GiB）。
     • MAXIMUM_CPU: クラスタの最大コア数。この上限は、手動で作成されたノードプールを含む、クラスタ内のすべてのノードプールの CPU コア数の合計に適用されます。
     • MAXIMUM_MEMORY: クラスタの最大メモリ容量（GiB）。この上限は、手動で作成されたノードプールを含む、クラスタ内のすべてのノードプールのメモリ容量の合計に適用されます。

   • GPU リソースの上限を指定します。

     resourceLimits:
       - resourceType: 'cpu'
         minimum: MINIMUM_CPU
         maximum: MAXIMUM_CPU
       - resourceType: 'memory'
         minimum: MINIMUM_MEMORY
         maximum: MAXIMUM_MEMORY
       - resourceType: 'GPU1_TYPE'
         minimum: MINIMUM_GPU1_COUNT
         maximum: MAXIMUM_GPU1_COUNT
       - resourceType: 'GPU2_TYPE'
         minimum: MINIMUM_GPU2_COUNT
         maximum: MAXIMUM_GPU2_COUNT
     

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

     • GPU1_TYPE、GPU2_TYPE: 制限を設定する GPU のタイプ（nvidia-l4 など）。
     • MINIMUM_GPU1_COUNT、MINIMUM_GPU2_COUNT: クラスタが持つことができる指定されたタイプの GPU の最小数。
     • MAXIMUM_GPU1_COUNT、MAXIMUM_GPU2_COUNT: クラスタに含めることができる指定されたタイプの GPU の最大数。

   • TPU リソースの上限を指定します。

     resourceLimits:
       - resourceType: 'cpu'
         minimum: MINIMUM_CPU
         maximum: MAXIMUM_CPU
       - resourceType: 'memory'
         minimum: MINIMUM_MEMORY
         maximum: MAXIMUM_MEMORY
       - resourceType: 'TPU1_TYPE'
         minimum: MINIMUM_TPU1_COUNT
         maximum: MAXIMUM_TPU1_COUNT
       - resourceType: 'TPU2_TYPE'
         minimum: MINIMUM_TPU2_COUNT
         maximum: MAXIMUM_TPU2_COUNT
     

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

     • TPU1_TYPE、TPU2_TYPE: 制限を設定する TPU のタイプ。次の値を使用できます。
       • tpu-v4-podslice: TPU v4。
       • tpu-v5-lite-podslice: ct5lp- で始まるマシンタイプを使用する TPU v5e。
       • tpu-v5p-slice: ct5p- で始まるマシンタイプを使用する TPU v5e。
       • tpu-v6e-slice: TPU Trillium。
     • MINIMUM_TPU1_COUNT、MINIMUM_TPU2_COUNT: クラスタが持つことができる指定されたタイプの TPU チップの最小数。指定した値がマルチホスト TPU スライス内の TPU チップの数より大きい場合、TPU スライスがスケールダウンされないことがあります。
     • MAXIMUM_TPU1_COUNT、MAXIMUM_TPU2_COUNT: クラスタが持つことができる指定されたタイプの TPU チップの最大数。マルチホスト TPU スライスの場合、GKE がスライスをアトミックにスケーリングできるように、各スライスのチップ数よりも大きい値を指定します。スライス内のチップの数は、TPU トポロジの積です。たとえば、TPU1_TYPE のトポロジが 2x2x2 の場合、スライス内のチップの数は 8 です。つまり、MAXIMUM_TPU1_COUNT の値は 8 より大きくする必要があります。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

既存のノードプールを自動作成としてマークする

クラスタレベルのノード自動プロビジョニングを有効にすると、クラスタ内の既存のノードプールを自動作成としてマークできます。GKE は、これらのノードプールのスケーリングを管理します。これには、ノードプールが空になったときの削除も含まれます。手動で作成したノードプールを自動作成としてマークすると、GKE がノードプールを管理できるようになります。

クラスタの自動プロビジョニングを無効にすると、GKE はクラスタ内の既存の自動作成されたすべてのノードプールの管理を停止します。後でクラスタの自動プロビジョニングを再度有効にしても、GKE は既存のノードプールの管理を自動的に再開しません。これらの既存のノードプールを自動作成としてマークする必要があります。

既存のノードプールを自動作成としてマークするには、次のコマンドを実行します。

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-autoprovisioning

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

自動作成されたノードプールのデフォルト設定を構成する

GKE は、ComputeClass と Pod の仕様を使用して、保留中の Pod を最適に実行できるノードのタイプを決定します。必要に応じて、GKE が自動作成されたノードプールに適用するデフォルト設定（ノードのカスタム Identity and Access Management（IAM）サービス アカウントやカスタム ブートディスク構成など）を構成できます。これらのデフォルト設定は、Google がクラスタに設定する対応するデフォルト値をオーバーライドします。たとえば、自動作成されたノードプールのデフォルトとして Ubuntu ノードイメージを設定できます。これにより、GKE のデフォルトの Container-Optimized OS ノードイメージがオーバーライドされます。

クラスタレベルでノード自動プロビジョニングを使用するか、ComputeClass のワークロード レベルでデフォルト設定を構成できます。これらのレベルのいずれかで設定を構成する前に、次の点を考慮してください。

• クラスタレベルの設定はクラスタ内の自動作成されたノードプールに適用され、ComputeClass の設定はその ComputeClass を使用するワークロードにのみ適用されます。
• ComputeClass とクラスタレベルで同じデフォルト設定を指定した場合、GKE は ComputeClass を使用するワークロードに ComputeClass 設定を使用します。
• 構成したデフォルト値は、自動作成された新しいノードプールにのみ適用されます。既存のノードプールは影響を受けません。

以降のセクションでは、特定のデフォルト設定を構成する方法について説明します。

デフォルトのノードイメージを設定する

次のオプションのいずれかを選択します。

ComputeClass

1. ComputeClass マニフェストで、nodePoolConfig.imageType フィールドを使用します。このフィールドは、GKE バージョン 1.32.4-gke.1198000 以降で使用できます。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - machineFamily: n4
     - machineFamily: n4d
     nodePoolConfig:
       imageType: IMAGE_TYPE
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

   IMAGE_TYPE は、ノードイメージの値に置き換えます。次のいずれかの値になります。

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

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

コマンドラインでデフォルトのノードイメージを設定するには、--autoprovisioning-image-type フラグを使用します。

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

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

• CLUSTER_NAME: クラスタの名前。
• IMAGE_TYPE: ノードイメージ。次のいずれかになります。
  • cos_containerd: Containerd を含む Container-Optimized OS
  • ubuntu_containerd: Containerd を含む Ubuntu

構成ファイルでデフォルトのノードイメージを設定する手順は次のとおりです。

1. 構成ファイルで、imageType フィールドを指定します。

     imageType: 'IMAGE_TYPE'
   

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

ノードのデフォルトの IAM サービス アカウントを設定する

GKE ノードは、ロギングやモニタリングなどのシステムタスクに IAM サービス アカウントを使用します。自動作成されたノードプールの IAM サービス アカウントを変更するには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass マニフェストで nodePoolConfig.serviceAccount フィールドを使用します。このフィールドは、GKE バージョン 1.31.4-gke.1072000 以降で使用できます。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - machineFamily: n4
     - machineFamily: n4d
     nodePoolConfig:
       serviceAccount: SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

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

   • SERVICE_ACCOUNT_NAME: IAM サービス アカウントの名前（my-node-account など）。
   • PROJECT_ID: サービス アカウント プロジェクトのプロジェクト ID。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

gcloud CLI を使用して自動作成されたノードプールのデフォルト サービス アカウントを構成する場合は、ノードプールが正しく機能するために必要なアクセス スコープも指定する必要があります。

コマンドラインでデフォルトのサービス アカウントとアクセス スコープを設定するには、--autoprovisioning-service-account フラグと --autoprovisioning-scopes フラグを使用します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-autoprovisioning \
    --autoprovisioning-service-account=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --autoprovisioning-scopes=https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/trace.append

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

• SERVICE_ACCOUNT_NAME: IAM サービス アカウントの名前（my-node-account など）。
• PROJECT_ID: サービス アカウント プロジェクトのプロジェクト ID。

構成ファイルでデフォルトのサービス アカウントとアクセス スコープを設定する手順は次のとおりです。

1. 構成ファイルで、serviceAccount フィールドと scopes フィールドを指定します。

   serviceAccount: SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com
   scopes: https://www.googleapis.com/auth/devstorage.read_only,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/trace.append
   

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

自動作成されたノードのデフォルト ゾーンを設定する

デフォルトでは、GKE はクラスタのタイプに応じて次のゾーンにノードを自動的に作成します。

• リージョン クラスタ: GKE は、クラスタ リージョン内の 3 つのランダムなゾーンにノードを作成します。
• ゾーンクラスタ: GKE は、クラスタ コントロール プレーンと同じゾーンにノードを作成します。

GKE がノードを自動作成するゾーンのリストを手動で指定できます。これらのゾーンは、クラスタ コントロール プレーンと同じリージョンに存在する必要があります。たとえば、コントロール プレーンが us-central1-a にあるゾーンクラスタがある場合、GKE がノードを自動作成する us-central1 リージョンの任意のゾーンを指定できます。既存のクラスタで自動作成ノードのデフォルト ゾーンを変更した場合、変更は GKE が作成する新しいノードプールにのみ適用されます。

自動作成されたノードのデフォルト ゾーンを指定するには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass マニフェストで、spec.priorityDefaults.location.zones フィールドを使用します。このフィールドは、GKE バージョン 1.33.1-gke.1545000 以降で使用できます。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorityDefaults:
       location:
         zones: ['ZONE1','ZONE2','...']
     priorities:
     - machineFamily: n4
     - machineFamily: n4d
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

   ZONE1,ZONE2,... は、自動作成されたノードのデフォルト ゾーンのカンマ区切りリスト（us-central1-a','us-central1-b', 'us-central1-f' など）に置き換えます。spec.priorities フィールドの特定のルールにゾーンの明示的なリストが含まれていない場合、GKE はこれらのゾーンを使用します。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

コマンドラインでノードプールの自動作成のデフォルト ゾーンを設定するには、--autoprovisioning-locations フラグを使用します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-autoprovisioning \
    --autoprovisioning-locations=ZONE1,ZONE2,...

ZONE1,ZONE2,... は、自動作成されたノードのデフォルト ゾーンのカンマ区切りリスト（us-central1-a','us-central1-b', 'us-central1-f' など）に置き換えます。

構成ファイルを使用してノードプールの自動作成のデフォルト ゾーンを設定する手順は次のとおりです。

1. 構成ファイルで autoprovisioningLocations フィールドを指定します。

   autoprovisioningLocations:
   - ZONE1
   - ZONE2
   

   ZONE1、ZONE2 は、自動作成されたノードのデフォルト ゾーン（us-central1-a、us-central1-b など）に置き換えます。

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

ブートディスクの暗号化用に顧客管理の暗号鍵を設定する

GKE が自動作成されたノードプールのノードのブートディスクを暗号化するために使用する Cloud Key Management Service の顧客管理の暗号鍵（CMEK）を指定できます。ノードプールの自動作成で鍵を使用する前に、鍵を作成する必要があります。ノード ブートディスクの CMEK を設定するには、次のいずれかのオプションを選択します。

ComputeClass

ComputeClass では、ComputeClass の spec.priorities フィールドのすべての優先度ルールでキーを指定する必要があります。

1. ComputeClass マニフェストで priorities.storage.bootDiskKMSKey フィールドを使用します。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - machineFamily: n4
       storage:
         bootDiskKMSKey: projects/KEY_PROJECT_ID/locations/KEY_LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME
     - machineFamily: n4d
       storage:
         bootDiskKMSKey: projects/KEY_PROJECT_ID/locations/KEY_LOCATION/keyRings/KEY_RING/cryptoKeys/KEY_NAME
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

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

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

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

1. 構成ファイルで bootDiskKmsKey フィールドを指定します。

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

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

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

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

ノードの完全性とセキュアブートを構成する

自動作成されたノードプールでセキュアブートと整合性モニタリングを有効にするには、ノードの自動プロビジョニング構成ファイルを使用します。

1. 構成ファイルで shieldedInstanceConfig フィールドを指定します。

   shieldedInstanceConfig:
     enableSecureBoot: true
     enableIntegrityMonitoring: true
   

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

ノードの自動修復と自動アップグレードを構成する

自動作成されたノードプールで、ノードの自動修復とノードの自動アップグレードの設定を変更できます。これらの機能は、すべての GKE クラスタとノードプールでデフォルトで有効になっています。クラスタの信頼性と安定性を高めるため、これらの機能を有効にしておくことをおすすめします。

警告: クラスタがリリース チャンネルに登録されている場合に自動アップグレードを無効にすると、GKE が新しいノードプールの作成に失敗する可能性があります。

ノードの自動修復とノードの自動アップグレードの設定を変更するには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass マニフェストで、spec.nodePoolConfig フィールドの autoRepair フィールドと autoUpgrade フィールドを使用します。これらのフィールドは、GKE バージョン 1.34.0-gke.2201000 以降で使用できます。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     nodePoolConfig:
       autoRepair: true
       autoUpgrade: true
     priorities:
     - machineFamily: n4
     - machineFamily: n4d
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

• コマンドラインで自動修復と自動アップグレードの設定を有効にするには、--enable-autoprovisioning-autorepair フラグと --enable-autoprovisioning-autoupgrade フラグを使用します。

  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --enable-autoprovisioning \
      --enable-autoprovisioning-autorepair \
      --enable-autoprovisioning-autoupgrade
  

• コマンドラインで自動修復と自動アップグレードの設定を無効にするには、--no-enable-autoprovisioning-autorepair フラグと --no-enable-autoprovisioning-autoupgrade フラグを使用します。

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

• 構成ファイルを使用してノードの自動修復と自動アップグレードの設定を変更する手順は次のとおりです。

  1. 構成ファイルで management.autoRepair フィールドと management.autoUpgrade フィールドを指定します。

     management:
       autoRepair: true
       autoUpgrade: true
     

     構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

  2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

     gcloud container clusters create CLUSTER_NAME \
         --location=CONTROL_PLANE_LOCATION \
         --enable-autoprovisioning \
         --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
     

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

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

サージ アップグレードの設定を構成する

自動作成されたノードプールでサージ アップグレードの設定を指定できます。サージ アップグレードは、GKE のデフォルトのノード アップグレード戦略です。サージ アップグレードの設定を変更するには、クラスタレベルのノード自動プロビジョニングを構成する必要があります。

• コマンドラインでサージ アップグレード設定を指定するには、--autoprovisioning-max-surge-upgrade フラグと --autoprovisioning-max-unavailable-upgrade フラグを使用します。

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

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

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

• 構成ファイルを使用してサージ アップグレード設定を指定する手順は次のとおりです。

  1. 構成ファイルで upgradeSettings.maxSurgeUpgrade フィールドと upgradeSettings.maxUnavailableUpgrade フィールドを指定します。

     upgradeSettings:
       maxSurgeUpgrade: MAX_SURGE
       maxUnavailableUpgrade: MAX_UNAVAILABLE
     

     構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

  2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

     gcloud container clusters create CLUSTER_NAME \
         --location=CONTROL_PLANE_LOCATION \
         --enable-autoprovisioning \
         --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
     

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

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

指定したサージ アップグレード設定は、クラスタがサージ アップグレードを使用して自動作成されたノードプールをアップグレードする場合にのみ適用されます。新しく自動作成されたノードプールでノードのアップグレード戦略をサージ アップグレードに切り替えるには、次のコマンドを実行します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --enable-autoprovisioning \
    --enable-autoprovisioning-surge-upgrade

アップグレード戦略を切り替えると、GKE はそのアップグレード戦略用に以前に構成した設定を使用します。

自動作成された新しいノードプールに Blue/Green アップグレードを使用する

新しい自動作成されたすべてのノードプールのノード アップグレード戦略を Blue/Green アップグレードに切り替え、Blue/Green アップグレードのデフォルト設定を調整できます。アップグレード戦略を変更するには、クラスタレベルのノードの自動プロビジョニングを構成する必要があります。変更は、新しく自動作成されたノードプールにのみ適用されます。自動作成された既存のノードプールを更新して Blue/Green アップグレードを使用することもできます。

• Blue/Green アップグレードと、自動作成された新しいノードプールの GKE デフォルト設定を使用するには、次のコマンドを実行します。

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

• Blue/Green アップグレードを使用し、自動作成された新しいノードプールの独自のデフォルト設定を構成するには、次のコマンドを実行します。

  gcloud container clusters update CLUSTER_NAME \
      --location=CONTROL_PLANE_LOCATION \
      --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
  

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

  • NODE_POOL_SOAK_DURATION: Blue プール内のすべてのノードバッチをドレインしてから Blue プールを削除するまでの GKE の待機時間（秒）。デフォルト値は 3600 です。
  • BATCH_NODE_COUNT: Blue のプールドレイン フェーズでバッチにドレインするノードの数。デフォルト値は 1 です。0 の値を指定すると、GKE は Blue プールのドレイン フェーズをスキップします。
  • BATCH_SOAK_DURATION: 前のドレイン オペレーションが完了してから、GKE がバッチドレイン オペレーションを開始するまでの待機時間（秒単位）。デフォルト値は 0 です。

カスタムノードのブートディスクを構成する

GKE が自動作成されたノードプールの各ノード VM にアタッチするブートディスクのタイプとサイズを指定するには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass の spec.priorities.storage フィールドで bootDiskType フィールドと bootDiskSize フィールドを使用します。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - machineFamily: n4
       storage:
         bootDiskType: BOOT_DISK_TYPE
         bootDiskSize: BOOT_DISK_SIZE
     - machineFamily: n4d
       storage:
         bootDiskType: BOOT_DISK_TYPE
         bootDiskSize: BOOT_DISK_SIZE
     whenUnsatisfiable: ScaleUpAnyway
     nodePoolAutoCreation:
       enabled: true
   

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

   • BOOT_DISK_TYPE: ノードのブートディスクとして使用するディスクタイプ。指定する値は、GKE がその優先度ルールに使用する Compute Engine マシンタイプでサポートされている必要があります。値は次のいずれかにする必要があります。
     • pd-balanced: バランス永続ディスク。
     • pd-standard: 標準の Persistent Disk。
     • pd-ssd: パフォーマンス（SSD）Persistent Disk。
     • hyperdisk-balanced: Google Cloud Hyperdisk Balanced。
   • BOOT_DISK_SIZE: ノード ブートディスクのサイズ（GiB 単位）。最小値は 10 です。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

gcloud

1. 構成ファイルで、diskSizeGb フィールドと diskType フィールドを指定します。

   diskSizeGb: BOOT_DISK_SIZE
   diskType: BOOT_DISK_TYPE
   

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

   • BOOT_DISK_TYPE: ノードのブートディスクとして使用するディスクタイプ。指定する値は、GKE がその優先度ルールに使用する Compute Engine マシンタイプでサポートされている必要があります。値は次のいずれかにする必要があります。
     • pd-balanced: バランス永続ディスク。
     • pd-standard: 標準の Persistent Disk。
     • pd-ssd: パフォーマンス（SSD）Persistent Disk。
     • hyperdisk-balanced: Google Cloud Hyperdisk Balanced。
   • BOOT_DISK_SIZE: ノード ブートディスクのサイズ（GiB 単位）。最小値は 10 です。

   構成ファイルに他の設定がある場合は、それらの設定を変更しないでください。構成ファイルの変更や削除は、対応するクラスタレベルの設定にも反映されます。

2. 新しいクラスタまたは既存のクラスタの --autoprovisioning-config-file フラグと --enable-autoprovisioning フラグを指定して、構成ファイルを GKE に提供します。

   gcloud container clusters create CLUSTER_NAME \
       --location=CONTROL_PLANE_LOCATION \
       --enable-autoprovisioning \
       --autoprovisioning-config-file=PATH_TO_CONFIGURATION_FILE
   

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

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

GKE は、システム機能とエフェメラル ストレージ用にノード ブートディスクの一部を予約します。詳細については、ノード ブートディスクを基盤とするエフェメラル ストレージをご覧ください。

一般的なシナリオに合わせて自動作成されたノードプールを構成する

以降のセクションでは、一般的な GKE ユースケースで自動作成されたノードプールをリクエストする方法について説明します。その他のユースケースとサポートされている構成の詳細については、特定のユースケースのドキュメントをご覧ください。

マシンシリーズまたはマシンタイプを選択する

サポートされている Compute Engine マシンシリーズまたはマシンタイプを選択するには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass マニフェストの spec.priorities フィールドで、次のいずれかのフィールドを指定します。これらのフィールドは同じ ComputeClass マニフェストで指定できますが、同じ優先度ルールでは指定できません。

   • マシンシリーズを選択するには、優先度ルールの machineFamily フィールドを指定します。

     apiVersion: cloud.google.com/v1
     kind: ComputeClass
     metadata:
       name: COMPUTE_CLASS
     spec:
       priorities:
       - machineFamily: MACHINE_SERIES
       whenUnsatisfiable: ScaleUpAnyway
       nodePoolAutoCreation:
         enabled: true
     

     MACHINE_SERIES は、Compute Engine マシンシリーズ（n4 など）に置き換えます。

   • マシンタイプを選択するには、優先度ルールの machineType フィールドを指定します。

     apiVersion: cloud.google.com/v1
     kind: ComputeClass
     metadata:
       name: COMPUTE_CLASS
     spec:
       priorities:
       - machineType: MACHINE_TYPE
       whenUnsatisfiable: ScaleUpAnyway
       nodePoolAutoCreation:
         enabled: true
     

     MACHINE_TYPE は、Compute Engine マシンタイプ（c4-standard-96 など）に置き換えます。GKE バージョン 1.33.2-gke.1111000 以降では、このフィールドにカスタム マシンタイプを指定することもできます。

   同じ優先度ルールで machineFamily フィールドと machineType フィールドを指定することはできません。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

3. ワークロードで ComputeClass を選択します。

Pod の仕様

1. Pod マニフェストで、次のいずれかのノードラベルを選択します。

   • マシンシリーズを選択するには、cloud.google.com/machine-family ノードラベルを使用します。

     apiVersion: v1
     kind: Pod
     metadata:
       name: machine-series-pod
     spec:
       nodeSelector:
         cloud.google.com/machine-family: MACHINE_SERIES
       containers:
       - name: hello-app
         image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
     

     MACHINE_SERIES は、Compute Engine マシンシリーズ（n4 など）に置き換えます。

   • 事前定義されたマシンタイプを選択するには、cloud.google.com/machine-family ノードラベルと node.kubernetes.io/instance-type ノードラベルを使用します。

     apiVersion: v1
     kind: Pod
     metadata:
       name: machine-series-pod
     spec:
       nodeSelector:
         cloud.google.com/machine-family: MACHINE_SERIES
         node.kubernetes.io/instance-type: MACHINE_TYPE
       containers:
       - name: hello-app
         image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
     

     MACHINE_TYPE は、指定されたマシンシリーズの Compute Engine マシンタイプに置き換えます。たとえば、MACHINE_SERIES に n4 を指定した場合は、MACHINE_TYPE に n4-standard-80 を指定できます。

     GKE バージョン 1.33.2-gke.1111000 では、このフィールドにカスタム マシンタイプを指定することもできます。

2. Pod を作成します。

   kubectl apply -f PATH_TO_POD_MANIFEST
   

   PATH_TO_POD_MANIFEST は、Pod マニフェストのパスに置き換えます。

GPU を選択する

自動作成されたノードプールに GPU をリクエストするには、次のいずれかのオプションを選択します。

ComputeClass

1. ComputeClass マニフェストで、spec.priorities.gpu フィールドを指定します。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - gpu:
         type: GPU_TYPE
         count: GPU_COUNT
         driverVersion: DRIVER_VERSION
     whenUnsatisfiable: DoNotScaleUp
     nodePoolAutoCreation:
       enabled: true
   

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

   • GPU_TYPE: 接続する GPU のタイプ（nvidia-l4 など）。
   • GPU_COUNT: 各ノードに接続する GPU の数。この値は 1 以上にする必要があります。
   • DRIVER_VERSION: インストールする GPU ドライバのバージョン。この値は default または latest にする必要があります。このフィールドには、GKE バージョン 1.31.1-gke.1858000 以降が必要です。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

3. 次の例のように、GPU ワークロードで ComputeClass を選択します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-gpu-pod
   spec:
     nodeSelector:
       cloud.google.com/compute-class: nvidia-l4-class
     containers:
     - name: my-gpu-container
       image: nvidia/cuda:11.0.3-runtime-ubuntu20.04
       command: ["/bin/bash", "-c", "--"]
       args: ["while true; do sleep 600; done;"]
       resources:
         limits:
         nvidia.com/gpu: 1
   

Pod の仕様

Pod 仕様で GPU を選択するには、クラスタレベルのノード自動プロビジョニングを構成し、その GPU タイプのリソース上限を設定する必要があります。GPU リソースの上限を構成し、Pod で GPU を選択する手順は次のとおりです。

1. ノードプールの自動作成のリソース上限を構成するで説明されているように、使用する GPU のクラスタレベルのリソース上限を構成します。

2. Pod 仕様でノードラベルを使用して GPU を選択します。

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-gpu-pod
   spec:
     nodeSelector:
       cloud.google.com/gke-accelerator: GPU_TYPE
       cloud.google.com/gke-accelerator-count: GPU_COUNT
       cloud.google.com/gke-gpu-driver-version: DRIVER_VERSION
     containers:
     - name: my-gpu-container
       image: nvidia/cuda:11.0.3-runtime-ubuntu20.04
       command: ["/bin/bash", "-c", "--"]
       args: ["while true; do sleep 600; done;"]
       resources:
         limits:
         nvidia.com/gpu: GPU_QUANTITY
   

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

   • GPU_TYPE: 接続する GPU のタイプ（nvidia-l4 など）。
   • GPU_COUNT: 各ノードに接続する GPU の数。この値は 1 以上にする必要があります。
   • DRIVER_VERSION: インストールする GPU ドライバのバージョン。この値は default または latest にする必要があります。GKE バージョン 1.32.2-gke.1297000 以降では、GKE は default ドライバ バージョンを自動的にインストールします。このノードラベルには、GKE バージョン 1.29.2-gke.1108000 以降が必要です。詳細については、GPU を使用するノードの自動プロビジョニングによるドライバのインストールをご覧ください。
   • GPU_QUANTITY: Pod に接続する GPU の数。この値は、GPU_COUNT の値以下にする必要があります。

TPU を選択する

TPU は、ComputeClass または Pod 仕様でリクエストできます。このセクションでは、Cloud TPU の選択について理解しており、使用する TPU のタイプ、トポロジ、カウントがわかっていることを前提としています。実行する手順は、TPU の選択方法によって異なります。

• ComputeClasses: カスタム コンピューティング クラスを使用して TPU をプロビジョニングするをご覧ください。
• Pod 仕様:
  1. ノードプールの自動作成のリソース上限を構成するで説明されているように、使用する TPU のクラスタレベルのリソース上限を構成します。
  2. TPU スライスノードでワークロードを実行するで説明されているように、Pod 仕様でセレクタとリソース リクエストを構成します。

自動作成されたノードの実行時間を制限する

GKE が自動作成されたノードを終了するまでの最大期間を指定できます。この時間制限には Compute Engine の制限事項が適用されます。

次のオプションのいずれかを選択します。

ComputeClass

1. ComputeClass マニフェストで、spec.priorities.maxRunDurationSeconds フィールドを使用します。このフィールドは、GKE バージョン 1.32.1-gke.1159000 以降で使用できます。

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS
   spec:
     priorities:
     - machine-family: n4
       maxRunDurationSeconds: MAX_RUN_DURATION
     whenUnsatisfiable: DoNotScaleUp
     nodePoolAutoCreation:
       enabled: true
   

   MAX_RUN_DURATION は、GKE がノードを終了する前に自動作成されたノードが実行できる時間（秒単位）に置き換えます。

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

   kubectl apply -f PATH_TO_COMPUTECLASS_MANIFEST
   

   PATH_TO_COMPUTECLASS_MANIFEST は、ComputeClass マニフェスト ファイルのパスに置き換えます。

3. ワークロードで ComputeClass を選択します。

Pod の仕様

1. Pod マニフェストで、cloud.google.com/gke-max-run-duration-seconds ノードラベルのノードセレクタを使用します。このノードラベルは、GKE バージョン 1.31.2-gke.1518000 以降で使用できます。

   apiVersion: v1
   kind: Pod
   metadata:
     name: machine-series-pod
   spec:
     nodeSelector:
       cloud.google.com/machine-family: n4
       cloud.google.com/gke-max-run-duration-seconds: MAX_RUN_DURATION
     containers:
     - name: hello-app
       image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
   

   MAX_RUN_DURATION は、GKE がノードを終了する前に自動作成されたノードが実行できる時間（秒単位）に置き換えます。

2. Pod を作成します。

   kubectl apply -f PATH_TO_POD_MANIFEST
   

   PATH_TO_POD_MANIFEST は、Pod マニフェストのパスに置き換えます。

最小 CPU プラットフォームを指定する

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

ノードプールの自動作成を無効にする

以降のセクションでは、特定のノードプールまたはクラスタ全体のノードプールの自動作成を無効にする方法について説明します。ComputeClass の nodePoolAutoCreation.enabled フィールドに false の値を指定することで、ComputeClass でノードプールの自動作成を無効にすることもできます。ただし、ComputeClass の自動作成は、アクティブな移行やフォールバックの優先度などの機能を使用できる ComputeClass の主なメリットであるため、無効にすることはおすすめしません。

特定のノードプールの自動作成を無効にする

GKE が既存の自動作成されたノードプール内のノードを管理しないようにすることができます。このアクションには次の影響があります。

• クラスタ オートスケーラーは、そのノードプールでのノードの作成または削除を停止します。GKE でノードを自動スケーリングする場合は、そのノードプールのクラスタ オートスケーラーを個別に有効にすることができます。
• ノード数がゼロの場合、GKE はノードプールを削除しません。
• GKE は、そのノードプールで使用可能な既存のノードに保留中の Pod を引き続き配置します。クラスタでノード自動プロビジョニングが有効になっている場合、GKE は必要に応じて保留中の Pod 用に新しいノードプールを作成することもできます。

特定のノードプールの自動作成を無効にするには、次のコマンドを実行します。

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-autoprovisioning

クラスタのノード自動プロビジョニングを無効にする

ノードの自動プロビジョニング クラスタ設定を無効にすると、クラスタ全体のノードプールの自動作成を無効にできます。このアクションには次の影響があります。

• クラスタ オートスケーラーは、既存の自動作成されたノードプールでのノードの作成と削除を停止します。クラスタ オートスケーラーを使用する手動で作成されたノードプールは影響を受けません。
• GKE は、保留中のワークロード用に新しいノードプールを自動的に作成しません。クラスタをモニタリングして、Pod がスタックしないようにします。

• クラスタが次の要件を満たしている場合、GKE は自動作成を有効にする ComputeClass の新しいノードプールの作成を続行します。

  • GKE バージョン 1.33.3-gke.1136000 以降を使用します。
  • Rapid リリース チャンネルに登録されている。

  クラスタがこれらの要件を満たしていない場合、GKE は自動作成を有効にする ComputeClass の新しいノードプールを作成しません。

後でクラスタレベルのノード自動プロビジョニング設定を再度有効にしても、GKE は既存のノードプールでノードプールの自動作成を再度有効にしません。個々のノードプールを自動作成としてマークする必要があります。

クラスタレベルのノードの自動プロビジョニング設定を無効にするには、次のいずれかのオプションを選択します。

コンソール

1. Google Cloud コンソールで [Kubernetes クラスタ] ページに移動します。

   Kubernetes クラスタに移動

2. 変更するクラスタの名前をクリックします。[クラスタの詳細] ページが開きます。

3. [詳細] タブをクリックします。

4. [自動化] セクションの [ノード自動プロビジョニング] 行で、[編集] をクリックします。[ノード自動プロビジョニングの編集] ペインが表示されます。

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

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

gcloud

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --no-enable-autoprovisioning

次のステップ

• クラスタ オートスケーラーの詳細を理解する。
• ノードプールの詳細を理解する。
• ノードのアップグレード戦略の詳細を理解する。