GKE ノードのコンパクト プレースメントを定義する

コンパクト プレースメント ポリシーを使用して、Google Kubernetes Engine(GKE)ノードをゾーン内で相互に相対的に配置するかどうかを制御できます。

概要

GKE クラスタにノードプールとワークロードを作成するときには、コンパクト プレースメント ポリシーを定義できます。このポリシーでは、これらのノードまたはワークロードを互いにゾーン内の物理的に近い場所に配置するように指定できます。ノードを近づけることで、ノード間のネットワーク レイテンシが短縮されます。これは、密結合のバッチ ワークロードに特に役立ちます。

GKE Autopilot でコンパクト プレースメントを使用する

Autopilot クラスタでは、Pod 仕様にノードセレクタを追加することで、特定のワークロードのコンパクト プレースメントをリクエストできます。デフォルトの Autopilot コンパクト プレースメント ポリシーを使用することも、N2 マシンシリーズまたは N2D マシンシリーズの既存の Compute Engine コンパクト プレースメント ポリシーを使用することもできます。

制限事項

  • GKE では、同じゾーンのコンパクト プレースメント内でワークロードがプロビジョニングされます。
  • コンピューティング クラス BalancedPerformanceAccelerator で使用できます。
  • C2、C2D、C3、C3D、C4D(1.33.0-gke.1439000 以降)、H3、H4D、N2、N2D のマシンタイプでのみ使用できます。
  • A100、L4、H100 GPU でのみ使用できます。
  • コンパクト プレースメントは、最大 1,500 個のノードでグループ化された Pod で使用できます。

コンパクト プレースメント ポリシーを有効にする

GKE Autopilot のコンパクト プレースメントを有効にするには、次のキーを使用して nodeSelector を Pod 仕様に追加します。

  • cloud.google.com/gke-placement-group: 同じコンパクト プレースメント グループ内で実行する必要のある Pod のグループに割り当てる識別子。各プレースメント グループのノード数は 1,500 に制限されています。プレースメント グループは、グループ化するとメリットが得られるワークロードのみに制限し、可能であれば、ワークロードを別々のプレースメント グループに分散することをおすすめします。

  • リソースのタイプを定義する次のいずれかのキー。

    • cloud.google.com/compute-class: "Balanced"
    • cloud.google.com/gke-accelerator: "nvidia-tesla-a100"
  • cloud.google.com/placement-policy-name: (省略可)既存の Compute Engine コンパクト プレースメント ポリシーの名前。カスタム コンパクト プレースメント ポリシーは、GKE バージョン 1.31.1-gke.2010000 以降でのみ指定できます。

    手順については、このページのコンパクト プレースメント ポリシーを作成するをご覧ください。

次の Pod 仕様の例では、カスタム コンパクト プレースメント ポリシーを使用してコンパクト プレースメントを有効にしています。

apiVersion: v1
kind: Pod
metadata:
# lines omitted for clarity
spec:
  nodeSelector:
    cloud.google.com/gke-placement-group: "placement-group-1"
    cloud.google.com/compute-class: "Balanced"
    cloud.google.com/placement-policy-name: PLACEMENT_POLICY_NAME

PLACEMENT_POLICY_NAME は、既存の Compute Engine コンパクト プレースメント ポリシーの名前に置き換えます。Autopilot のデフォルトのコンパクト プレースメント ポリシーを使用する場合は、cloud.google.com/placement-policy-name 行を省略します。

プレースメント グループを使用せずにカスタム コンパクト プレースメント ポリシーを使用する

プレースメント グループのないカスタム コンパクト プレースメント ポリシーを使用するには、Pod 仕様に cloud.google.com/placement-policy-name ノードセレクタを追加するか、プレースメント優先度でカスタム コンピューティング クラスを定義する必要があります。

Pod 仕様に cloud.google.com/placement-policy-name ノードセレクタを追加する

この方法は、JobSet を使用して各ジョブを個別にスケジュールしながら、カスタム コンパクト プレースメント ポリシーを使用して、同じジョブを実行するノードを近くに配置したい場合に役立ちます。

JobSet ではジョブごとに異なるノードセレクタを指定できないため、このシナリオではプレースメント グループで JobSet を使用できません。ただし、排他的なトポロジに対する JobSet の組み込みサポートを使用しても同じ効果が得られます。

次の Pod 仕様の例では、JobSet ワークロードのカスタム コンパクト プレースメント ポリシーを使用してコンパクト プレースメントを有効にしています。

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: my-jobset
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-nodepool
spec:
 replicatedJobs:
    - name: my-job
      template:
        spec:
          # lines omitted for clarity
          template:
            spec:
              nodeSelector:
                cloud.google.com/placement-policy-name: PLACEMENT_POLICY_NAME
                cloud.google.com/machine-family: "n2"
              # lines omitted for clarity

PLACEMENT_POLICY_NAME は、既存の Compute Engine コンパクト プレースメント ポリシーの名前に置き換えます。

カスタム コンピューティング クラスを使用してプレースメント ポリシーを定義する

詳細については、プレースメント優先度を使用したカスタム コンピューティング クラスのドキュメントをご覧ください。

ポリシー名を含む nodeSelector をワークロード仕様に直接追加する代わりに、ComputeClass 定義の placement フィールドを設定して、コンパクト プレースメント ポリシーを適用できます。詳細については、配置優先度を持つカスタム コンピューティング クラスをご覧ください。

GKE Standard でコンパクト プレースメントを使用する

制限事項

