このページでは、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
リモート サーバーで SSH を使用している場合は、
--console-only
フラグを指定して、コマンドがブラウザを起動しないようにします。gcloud init --console-only
- Google Cloud アカウントを使用できるように、gcloud CLI の承認手順を行います。
- 新しい構成を作成するか、既存の構成を選択します。
- Google Cloud プロジェクトを選択します。
- デフォルトの Compute Engine ゾーンを選択します。
- デフォルトの Compute Engine リージョンを選択します。
- デフォルトのプロジェクト 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 init
gcloud config
デフォルトの場所を設定することで、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 のページに移動します。
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[
編集] をクリックします。[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの 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 OScos
: Docker を含む Container-Optimized OSubuntu_containerd
: Containerd を含む Ubuntuubuntu
: 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 のページに移動します。
クラスタの名前をクリックします。
[自動化] セクションの [ノードの自動プロビジョニング] で、[
編集] をクリックします。[ノードの自動プロビジョニングを有効にする] チェックボックスをオンにします。
クラスタの 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 のページに移動します。
クラスタの名前をクリックします。
[自動化] の [ノードの自動プロビジョニング] で、[
編集] をクリックします。[ノードの自動プロビジョニングを有効にする] チェックボックスをオフにします。
[保存] をクリックします。
ノードプールを「自動プロビジョニングあり」とマークする
クラスタでノードの自動プロビジョニングを有効にすると、自動プロビジョニングするノードプールを指定できます。ワークロードが使用されていない場合、自動プロビジョニングされたノードプールは自動的に削除されます。
ノードプールを自動プロビジョニングとしてマークするには、次のコマンドを実行します。
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
: 構成ファイルの名前。