このドキュメントでは、Standard Google Kubernetes Engine(GKE)クラスタでノードの自動プロビジョニングを使用する方法を説明します。このドキュメントを読む前に、ノードの自動プロビジョニングについて理解しておいてください。
始める前に
始める前に、次の作業が完了していることを確認してください。
- Google Kubernetes Engine API を有効にする。 Google Kubernetes Engine API の有効化
- このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、
gcloud components update
を実行して最新のバージョンを取得する。
要件
ノード自動プロビジョニングは次の GKE リリースで利用できます。
- バージョン 1.11.2-gke.25 以降(ゾーンクラスタ)。
- バージョン 1.12.x 以降(リージョン クラスタ)。
- バージョン 1.27.6 以降または 1.28 以降(Cloud TPU v4 と v5e の場合)。
- バージョン 1.28.7-gke.1020000 以降と 1.29.2-gke.1035000 以降(Cloud TPU v5p の場合)。
ノードの自動プロビジョニングを有効にする
クラスタの自動プロビジョニングは、gcloud CLI または Google Cloud コンソールを使用して有効にできます。
ノードの自動プロビジョニングには次のリソース制限があります。
ノードの IP アドレス範囲は慎重に計画する必要があります。クラスタの作成後に、ノードの IP アドレス範囲を拡張できます。ただし、新しい範囲を送信元として含めるようにファイアウォール ルールを更新する必要があるため、クラスタの作成後にノードの IP アドレス範囲を拡張しないことをおすすめします。ノードの自動プロビジョニングで不連続マルチ Pod CIDR を使用すると、Pod の IP アドレス範囲を拡張できます。
gcloud
ノード自動プロビジョニング機能を有効にするには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --min-cpu MINIMUM_CPU \ --min-memory MIMIMUM_MEMORY \ --max-cpu MAXIMUM_CPU \ --max-memory MAXIMUM_MEMORY \ --autoprovisioning-scopes=https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring,https://www.googleapis.com/auth/devstorage.read_only
次のように置き換えます。
CLUSTER_NAME
: ノード自動プロビジョニングを有効にするクラスタの名前。MINIMUM_CPU
: クラスタの最小コア数。MINIMUM_MEMORY
: クラスタの最小メモリ量(GB)。MAXIMUM_CPU
: クラスタの最大コア数。MAXIMUM_MEMORY
: クラスタの最大メモリ量(GB)。
次の例では、dev-cluster
でノードの自動プロビジョニングを有効にし、1 個の CPU と 1 GB のメモリから構成されるクラスタから、最大 10 個の CPU と 64 GB のメモリから構成されるクラスタまでのスケーリングを可能にしています。
gcloud container clusters update dev-cluster \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 1 \ --max-cpu 10 \ --max-memory 64
コンソール
ノードの自動プロビジョニングを有効にするには、次の操作を行います。
Google Cloud コンソールで 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-t4' maximum: 4 management: autoRepair: true autoUpgrade: true shieldedInstanceConfig: enableSecureBoot: true enableIntegrityMonitoring: true diskSizeGb: 100
自動プロビジョニングの構成ファイルを使用するには:
gcloud CLI からアクセスできる場所に、必要な構成のファイルを作成します。
次のコマンドを実行して、構成をクラスタに適用します。
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 OSubuntu_containerd
: Containerd を含む Ubuntu
ファイル
新しく自動プロビジョニングされたすべてのノードプールについて、使用するノードイメージ タイプを構成ファイルで指定できます。次の YAML 構成では、新しく自動プロビジョニングされたノードプールに対して、イメージタイプが cos_containerd
であり、CPU とメモリのリソース上限を関連付けていることを指定しています。自動プロビジョニングを有効にするには、CPU とメモリの最大値を指定する必要があります。
YAML 構成を保存します。
resourceLimits: - resourceType: 'cpu' minimum: 4 maximum: 10 - resourceType: 'memory' maximum: 64 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 CLI がアクセスできる場所に、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 CLI からアクセスできる場所に 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 CLI からアクセスできる場所にあるファイルにコピーします。
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 CLI からアクセスできる場所にあるファイルにコピーします。
autoUpgrade
とautoRepair
の値を編集します。ファイルを保存します。次のコマンドを実行して、構成をクラスタに適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルの名前。
自動プロビジョニングされた新しいノードプールにサージ アップグレードを使用する
gcloud CLI または構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールでサージ アップグレードの設定を指定できます。GKE のデフォルトでは、ノードのアップグレード戦略がサージ アップグレードに設定されます。
gcloud
自動プロビジョニングされた新しいすべてのノードプールに対してサージ アップグレードを指定するには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-max-surge-upgrade MAX_SURGE \ --autoprovisioning-max-unavailable-upgrade MAX_UNAVAILABLE
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。MAX_SURGE
: アップグレード中にノードプールに追加できるノードの最大数。MAX_UNAVAILABLE
: アップグレード中に同時に使用不可になることが許容される、ノードプール内のノードの最大数。
ファイル
次のように、構成ファイルを使用して、新しく自動プロビジョニングされたすべてのノードプールのサージ アップグレード設定を指定できます。
upgradeSettings: maxSurgeUpgrade: 1 maxUnavailableUpgrade: 2
自動プロビジョニングの構成ファイルを使用するには:
gcloud
からアクセス可能な場所にあるファイルに上記の構成をコピーします。maxSurgeUpgrade
とmaxUnavailableUpgrade
の値を編集します。ファイルを保存します。次のコマンドを実行して、構成をクラスタに適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルの名前。
詳細については、gcloud container clusters update
のドキュメントをご覧ください。
新しく自動プロビジョニングされたノードプールでサージ アップグレードを使用するように戻すには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --enable-autoprovisioning-surge-upgrade
CLUSTER_NAME
はクラスタの名前で置き換えます。
前のコマンドと同様に、特定の設定に対するフラグを指定することもできます。設定されている場合、GKE は以前の構成をアップグレード戦略に再利用します。
自動プロビジョニングされた新しいノードプールに Blue/Green アップグレードを使用する
gcloud CLI を使用すると、新しく自動プロビジョニングされたすべてのノードプールに Blue/Green アップグレードを使用できます。Blue/Green アップグレードでは、デフォルト設定を使用できます。または、環境に合わせて最適化されるように設定することもできます。Blue/Green アップグレードの詳細については、Blue/Green アップグレードをご覧ください。
既存の自動プロビジョニングされたノードプールのノード アップグレード戦略を更新するには、既存のノードプールのサージ アップグレードをオンまたはオフにすると既存のノードプールの Blue/Green アップグレード戦略の更新をご覧ください。
後述するコマンドでは、次の変数を使用しています。
CLUSTER_NAME
: ノードプールのクラスタの名前。COMPUTE_ZONE
: クラスタのゾーン。NODE_POOL_NAME
: ノードプールの名前。NUMBER_NODES
: クラスタの各ゾーンにあるノードプール内のノード数。BATCH_NODE_COUNT
: Blue のプールドレイン フェーズでバッチにドレインする Blue ノードの数。デフォルトは 1 です。0 に設定した場合、Blue のプールドレイン フェーズはスキップされます。BATCH_PERCENT
: Blue のプールドレイン フェーズでバッチにドレインする Blue ノードの割合。[0.0, 1.0] の範囲内にしてください。BATCH_SOAK_DURATION
: 各バッチドレインの後に待機する時間(秒)。デフォルトは 0 です。NODE_POOL_SOAK_DURATION
: すべてのバッチのドレインが完了した後に待機する時間(秒)。デフォルトは 3,600 秒です。
Blue/Green アップグレードのデフォルトの設定は次のとおりです。
BATCH_NODE_COUNT
= 1BATCH_SOAK_DURATION
= 0 秒NODE_POOL_SOAK_DURATION
= 3,600 秒(1 時間)
自動プロビジョニングされた新しいノードプールに Blue/Green アップグレードを使用するようにクラスタを更新する
次のコマンドは、gcloud container clusters
update
を使用して、新しく自動プロビジョニングされたノードプールに対してノードのアップグレード戦略を更新します。
これらのフラグは、次の場合にも使用できます。
gcloud container clusters create
コマンドを使用して、ノードの自動プロビジョニングを有効にしてクラスタを作成する。gcoud container clusters update
コマンドを使用して、ノードの自動プロビジョニングを有効にする。
自動プロビジョニングされた新しいノードプールのデフォルト設定で Blue/Green アップグレードを使用するようにクラスタを更新するには、次のコマンドを使用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --enable-autoprovisioning-blue-green-upgrade
自動プロビジョニングされた新しいノードプールに特定の設定で Blue/Green アップグレードを使用するようにクラスタを更新できます。これらのコマンドは、--enable-autoprovisioning-blue-green-upgrade
フラグなしで使用して設定を更新することもできます。
次のコマンドは、BATCH_NODE_COUNT
を使用して絶対ノード数のバッチサイズを設定します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --enable-autoprovisioning-blue-green-upgrade \ --autoprovisioning-node-pool-soak-duration=NODE_POOL_SOAK_DURATION \ --autoprovisioning-standard-rollout-policy=batch-node-count=BATCH_NODE_COUNT,batch-soak-duration=BATCH_SOAK_DURATION
また、BATCH_PERCENT
を使用して割合ベースのバッチサイズを設定することもできます。最後のコマンドの batch-node-count
は batch-percent
に置き換え、0~1 の小数を使用します(例: 25% は 0.25
)。割合ベースのバッチサイズの設定方法については、割合ベースのバッチサイズを使用して Blue/Green アップグレードでノードプールを更新するをご覧ください。
カスタム ブートディスク
ノード自動プロビジョニングは、カスタム ブートディスクを使用したノードプールの作成をサポートします。
構成ファイルを使用してブートディスクの設定をカスタマイズできます。GKE は、kubelet 関数用にノード ブートディスクの一部を予約します。詳細については、ノード ブートディスクを基盤とするエフェメラル ストレージをご覧ください。
次の YAML 構成では、ノードの自動プロビジョニングによって 100 GB の SSD ディスクで構成されるノードプールが作成されます。
diskSizeGb: 100 diskType: pd-ssd
以下を指定します。
diskSizeGb
: ディスクのサイズ(GB)。diskType
: ディスクのタイプ。次のいずれかの値になります。pd-balanced
(デフォルト)pd-standard
pd-ssd
。 GKE バージョン 1.22 以前では、pd-ssd
を指定すると、ノードの自動プロビジョニングはノードプールの作成時に N1 マシンタイプのみを考慮します。
自動プロビジョニングの構成ファイルを使用するには:
gcloud CLI がアクセスできる場所に、目的のブートディスク構成を持つファイルを作成します。
次のコマンドを実行して、構成をクラスタに適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルの名前。
GKE マネージド Pod をワークロードから分離する
クラスタ管理者は、GKE が管理する Pod をワークロードから分離できます。この分離により、システム Pod が実行されている使用率の低いノードがクラスタにある場合に、スケールダウンの問題を回避できます。
次の例は、ノードの自動プロビジョニングと Kubernetes の taint と Toleration を組み合わせて、マネージド Pod をワークロードから分離する方法を示しています。
e2-standard-2
VM のデフォルト ノードプールを持つクラスタを作成し、それらのノードでのみ GKE システム ワークロードを実行できるようにノード taint を適用します。gcloud container clusters create test-cluster \ --machine-type=e2-standard-2 \ --node-taints=components.gke.io/gke-managed-components=true:NoSchedule
クラスタのノードの自動プロビジョニングを有効にします。
gcloud container clusters update test-cluster \ --enable-autoprovisioning \ --min-cpu 1 \ --min-memory 1 \ --max-cpu 10 \ --max-memory 64
クラスタは、クラスタの合計サイズを 1 CPU と 1 GB のメモリから、最大 10 CPU と 64 GB のメモリまでスケーリングできます。
この構成をテストするには、次のサンプル マニフェストを
nginx.yaml
として保存します。apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent tolerations: - key: dedicated operator: Equal value: ui-team effect: NoSchedule nodeSelector: dedicated: ui-team
このマニフェストは、
nodeSelector
ラベルとdedicated: ui-team
のノード taint を設定したクラスタにテスト ワークロード Pod をデプロイします。ノードの自動プロビジョニング機能を使用しない場合、ノードプールに適切なラベルと taint がないため、このワークロード Pod をスケジュールできません。マニフェストをクラスタに適用します。
kubectl apply -f nginx.yaml
出力は次のようになります。
pod/nginx created
ui-team
ラベルに適合する新しいノードプールを確認します。kubectl get node --selector=dedicated=ui-team
出力は次のようになります。
NAME STATUS ROLES AGE VERSION gke-test-nap-e2-medium-14b723z1-19f89fa8-jmhr Ready <none> 14s v1.21.11-gke.900
クラスタは、ワークロードをマネージド GKE Pod から分離します。
自動プロビジョニングされた新しいノードプールにアクセラレータを使用する
ノードの自動プロビジョニングを有効にして、GPU または Cloud TPU アクセラレータを自動的にプロビジョニングするように GKE を構成すると、AI / ML ワークロードのスケジューリングに必要な容量を確保できます。
GPU の上限の構成
ノードの自動プロビジョニングで GPU で使用する場合、gcloud CLI または Google Cloud コンソールを使用して、クラスタ内の各 GPU タイプに上限を設定できます。GPU の上限数は GPU の最大数です。たとえば、GPU が 16 個の VM は、この上限では 1 個ではなく 16 個としてカウントされます。複数のタイプの GPU を構成するには、構成ファイルを使用する必要があります。
使用可能な resourceTypes の一覧を取得するには、gcloud compute accelerator-types list
を実行します。
gcloud
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --max-cpu MAXIMUM_CPU \ --max-memory MAXIMUM_MEMORY \ --min-accelerator type=GPU_TYPE,count=MINIMUM_ACCELERATOR \ --max-accelerator type=GPU_TYPE,count=MAXIMUM_ACCELERATOR
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。MAXIMUM_CPU
: クラスタの最大コア数。MAXIMUM_MEMORY
: クラスタの最大メモリ量(GB)。GPU_TYPE
: GPU タイプ。MINIMUM_ACCELERATOR
: クラスタ内の GPU アクセラレータの最小数。MAXIMUM_ACCELERATOR
: クラスタ内の GPU アクセラレータの最大数。
次の例では、dev-cluster
クラスタ内の nvidia-tesla-t4
GPU アクセラレータに GPU の上限を設定しています。
gcloud container clusters update dev-cluster \ --enable-autoprovisioning \ --max-cpu 10 \ --max-memory 64 \ --min-accelerator type=nvidia-tesla-t4,count=1 \ --max-accelerator type=nvidia-tesla-t4,count=4
ファイル
構成ファイルを使用すると、複数のタイプの GPU の上限を読み込むことが可能です。 次の YAML 構成では、2 種類の GPU を設定しています。
resourceLimits: - resourceType: 'cpu' minimum: 4 maximum: 10 - resourceType: 'memory' maximum: 64 - resourceType: 'nvidia-tesla-t4' maximum: 4 - resourceType: 'nvidia-tesla-v100' maximum: 2
自動プロビジョニングの構成ファイルを使用するには:
上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。
cpu
とmemory
の値を編集します。resourceType
の値を必要な数だけ追加します。ファイルを保存します。次のコマンドを実行して、構成をクラスタに適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルの名前。
詳細については、gcloud container clusters update
のドキュメントをご覧ください。
コンソール
GPU リソースでノードの自動プロビジョニングを有効にするには、次の操作を行います。
Google Cloud コンソールで Google Kubernetes Engine のページに移動します。
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[
編集] をクリックします。[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの CPU とメモリの最小使用量と最大使用量を設定します。
[
リソースの追加] をクリックします。追加する GPU のタイプ(NVIDIA T4 など)を選択します。クラスタに追加する GPU の最小数と最大数を設定します。
GKE で GPU の制限事項に同意します。
[変更を保存] をクリックします。
インストールするドライバのバージョンを選択する
GKE バージョン 1.29.2-gke.1108000 以降では、自動プロビジョニングされた GPU ノードに自動的にインストールする、GKE の GPU ドライバ バージョンを選択できます。マニフェストに次のフィールドを追加します。
spec:
nodeSelector:
cloud.google.com/gke-gpu-driver-version: "DRIVER_VERSION"
DRIVER_VERSION
は次のいずれかの値に置き換えます。
default
- ノードの GKE バージョンに対応するデフォルトの安定版ドライバ。マニフェストで nodeSelector を省略した場合、これがデフォルトのオプションになります。latest
- ノードの GKE バージョンに対応する最新のドライバ バージョン。
Cloud TPU の構成
GKE バージョン 1.28 以降では、Cloud TPU でノードの自動プロビジョニングを使用できます。ただし、v5p はノードの自動プロビジョニングとクラスタの自動スケーリングでサポートされていません。TPU でのノードの自動プロビジョニングの仕組みについて詳しくは、サポートされている ML アクセラレータをご覧ください。
gcloud CLI を使用してクラスタを作成し、Pod が TPU リソースを使用するように構成します。複数のタイプの TPU を構成するには、構成ファイルを使用する必要があります。
gcloud
クラスタを作成して TPU の上限を定義します。
gcloud container clusters create CLUSTER_NAME \ --enable-autoprovisioning \ [--min-cpu MINIMUM_CPU ] \ --max-cpu MAXIMUM_CPU \ [--min-memory MINIMUM_MEMORY ] \ --max-memory MAXIMUM_MEMORY \ [--min-accelerator=type=TPU_TYPE,count= MINIMUM_ACCELERATOR ] \ --max-accelerator=type=TPU_TYPE,count= MAXIMUM_ACCELERATOR
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。MINIMUM_CPU
: クラスタの最小 vCPU 数。MAXIMUM_CPU
: クラスタの最大 vCPU 数。MINIMUM_MEMORY
: クラスタの最小メモリ量(GB)。MAXIMUM_MEMORY
: クラスタの最大メモリ量(GB)。TPU_TYPE
: 選択する TPU のタイプ。TPU v4 を選択する場合は、tpu-v4-podslice
を使用します。マシンタイプがct5lp-
で始まる TPU v5e を選択する場合は、tpu-v5-lite-podslice
を使用します。マシンタイプがct5l-
で始まる TPU v5e を選択する場合は、tpu-v5-lite-device
を使用します。MINIMUM_ACCELERATOR
: クラスタ内の TPU チップの最小数。MINIMUM_ACCELERATOR
を使用すると、count
がスライス内の TPU チップの数より少ない場合でも、マルチホスト TPU スライスのスケールダウンがブロックされる可能性があります。
MAXIMUM_ACCELERATOR
: クラスタ内の TPU チップの最大数。- Pod 構成でマルチホスト TPU スライスがリクエストされた場合、GKE は対象のスライスをアトミックに作成します。指定したトポロジのすべての TPU チップをプロビジョニングできるよう十分に高いカウント値を設定します。各 TPU スライス内のチップの数は、トポロジの積に等しくなります。たとえば、マルチホスト TPU スライスのトポロジが
2x2x2
の場合、TPU チップの数は8
に等しいため、MAXIMUM_ACCELERATOR
は 8 より大きくする必要があります。
- Pod 構成でマルチホスト TPU スライスがリクエストされた場合、GKE は対象のスライスをアトミックに作成します。指定したトポロジのすべての TPU チップをプロビジョニングできるよう十分に高いカウント値を設定します。各 TPU スライス内のチップの数は、トポロジの積に等しくなります。たとえば、マルチホスト TPU スライスのトポロジが
次の例では、
dev-cluster
クラスタ内のct5lp-hightpu-1t
、ct5lp-hightpu-4t
、ct5lp-hightpu-8t
のマシンタイプに TPU の上限を設定しています。たとえば、それぞれ 4 個の TPU チップ、112 個の vCPU、192 GiB のメモリを搭載したct5lp-hightpu-4t
マシンを最大 10 個までプロビジョニングできます。gcloud container clusters create dev-cluster-inference \ --enable-autoprovisioning \ --min-cpu 0 \ --max-cpu 1120 \ --min-memory 0 \ --max-memory 1920 \ --min-accelerator=type=tpu-v5-lite-podslice,count=0 \ --max-accelerator=type=tpu-v5-lite-podslice,count=40
Pod が TPU リソースをリクエストする Deployment 仕様を作成します。たとえば、次のマニフェストでは、GKE が 4 つの
ct5lp-hightpu-4t
ノードをプロビジョニングします。apiVersion: apps/v1 kind: Deployment metadata: name: tpu-workload labels: app: tpu-workload spec: replicas: 4 selector: matchLabels: app: nginx-tpu template: metadata: labels: app: nginx-tpu spec: nodeSelector: cloud.google.com/gke-tpu-accelerator: tpu-v5-lite-podslice cloud.google.com/gke-tpu-topology: 2x2 cloud.google.com/reservation-name: my-reservation containers: - name: nginx image: nginx:1.14.2 resources: requests: google.com/tpu: 4 limits: google.com/tpu: 4 ports: - containerPort: 80
nodeSelector
フィールドで、TPU タイプ、TPU トポロジ、アクセラレータ数を定義します。ここで、cloud.google.com/gke-tpu-accelerator
: TPU タイプを定義します。例:tpu-v4-podslice
cloud.google.com/gke-tpu-topology
: TPU トポロジを定義します(例:2x2x1
または4x4x8
)。
ワークロードで既存の予約を消費するには、
nodeSelector
フィールドに追加のラベルを指定します。 *cloud.google.com/reservation-name
: GKE がノードの自動プロビジョニングに使用する予約の名前を定義します。limits: google.com/tpu
で、ノードあたりの TPU チップの数を定義します。
ファイル
構成ファイルを使用して、複数のタイプの TPU に上限を割り当てることができます。次の YAML 構成では、2 種類の TPU を構成しています。
resourceLimits: - resourceType: 'cpu' maximum: 10000 - resourceType: 'memory' maximum: 10000 - resourceType: 'tpu-v4-podslice' maximum: 32 - resourceType: 'tpu-v5-lite' maximum: 64
自動プロビジョニングの構成ファイルを使用するには:
上記の構成を、gcloud CLI からアクセスできる場所にあるファイルにコピーします。
resourceType
とmaximum
の値を編集します。resourceType
の値を必要な数だけ追加します。ファイルを保存します。次のコマンドを実行して、構成をクラスタに適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルの名前。
詳細については、gcloud container clusters update
のドキュメントをご覧ください。
ノード自動プロビジョニングのロケーション
ノードの自動プロビジョニングで新しいノードプールを作成できるゾーンを設定します。リージョンのロケーションはサポートされていません。ゾーンは、クラスタと同じリージョンに属している必要がありますが、クラスタレベルで定義されているノードの場所には限定されません。ノードの自動プロビジョニングの場所を変更しても、既存のノードプールに影響はありません。
ノードの自動プロビジョニングで新しいノードプールを作成できるロケーションを設定するには、gcloud CLI または構成ファイルを使用します。
gcloud
次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning --autoprovisioning-locations=ZONE
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。ZONE
: ノード自動プロビジョニングで新しいノードプールを作成できるゾーン。複数のゾーンを指定するには、各ゾーンをカンマで区切ります(例:ZONE1, ZONE2,...
)。
ファイル
ノードの自動プロビジョニングで新しいノードプールを作成できるロケーションを設定するには、構成ファイルを使用します。
次の YAML 構成を追加して、新しいノードプールのロケーションを設定します。
autoprovisioningLocations:
- ZONE
ZONE
は、ノード自動のプロビジョニングで新しいノードプールを作成できるゾーンに置き換えます。複数のゾーンを指定するには、リストにゾーンを追加します。ファイルを保存します。
自動プロビジョニングの構成ファイルを使用するには:
gcloud CLI
がアクセスできるロケーションに構成ファイルを作成します。クラスタに構成ファイルを適用します。
gcloud container clusters update CLUSTER_NAME \ --enable-autoprovisioning \ --autoprovisioning-config-file FILE_NAME
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前。FILE_NAME
: 構成ファイルのパス。
コンパクト プレースメントにより物理的に近接したノード
GKE バージョン 1.25 以降では、ノードの自動プロビジョニングでコンパクト プレースメント ポリシーがサポートされています。コンパクト プレースメント ポリシーを使用すると、ゾーン内で相互により近接したノードプールを作成するよう GKE に指示できます。
コンパクト プレースメント ポリシーを定義するには、次のキーを使用して nodeSelector
を Pod 仕様に追加します。
cloud.google.com/gke-placement-group
は、同じコンパクト プレースメント グループ内でともに実行する必要がある Pod のグループに割り当てる識別子です。cloud.google.com/machine-family
はマシン ファミリー名です。詳細については、コンパクト プレースメントをサポートするマシン ファミリーをご覧ください。
次の例では、プレースメント グループ ID が placement-group-1
、マシン ファミリーが c2
のコンパクト プレースメント ポリシーを設定します。
apiVersion: v1
kind: Pod
metadata:
...
spec:
...
nodeSelector:
cloud.google.com/gke-placement-group: placement-group-1
cloud.google.com/machine-family: c2
詳細については、GKE ノードのコンパクト プレースメントを定義する方法をご覧ください。
ノード自動プロビジョニング機能を無効にする
特定のクラスタのノード自動プロビジョニング機能を無効にすると、ノードプールが自動プロビジョニングされなくなります。
gcloud
クラスタのノードの自動プロビジョニングを無効にするには、次のコマンドを実行します。
gcloud container clusters update CLUSTER_NAME \ --no-enable-autoprovisioning
CLUSTER_NAME
は、使用するクラスタの名前に置き換えます。
ファイル
Google Cloud コンソールを使用してノードの自動プロビジョニングを無効にするには:
Google Cloud コンソールで 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 プラットフォームは、ワークロード レベル(推奨)またはクラスタレベルで指定できます。