コンパクト プレースメント ポリシーを使用して、Google Kubernetes Engine(GKE)ノードをゾーン内で相互に相対的に配置するかどうかを制御できます。
概要
GKE クラスタにノードプールとワークロードを作成するときには、コンパクト プレースメント ポリシーを定義できます。このポリシーでは、これらのノードまたはワークロードを互いにゾーン内の物理的に近い場所に配置するように指定できます。ノードを近づけることで、ノード間のネットワーク レイテンシが短縮されます。これは、密結合のバッチ ワークロードに特に役立ちます。
GKE Autopilot でコンパクト プレースメントを使用する
制限事項
- GKE では、同じゾーンのコンパクト プレースメント内でワークロードがプロビジョニングされます。
- コンパクト プレースメントは、
Balanced
と A100 GPU で使用できます。詳細については、マシンタイプをご覧ください。 - コンパクト プレースメントは、最大 150 個のノードでグループ化された Pod で使用できます。
- ノードのライブ マイグレーションはサポートされません。
コンパクト プレースメント ポリシーを有効にする
GKE Autopilot のコンパクト プレースメントを有効にするには、次のキーを使用して nodeSelector
を Pod 仕様に追加します。
cloud.google.com/gke-placement-group
は、同じコンパクト プレースメント グループ内で一緒に実行される Pod のグループに割り当てる識別子です。リソースのタイプを定義する次のいずれかのキー。
cloud.google.com/compute-class: "Balanced"
cloud.google.com/gke-accelerator: "nvidia-tesla-a100"
次の例は、コンパクト プレースメントを有効にする Pod 仕様の一部です。プレースメント グループ ID は placement-group-1
で、コンピューティング クラスは Balanced
です。
nodeSelector:
cloud.google.com/gke-placement-group: "placement-group-1"
cloud.google.com/compute-class: "Balanced"
各プレースメント グループのノード数は 150 に制限されています。プレースメント グループは、グループ化するとメリットが得られるワークロードのみに制限し、可能であれば、ワークロードを別々のプレースメント グループに分散することをおすすめします。
GKE Standard でコンパクト プレースメントを使用する
制限事項
GKE Standard ノードプールのコンパクト プレースメントには、次の制限があります。
- 新しいノードプールでのみサポートされます。既存のノードプールでコンパクト プレースメントを有効または無効にすることはできません。
- 単一ゾーンで動作するノードプールでのみ使用できます。
- A2、C2、G2、C2D、C3D、N2、N2D、C3 マシンタイプでのみ使用できます。
- 各ポリシーで最大 150 個の Compute Engine VM インスタンスをサポートします。この上限を超えるノードプールは作成中に拒否されます。
- ノードのライブ マイグレーションはサポートされません。
- Blue / Green アップグレードでは、
placement-policy
フラグを使用してカスタム リソース ポリシーを指定することはサポートされていません。
コンパクト プレースメント ポリシーを作成する
Google Cloud CLI でコンパクト プレースメント ポリシーを作成するには、ノードプールまたはクラスタの作成時に placement-type=COMPACT
オプションを指定します。この設定により、GKE はノードプール内でノードを物理的に近い場所に配置しようとします。
クラスタで既存のリソース ポリシーを使用するには、ノードプールまたはクラスタの作成時に、placement-policy
フラグにカスタム ポリシーのロケーションを指定します。これにより、予約済みプレースメント、同じプレースメント ポリシーを持つ複数のノードプール、その他の高度なプレースメント オプションを柔軟に使用できます。ただし、--placement-type=COMPACT フラグを指定する場合よりも多くの手動操作が必要になります。たとえば、カスタム リソース ポリシーを作成、削除、維持する必要があります。リソース ポリシーを使用して、すべてのノードプールで VM インスタンスの最大数が遵守されるようにします。この上限に達し、一部のノードプールがその最大サイズに達していない場合、ノードの追加は失敗します。
placement-type
フラグと placement-policy
フラグを指定しない場合、デフォルトではノードのプレースメントに関する要件はありません。
新しいクラスタにコンパクト プレースメント ポリシーを作成する
新しいクラスタを作成するときに、デフォルトのノードプールに適用されるコンパクト プレースメント ポリシーを指定できます。クラスタに作成する後続のノードプールがある場合は、コンパクト プレースメントを適用するかどうかを指定する必要があります。
デフォルトのノードプールにコンパクト プレースメント ポリシーが適用された新しいクラスタを作成するには、次のコマンドを使用します。
gcloud container clusters create CLUSTER_NAME \
--machine-type MACHINE_TYPE \
--placement-type COMPACT \
--max-surge-upgrade 0 \
--max-unavailable-upgrade MAX_UNAVAILABLE
次のように置き換えます。
CLUSTER_NAME
: 新しいクラスタの名前。MACHINE_TYPE
: ノードに使用するマシンのタイプ。C2 マシンタイプ(c2-standard-4
など)にする必要があります。--placement-type COMPACT
: デフォルトのノードプール内のノードにコンパクト プレースメントを適用します。MAX_UNAVAILABLE
: ノードプールのアップグレード中に同時に使用できないノードの最大数。コンパクト プレースメントには、アップグレード中に同じ場所に配置されたノードを検出する可能性を最適化するため、高速、サージ アップグレードなしをおすすめします。
既存のクラスタにコンパクト プレースメント ポリシーを作成する
既存のクラスタでは、コンパクト プレースメント ポリシーが適用されたノードプールを作成できます。
コンパクト プレースメント ポリシーが適用されたノードプールを作成するには、次のコマンドを使用します。
gcloud container node-pools create NODEPOOL_NAME \
--machine-type MACHINE_TYPE \
--cluster CLUSTER_NAME \
--placement-type COMPACT \
--max-surge-upgrade 0 \
--max-unavailable-upgrade MAX_UNAVAILABLE
次のように置き換えます。
NODEPOOL_NAME
: 新しいノードプールの名前。MACHINE_TYPE
: ノードに使用するマシンのタイプ。C2 マシンタイプ(c2-standard-4
など)にする必要があります。CLUSTER_NAME
: 既存のクラスタの名前。--placement-type COMPACT
: 新しいノードプール内のノードにコンパクト プレースメントを適用することを示します。MAX_UNAVAILABLE
: ノードプールのアップグレード中に同時に使用できないノードの最大数。コンパクト プレースメントには、アップグレード中に同じ場所に配置されたノードを検出する可能性を最適化するため、高速、サージ アップグレードなしをおすすめします。
共有カスタム プレースメント ポリシーを使用してノードプールを作成する
リソース ポリシーを手動で作成して、複数のノードプールで使用できます。
クラスタの Google Cloud リージョンにリソース ポリシーを作成します。
gcloud compute resource-policies create group-placement POLICY_NAME \ --region REGION \ --collocation collocated
次のように置き換えます。
POLICY_NAME
: リソース ポリシーの名前。REGION
: クラスタのリージョン。
カスタム リソース ポリシーを使用してノードプールを作成します。
gcloud container node-pools create NODEPOOL_NAME \ --machine-type MACHINE_TYPE \ --cluster CLUSTER_NAME \ --placement-policy POLICY_NAME \ --max-surge-upgrade 0 \ --max-unavailable-upgrade MAX_UNAVAILABLE
次のように置き換えます。
NODEPOOL_NAME
: 新しいノードプールの名前。MACHINE_TYPE
: ノードに使用するマシンのタイプ。C2 マシンタイプ(c2-standard-4
など)にする必要があります。CLUSTER_NAME
: 既存のクラスタの名前。MAX_UNAVAILABLE
: ノードプールのアップグレード中に同時に使用できないノードの最大数。コンパクト プレースメントには、アップグレード中に同じ場所に配置されたノードを検出する可能性を最適化するため、高速、サージ アップグレードなしをおすすめします。
コンパクト プレースメント ポリシーを使用する Compute Engine 予約を使用する
予約を使用すると、指定したゾーンでハードウェアが使用できることが保証され、ハードウェア不足が原因でノードプールの作成が失敗するリスクを軽減できます。
コンパクト プレースメント ポリシーを指定する予約を作成します。
gcloud compute reservations create RESERVATION_NAME \ --vm-count MACHINE_COUNT \ --machine-type MACHINE_TYPE \ --resource-policies policy=POLICY_NAME \ --zone ZONE \ --require-specific-reservation
次のように置き換えます。
RESERVATION_NAME
: 予約の名前。MACHINE_COUNT
: 予約済みノードの数。MACHINE_TYPE
: ノードに使用するマシンのタイプ。C2 マシンタイプである必要があります。たとえば、4 個の vCPU を持つ事前定義の C2 マシンタイプを使用するには、c2-standard-4
を指定します。POLICY_NAME
: リソース ポリシーの名前。ZONE
: 予約を作成するゾーン。
コンパクト プレースメント ポリシーと前の手順で作成した予約の両方を指定して、ノードプールを作成します。
gcloud container node-pools create NODEPOOL_NAME \ --machine-type MACHINE_TYPE \ --cluster CLUSTER_NAME \ --placement-policy POLICY_NAME \ --reservation-affinity specific \ --reservation RESERVATION_NAME \ --max-surge-upgrade 0 \ --max-unavailable-upgrade MAX_UNAVAILABLE
次のように置き換えます。
NODEPOOL_NAME
: 新しいノードプールの名前。MACHINE_TYPE
: ノードに使用するマシンのタイプ。C2 マシンタイプ(c2-standard-4
など)にする必要があります。CLUSTER_NAME
: 既存のクラスタの名前。
コンパクト プレースメントを使用するノードにワークロードを作成する
コンパクト プレースメントを使用する専用ノードでワークロードを実行するには、次のようなノードへの Pod の割り当てや、ノードのグループに対する不要な Pod のスケジューリングの防止など、いくつかの Kubernetes メカニズムを使用します。
次の例では、専用ノードに taint を追加し、対応する容認とアフィニティを Pod に追加します。
コンパクト プレースメント ポリシーが設定されているノードプール内のノードに taint を追加します。
kubectl taint nodes -l cloud.google.com/gke-nodepool=NODEPOOL_NAME dedicated-pool=NODEPOOL_NAME:NoSchedule
ワークロード定義で、必要な許容範囲とノード アフィニティを指定します。次に、単一 Pod の例を示します。
apiVersion: v1 kind: Pod metadata: ... spec: ... tolerations: - key: dedicated-pool operator: "Equal" value: "NODEPOOL_NAME" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: dedicated-pool operator: In values: - NODEPOOL_NAME
一部の場所では、コンパクト プレースメント ポリシーを使用して大規模なノードプールを作成できない場合があります。このようなノードプールのサイズを必要なサイズに制限するには、コンパクトな配置が必要なワークロードごとにノードプールを作成することをおすすめします。
ノードの自動プロビジョニングにコンパクト プレースメントを使用する
GKE バージョン 1.25 以降では、ノードの自動プロビジョニングでコンパクト プレースメント ポリシーがサポートされています。ノードの自動プロビジョニングにより、GKE はクラスタ リソースの需要に基づいてノードプールを自動的にプロビジョニングします。詳細については、ノードの自動プロビジョニングを使用するをご覧ください。
ノードの自動プロビジョニングのコンパクト プレースメントを有効にするには、次のキーを使用して nodeSelector
を Pod 仕様に追加します。
cloud.google.com/gke-placement-group
は、同じコンパクト プレースメント グループ内で一緒に実行される Pod のグループに割り当てる識別子です。cloud.google.com/machine-family
はマシン ファミリー名です。コンパクト プレースメントをサポートするマシン ファミリーのいずれかを使用します。コンピューティングとネットワークのパフォーマンス要件があるワークロードには、C2 または C2D マシン ファミリーを使用することをおすすめします。
次の例は、コンパクト プレースメントを有効にする Pod 仕様です。
apiVersion: v1
kind: Pod
metadata:
...
spec:
...
nodeSelector:
cloud.google.com/gke-placement-group: PLACEMENT_GROUP_IDENTIFIER
cloud.google.com/machine-family: MACHINE_FAMILY
Pod 構成で、コンパクト プレースメントでサポートされているマシンタイプがすでに定義されている場合は、cloud.google.com/machine-family
キーを省略できます。たとえば、Pod 仕様に nvidia.com/gpu
が含まれ、クラスタが A100 GPU を使用するように構成されている場合、cloud.google.com/machine-family
キーを含める必要はありません。
次の例は、nvidia.com/gpu
リクエストを定義する Pod 仕様で、クラスタが A100 GPU を使用するように構成されています。この Pod spec
には cloud.google.com/machine-family
キーが含まれていません。
apiVersion: v1
kind: Pod
metadata:
...
spec:
...
nodeSelector:
cloud.google.com/gke-placement-group: PLACEMENT_GROUP_IDENTIFIER
cloud.google.com/gke-accelerator: "nvidia-tesla-a100"
resources:
limits:
nvidia.com/gpu: 2
詳細については、GPU を使用するように Pod を構成するをご覧ください。
プレースメント グループのサイズを最適化する
GKE は小規模な Deployment に最適なプレースメントを見つけるため、同じプレースメント グループで異なるタイプの Pod を実行しないように GKE に指示することをおすすめします。cloud.google.com/gke-placement-group
キーと、定義したコンパクト プレースメント ID を指定して、toleration キーを追加します。
次の例は、コンパクト プレースメントを使用した Pod toleration を定義する Pod 仕様を示しています。
apiVersion: v1
kind: Pod
metadata:
...
spec:
...
tolerations:
- key: cloud.google.com/gke-placement-group
operator: "Equal"
value: PLACEMENT_GROUP_IDENTIFIER
effect: "NoSchedule"
Pod toleration によるノードの自動プロビジョニングの詳細については、ワークロードの分離をご覧ください。
次のステップ
- Compute Engine でのインスタンス プレースメント ポリシーの定義について学習する。