GKE Standard ノードプールのコンパクト プレースメントには、次の制限があります。

  • 新しいノードプールでのみサポートされます。既存のノードプールでコンパクト プレースメントを有効または無効にすることはできません。
  • 単一ゾーンで動作するノードプールでのみ使用できます。
  • A2、A3、A4、C2、C2D、C3、C3D、C4、C4D、G2、H3、H4D、N2、N2D マシンタイプでのみ使用できます。ただし、A3 UltraA4 の場合は、コンパクト プレースメントではなく、ブロック ターゲット予約の使用をおすすめします。詳細については、容量を予約するをご覧ください。
  • 各ポリシーで最大 1,500 個の 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: ノードに使用するマシンのタイプ。Standard クラスタの制限事項に記載されているサポート対象のマシンタイプである必要があります。
  • --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: ノードに使用するマシンのタイプ。Standard クラスタの制限事項に記載されているサポート対象のマシンタイプである必要があります。
  • CLUSTER_NAME: 既存のクラスタの名前。
  • --placement-type COMPACT: 新しいノードプール内のノードにコンパクト プレースメントを適用することを示します。
  • MAX_UNAVAILABLE: ノードプールのアップグレード中に同時に使用できないノードの最大数。コンパクト プレースメントには、アップグレード中に同じ場所に配置されたノードを検出する可能性を最適化するため、高速、サージ アップグレードなしをおすすめします。

共有カスタム プレースメント ポリシーを使用してノードプールを作成する

リソース ポリシーを手動で作成して、複数のノードプールで使用できます。

  1. クラスタの Google Cloud リージョンにリソース ポリシーを作成します。

    gcloud compute resource-policies create group-placement POLICY_NAME \
        --region REGION \
        --collocation collocated
    

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

    • POLICY_NAME: リソース ポリシーの名前。
    • REGION: クラスタのリージョン。
  2. カスタム リソース ポリシーを使用してノードプールを作成します。

    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: ノードに使用するマシンのタイプ。Standard クラスタの制限事項に記載されているサポート対象のマシンタイプである必要があります。
    • CLUSTER_NAME: 既存のクラスタの名前。
    • MAX_UNAVAILABLE: ノードプールのアップグレード中に同時に使用できないノードの最大数。コンパクト プレースメントには、アップグレード中に同じ場所に配置されたノードを検出する可能性を最適化するため、高速、サージ アップグレードなしをおすすめします。

コンパクト プレースメント ポリシーを使用する Compute Engine 予約を使用する

予約を使用すると、指定したゾーンでハードウェアが使用できることが保証され、ハードウェア不足が原因でノードプールの作成が失敗するリスクを軽減できます。

  1. コンパクト プレースメント ポリシーを指定する予約を作成します。

    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: ノードに使用するマシンのタイプ。Standard クラスタの制限事項に記載されているサポート対象のマシンタイプである必要があります。
    • POLICY_NAME: リソース ポリシーの名前。
    • ZONE: 予約を作成するゾーン。
  2. コンパクト プレースメント ポリシーと前の手順で作成した予約の両方を指定して、ノードプールを作成します。

    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: ノードに使用するマシンのタイプ。Standard クラスタの制限事項に記載されているサポート対象のマシンタイプである必要があります。
  • CLUSTER_NAME: 既存のクラスタの名前。

コンパクト プレースメントを使用するノードにワークロードを作成する

コンパクト プレースメントを使用する専用ノードでワークロードを実行するには、次のようなノードへの Pod の割り当てや、ノードのグループに対する不要な Pod のスケジューリングの防止など、いくつかの Kubernetes メカニズムを使用します。

次の例では、専用ノードに taint を追加し、対応する容認とアフィニティを Pod に追加します。

  1. コンパクト プレースメント ポリシーが設定されているノードプール内のノードに taint を追加します。

    kubectl taint nodes -l cloud.google.com/gke-nodepool=NODEPOOL_NAME dedicated-pool=NODEPOOL_NAME:NoSchedule
    
  2. ワークロード定義で、必要な許容範囲とノード アフィニティを指定します。次に、単一 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 はクラスタ リソースの需要に基づいてノードプールを自動的にプロビジョニングします。詳細については、ノードの自動プロビジョニングを使用するをご覧ください。

ノードの自動プロビジョニングのコンパクト プレースメントを有効にするには、次の例のように Pod 仕様に nodeSelector を追加します。

apiVersion: v1
kind: Pod
metadata:
# lines omitted for clarity
spec:
  nodeSelector:
    cloud.google.com/gke-placement-group: PLACEMENT_GROUP_IDENTIFIER
    cloud.google.com/machine-family: MACHINE_FAMILY
    cloud.google.com/placement-policy-name: PLACEMENT_POLICY_NAME
# lines omitted for clarity

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

  • PLACEMENT_GROUP_IDENTIFIER: 同じコンパクト プレースメント グループ内で実行する必要のある Pod のグループに割り当てる識別子。
  • MACHINE_FAMILY: マシン ファミリーの名前。コンパクト プレースメントをサポートするマシン ファミリーのいずれかを使用します。コンピューティングとネットワークのパフォーマンス要件があるワークロードには、C2 または C2D マシン ファミリーを使用することをおすすめします。
  • PLACEMENT_POLICY_NAME: (省略可)既存の Compute Engine コンパクト プレースメント ポリシーの名前。ノード自動プロビジョニングによって新しいノードプールが作成され、Pod がグループ化されると、GKE は指定されたコンパクト プレースメント ポリシーを使用します。カスタム コンパクト プレースメント ポリシーは、GKE バージョン 1.31.1-gke.2010000 以降でのみ指定できます。

    手順については、このページのコンパクト プレースメント ポリシーを作成するをご覧ください。

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 によるノードの自動プロビジョニングの詳細については、ワークロードの分離をご覧ください。

次のステップ