Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

カスタムスケジューラで動的スライスを使用する

Standard

このドキュメントでは、Slice カスタムリソースを直接操作して動的スライスを使用する方法について説明します。スライスを作成し、パーティションの状態をモニタリングして、スライスの正常性を確認できます。

この手順を行う前に、動的スライシングのコンセプトを理解しておいてください。

カスタムスケジューラで動的スライスを使用する理由

複雑なスケジューリング要件がある場合や、動的スライスを既存のスケジューリングインフラストラクチャと統合する場合は、独自のスケジューラを使用して Slice カスタムリソースを管理します。

Slice カスタムリソースを直接管理するのではなく、スケジューラを使用する場合は、GKE で Kueue とトポロジ認識スケジューリング（TAS）との統合が提供されます。詳細については、Kueue と TAS を使用して動的スライスをスケジュールするをご覧ください。

ワークフローの概要

カスタムスケジューラで動的スライスを使用するには、このドキュメントで次のタスクを行います。

スライスコントローラを有効にします。
増分プロビジョニングを使用してノードプールを作成する。
ワークロードの要件に基づいて Slice カスタムリソースを作成します。Slice カスタムリソースをクラスタに適用します。
パーティションの状態とスライスの健全性をモニタリングします。
完了したら、スライスを削除します。

Slice カスタムリソースのフィールドとステータスの詳細については、Slice カスタムリソースのリファレンス情報をご覧ください。

要件

GKE で動的スライスを使用するには、次の要件を満たす必要があります。

次のいずれかのバージョンの Rapid チャンネルで Standard クラスタを使用します。
- 動的スーパースライシング構成（トポロジが 4x4x4 以上）の場合は、バージョン 1.35.2-gke.1842000 以降を使用します。
- 動的サブスライス構成（4x4x4 より小さいトポロジ）の場合は、バージョン 1.36.0-gke.3712000 以降を使用します。
Ironwood（TPU7x）バージョンを使用します。
ノードに Container-Optimized OS イメージを使用します。
増分プロビジョニングを使用するには、All Capacity モードの予約を使用します。All Capacity モードは、TPU Cluster Director によって有効になる機能です。
動的サブスライスでは、ノードに保留中のメンテナンスイベントがあることを確認します。保留中のメンテナンスイベントについてインスタンスをモニタリングする。終了時刻が 2026 年 9 月 18 日から 2026 年 9 月 30 日の間に設定されている保留中のメンテナンスイベントがノードにある場合は、サブスライスを使用する前に、これらのノードでホストメンテナンスイベントを手動でトリガーする必要があります。

始める前に

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

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 など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

Rapid チャンネルで、バージョン 1.35.2-gke.1842000 以降の既存の Standard クラスタがあることを確認します。新しいクラスタを作成するには、リージョンクラスタの作成をご覧ください。
リージョンに Ironwood（TPU7x）の十分な割り当てがあることを確認します。
マルチスライスワークロードを実行する場合は、v0.10.1 以降の JobSet をインストールします。
All Capacity モードで TPU 容量をリクエストする。

スライスコントローラを有効にする

動的スライスを使用するには、クラスタでスライスコントローラを有効にします。

クラスタを更新します。
```
gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-slice-controller
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- LOCATION: 使用可能な TPU 容量があるリージョン。

kubectl コマンドを使用してクラスタと通信できるように、認証情報を取得します。

gcloud config set container/cluster CLUSTER_NAME
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION

次のコマンドの出力で、slices.accelerator.gke.io 値が存在することを確認します。
```
kubectl get crd slices.accelerator.gke.io
```
出力は次のようになります。
```
slices.accelerator.gke.io                2026-01-09T23:58:02Z
```

増分プロビジョニングでノードプールを作成する

このセクションでは、増分プロビジョニングを使用して TPU ノードプールを作成する方法について説明します。GKE は、すべての TPU 容量を 16 ノードの TPU VM グループ（サブブロック）のノードプールに変換します。GKE は、ホストマシンの正常な部分にノードを配置し、異常なマシンを修復しながら段階的にプロビジョニングすることで、16 個の正常な VM をすべて見つけられない場合でも、これらのノードプールをプロビジョニングします。

ノードプールは次のいずれかに属するようにターゲット設定できます。

All Capacity モードの予約で公開される特定の TPU ブロック。ブロックターゲティングにより、GKE は指定されたブロック内の使用可能なサブブロックにノードプールを作成できます。
よりきめ細かい制御を行うための、TPU の特定のサブブロックまたは TPU VM の特定の 16 ノードグループ。

ワークロードポリシーの作成

Ironwood（TPU7x）で TPU スライスノードプールを作成するには、まず accelerator-topology-mode フィールドが provision_only に設定されたワークロードポリシーを作成する必要があります。この設定により、増分プロビジョニングプロセスがトリガーされます。

ワークロードポリシーを作成します。

gcloud compute resource-policies create workload-policy WORKLOAD_POLICY_NAME \
        --project=PROJECT_ID \
        --region=REGION  \
        --type=HIGH_THROUGHPUT \
        --accelerator-topology=4x4x4 \
        --accelerator-topology-mode=provision_only

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

WORKLOAD_POLICY_NAME: ワークロードポリシーの名前。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。
REGION: ワークロードポリシーのリージョン。

このコマンドで、次の操作を行います。

accelerator-topology フィールドは常に 4x4x4 に設定して、単一のサブブロック内のチップの総数と一致させます。
増分プロビジョニングプロセスがトリガーされるように、accelerator-topology-mode フィールドは常に provision_only に設定してください。provision_only フィールドが設定されている場合、ノードプールは ICI リンクまたは OCS リンクを形成せずに TPU ノードをプロビジョニングします。

ノードプールがブロックまたはサブブロックに属するようにターゲットを設定する

すべての容量モードの予約内で、特定のサブブロックまたはブロックをターゲットにできます。

ブロックをターゲットにする: 各ノードプールは、指定されたブロックの容量を使用します。GKE は、そのブロック内の使用可能なサブブロックにノードプールを配置します。使用するブロックのサブブロックの数と同じ数のノードプールを作成する必要があります。
サブブロックをターゲットにする: 各ノードプールは、特定の利用可能なサブブロックにマッピングされます。サブブロックターゲティングを使用する場合、GKE は少なくとも 1 つの VM が正常であればノードプールを作成します。増分プロビジョニングにより、すべてのノードが指定されたサブブロック内に配置されます。

ブロック

予約のブロックの名前と、ブロックで使用可能なサブブロックの数を取得するには、All Capacity モードの予約のトポロジと健全性ステータスを表示するドキュメントの手順に沿って操作します。
1. すべての予約ブロックを一覧表示して、name: フィールドの値をコピーし、ブロックの名前を特定します。この値は、このドキュメント内のブロックまたは BLOCK_NAME の名前です。
2. 予約ブロックを記述し、reservationSubBlockCount フィールドの値を確認して、作成するノードプールの数を決定します。この値は、使用可能なサブブロックの数です。たとえば、reservationSubBlockCount: 4 値は、ブロックに 4 つのサブブロックが使用可能であることを示します。この場合、4 つの個別のノードプールを作成する必要があります。
予約パスを設定します。
```
export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME"
```
次のように置き換えます。
- RESERVATION_NAME: TPU 予約の名前。
- BLOCK_NAME: ブロックの名前。
前の手順で特定したサブブロックごとにノードプールを作成します。たとえば、カウントが 4 の場合は、このコマンドを 4 回実行します。各ノードプールに一意の名前を使用します。
```
gcloud container node-pools create NODE_POOL_NAME \
      --cluster=CLUSTER_NAME \
      --node-locations=ZONE \
      --machine-type=tpu7x-standard-4t \
      --num-nodes=16 \
      --placement-policy=WORKLOAD_POLICY_NAME \
      --reservation-affinity=specific \
      --reservation=${RESERVATION_PATH}
```
次のように置き換えます。
- NODE_POOL_NAME: 新しいノードプールの名前。
- CLUSTER_NAME: GKE クラスタの名前。
- WORKLOAD_POLICY_NAME: 作成したワークロードポリシーの名前。
- ZONE: ノードプールのゾーン（us-central1-a など）。

サブブロック

ブロックの名前と使用可能なサブブロックの ID を取得するには、All Capacity モードの予約のトポロジと健全性ステータスを表示するドキュメントで次の手順を完了します。
1. ブロックの名前を確認するには、すべての予約ブロックを一覧表示し、name: フィールドの値をコピーします。この値は、このドキュメントのブロックまたは BLOCK_NAME の名前です。
2. サブブロックの名前を特定するには、ブロックのすべてのサブブロックを一覧表示し、reservationSubBlocks の各エントリの name: フィールドの値をコピーします。この値は、このドキュメントのサブブロックまたは SUBBLOCK_NAME の名前です。
予約パスを設定します。
```
export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUBBLOCK_NAME"
```
次のように置き換えます。
- RESERVATION_NAME: TPU 予約の名前。
- BLOCK_NAME: ブロックの名前。
- SUBBLOCK_NAME: サブブロックの名前。

ノードプールを作成します。

gcloud container node-pools create NODE_POOL_NAME \
        --project=PROJECT_ID \
        --cluster=CLUSTER_NAME \
        --node-locations=ZONE \
        --machine-type=tpu7x-standard-4t \
        --num-nodes=16 \
        --placement-policy=WORKLOAD_POLICY_NAME \
        --reservation-affinity=specific \
        --reservation=${RESERVATION_PATH}

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

NODE_POOL_NAME: 新しいノードプールの一意の名前（例: sub-block-pool-1）。
PROJECT_ID: 実際の Google Cloud プロジェクト ID。
CLUSTER_NAME: GKE クラスタの名前。
ZONE: ノードプールのゾーン（us-central2-b など）。
WORKLOAD_POLICY_NAME: 作成したワークロードポリシーの名前。

この段階では、ノードは作成されますが、Inter-Chip Interconnect（ICI）リンクはまだアクティブではありません。そのため、これらのノードプールでワークロードを直接実行することはできません。

必要な ICI リンクをすべて有効にしてスライスを形成し、ワークロードのスケジュール設定を許可するには、次のいずれかの方法で動的スライスを作成します。

スライスカスタムリソースを作成します。Pod の代わりに、Slice カスタムリソースを使用して指定されたトポロジを定義します。このトポロジは、スライスコントローラによって有効になります。
Kueue と TAS を使用して GKE ワークロードをスケジュールします。Kueue は、Slice カスタムリソースの作成と削除を自動的に処理します。Kueue によって作成された Slice カスタムリソースを手動で変更しないでください。

スーパースライスまたはサブスライスを使用して動的スライスを形成する

ノードプールを作成したら、Slice カスタムリソースを作成して、より大きな動的スーパースライスまたはより小さな動的サブスライスを形成できます。Slice カスタムリソースは、スライスコントローラが有効にする指定されたトポロジを定義します。ワークロードは、この動的スライスでスケジュール設定と実行を行います。

動的スライスパーティション

パーティションは、ワークロードの動的スライスを形成するために使用できるトポロジを提供します。パーティションには、2x2x1、2x2x2、2x2x4、2x4x4、4x4x4 など、各ノードで使用可能なすべてのトポロジが表示されます。4x4x4 より小さいトポロジには、GKE バージョン 1.36.0-gke.3712000 以降が必要です。

4x4x4 より大きいスライスには、複数の 4x4x4 パーティションを関連付けて作成されるため、パーティションラベルがありません。

増分プロビジョニングノードプールのすべての TPU ノードには、指定されたすべてのパーティション ID とパーティション状態ノードラベルが必要です。

ノードとパーティションのステータスを確認する

ノードプールからノード名を取得するには、次のコマンドを実行します。

kubectl get nodes -l cloud.google.com/gke-nodepool=${NODE_POOL_NAME}

結果は次のようになります。

NAME                                 STATUS   ROLES    AGE    VERSION
gke-np-status-update-7b4c890c-0jhp   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-377r   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-gb51   Ready    <none>   2d1h   v1.35.1-gke.1396002

ノードのプロビジョニングモデルを確認します。

kubectl describe node NODE_NAME | grep "cloud.google.com/gke-accelerator-topology-mode"

結果は次のようになります。

cloud.google.com/gke-accelerator-topology-mode: PROVISION_ONLY

ターゲットにするトポロジパーティションのノードラベル情報を取得します。

kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-id"

NODE_NAME は、ノードプール内のいずれかのノードの名前に置き換えます。

結果は次のようになります。

cloud.google.com/gke-tpu-partition-4x4x4-id=fba785f80d18552357dcdef6d3d16c27
cloud.google.com/gke-tpu-partition-2x4x4-id=e18372d627ac412cb24d5ea8ab8912c9
cloud.google.com/gke-tpu-partition-2x2x4-id=7fbd4e29dc1839217fae41a9dd8211b4
cloud.google.com/gke-tpu-partition-2x2x2-id=a9476d1b02bd4f4e75ffffae3bd23c01
cloud.google.com/gke-tpu-partition-2x2x1-id=0bcfe937d1bb3914a8bdcd94e9f73319

ノードに node.gke.io/created-by-mig アノテーションが含まれていることを確認します。
```
kubectl describe node NODE_NAME | grep "node.gke.io/created-by-mig"
```
NODE_NAME は、ノードプール内のいずれかのノードの名前に置き換えます。

結果は次のようになります。
```
node.gke.io/created-by-mig: projects/735972712744/zones/us-central1-ai1a/team/string
```
出力には node.gke.io/created-by-mig アノテーションが含まれます。これにより、GKE コントロールプレーンは Kubernetes ノードを基盤となる Compute Engine リソースにリンクできます。
確認するトポロジパーティションの状態のノードラベル情報を取得します。
```
kubectl describe node NODE_NAME | grep -E "cloud.google.com/gke-tpu-partition-.*-state"
```
結果は次のようになります。
```
cloud.google.com/gke-tpu-partition-4x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x2-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x1-state=HEALTHY
```
cloud.google.com/gke-tpu-partition-[shape]-state ラベル（[shape] はパーティション ID のトポロジに対応）は、パーティションが動的スライスを形成できるかどうかを示します。この状態ラベルは、次の値をサポートしています。
- HEALTHY: パーティションは正常で、完全に機能しています。
- DEGRADED: パーティションは破損していますが、動的スライス形成には引き続き使用できます。この状態は、最上位の 4x4x4 トポロジにのみ適用されます。小規模なトポロジには、劣化状態はありません。
- UNHEALTHY: パーティションが機能しておらず、スライスを形成するために使用できません。
- UNSET: GKE スライスコントローラの初期化が失敗したため、状態が未定義です。
- INCOMPLETE: パーティション内のすべてのノードがプロビジョニングされていません。

Slice カスタムリソースを作成する

Slice カスタムリソースは、動的スーパースライスを作成するか、動的サブスライスを作成するかによって若干異なります。

Slice カスタムリソースを定義します。
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  # Name of the slice resource
  name: SLICE_NAME
spec:
  # Specify the type of accelerator for this slice
  type: "tpu7x"
  # Define the desired topology for the accelerator slice
  topology: TOPOLOGY
  partitionIds:
    - PARTITION_ID # Example: a9476d1b02bd4f4e75ffffae3bd23c01
    - PARTITION_ID_2
    # ... add more partition IDs as needed
```
次のように置き換えます。
- SLICE_NAME: スライスの名前。名前は metadata.name の条件を満たし、49 文字以下にする必要があります。
- TOPOLOGY: 動的スライスのトポロジ。トポロジは次の条件を満たしている必要があります。
  - 動的サブスライスの場合: 2x2x1、2x2x2、2x2x4、2x4x4 など、4x4x4 より小さいトポロジを指定できます。これらの小規模なトポロジには、GKE バージョン 1.36.0-gke.3712000 以降が必要です。
  - 動的スーパースライシングの場合: 4x4x4 以上のトポロジを指定できます。動的スーパースライシングを構成するには、リクエストされたトポロジの各ディメンションが 4 の倍数である必要があります（例: 4A x 4B x 4C）。トポロジディメンションの 3 つの値 AxBxC は、非減少順（A ≤ B ≤ C）にする必要があります。たとえば、4x4x8 は有効ですが、4x8x4 は無効です。この順序により、スライスの形成が安定し、予期しない動作を回避できます。トポロジディメンションの 3 つの値の積 A × B × C は 9,216 を超えてはなりません。
- PARTITION_ID: スライスを構成するパーティションを識別する文字列のリスト。
  - 動的サブスライスの場合: 1 つだけパーティション ID を指定する必要があります。
  - 動的スーパースライシングの場合: パーティションの数を計算する必要があります。各パーティションは 64 個のチップで構成されます。spec.partitionIds リスト内のアイテムの数は、計算されたパーティション数（(A × B × C) / 64）と完全に一致している必要があります。
  - partitionIds リストは、次の条件を満たしている必要があります。
    - 各パーティションは予約サブブロックにマッピングする必要があります。
    - 関連付けられたサブブロックはすべて同じ予約に属している必要があります。
    - 関連付けられたすべてのサブブロックは、同じ予約内に存在する必要があります。
    - 関連付けられたノードプール内のすべてのノードが ready 状態である必要があります。
- type フィールドの値は tpu7x にする必要があります。
- 必要に応じて、スライスコントローラがスライス形成中に自動的に再試行できるようにするには、スライスカスタムリソースに slice.gke.io/retry-on-failure: "true" アノテーションを追加します。SliceCreationFailed ステータスの理由でスライスが作成されない場合、コントローラはスライスが正常に形成されるまで再試行します。
たとえば、4x8x8 スライス（動的スーパースライス）を作成するには、4 つの一意のパーティション ID を指定する必要があります。
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
    name: test-super-slice-example
    annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
    type: "tpu7x"
    topology: "4x8x8" # (4*8*8)/64 = 4 partitions
    partitionIds:
        - "p0-4x4x4"
        - "p1-4x4x4"
        - "p2-4x4x4"
        - "p3-4x4x4"
```
たとえば、2x2x2 スライス（動的サブスライス）を作成するには、一意のパーティション ID を 1 つ指定する必要があります。
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  name: test-sub-slice-example
  annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
  type: "tpu7x"
  topology: "2x2x2"
  partitionIds:
    - "fba785f80d18552357dcdef6d3d16c27" # Only 1 partitionId for sub-slice
```
Slice カスタムリソースを適用します。
```
kubectl apply -f test-slice-example.yaml
```
この時点で、GKE はスライスの作成を試みます。次のいずれかの問題が発生すると、スライスの作成が失敗し、Slice カスタムリソースのステータスの理由が SliceCreationFailed または FAILED に更新されます。
- カスタムリソースで選択されたノードが存在しない場合、ステータスの理由は SliceCreationFailed になります。
- カスタムリソースのノードが別のスライスで使用されている場合、ステータスの理由は SliceCreationFailed になります。
- カスタムリソースのノードが同じ予約サブブロックの一部でない場合、ステータスの理由は FAILED になります。
- ノードが同じ予約にない場合、ステータスの理由は FAILED になります。
- トポロジがパーティションの数と一致しない場合、ステータスの理由は SliceCreationFailed です。
ステータスが SliceCreationFailed のときにスライス形成を自動的に再試行するには、Slice カスタムリソースを作成するで説明されているように slice.gke.io/retry-on-failure: "true" アノテーションを構成します。

Slice カスタムリソースのステータスの詳細については、Slice のステータスをご覧ください。

Slice カスタムリソースのステータスをモニタリングする

Slice カスタムリソースのステータスを確認するには、次のコマンドを実行します。

kubectl describe slice SLICE_NAME

SLICE_NAME は、スライスの名前に置き換えます。

出力は次のようになります。

Name:         test-slice
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-01-11T23:45:15Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1768175347356335006
  UID:               d0b71e5c-be3f-4788-aead-930c7afec4f2
Spec:
  Partition Ids:
    2c79463990ff67c4e3c2648666bfedfa
    ba898ffcac0ad0946e8ff036d771ee53
    [more partition IDs]
  Topology:  8x16x16
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-01-11T23:45:38Z
    Message:               ""
    
    Reason:                FAILED
    
    Status:                False
    Type:                  Ready
Events:

Slice カスタムリソースのステータスの reason フィールドは、現在のライフサイクル状態を示します。可能な状態は、動的サブスライスを使用しているか、動的スーパースライスを使用しているかによって異なります。

動的サブスライシングのステータス条件

SliceNotCreated: コントローラが初期化とリソースのチェックを実行します。
- 前提条件が満たされていない場合、状態は SliceCreationFailed に移行します。
- 検証に合格すると、状態は ACTIVATING に移行します。
ACTIVATING: GKE がスライスを形成しています。
- 成功すると、状態は ACTIVE に移行します。
- サブブロックがデグレードしてもスライスが使用可能な場合、状態は ACTIVE_DEGRADED に移行します。
- 形成に失敗すると、状態は FAILED に移行します。
DEACTIVATING: Slice カスタムリソースが削除された場合、またはアクティブ状態または失敗状態のときに重大な障害が発生した場合、スライスは解体を始めます。
INCOMPLETE: リソースが完全に削除される前の最終ステップ。

動的スーパースライシングのステータス条件

SliceNotCreated: スライスがまだ作成されていません。スライスコントローラが初期化され、スライス形成のプリフライトチェックが実行されています。
SliceCreationFailed: 前提条件が満たされていない（必要な Compute Engine リソースがないなど）か、事前チェックが失敗したため、作成に失敗しました。この状態のスライス形成を自動的に再試行するには、slice.gke.io/retry-on-failure: "true" アノテーションを構成します。
ACTIVATING: スライスは形成（ステッチ）中です。
ACTIVE: スライスが完全に形成され、正常で、ワークロードを実行する準備ができている。
ACTIVE_DEGRADED: スライスは形成されますが、ICI 復元性によってサポートされる劣化キューブが含まれます。ワークロードは実行できますが、パフォーマンスに影響する可能性があります。動的スーパースライシングは、単一の光回路スイッチ（OCS）の障害に対する耐障害性があります。1 つの OCS ユニットで障害が発生すると、そのスイッチを通過するすべての光リンクが使用できなくなり、スーパーポッド内のすべてのキューブが劣化状態で動作します。
DEACTIVATING: スライスは解体中です。
FAILED: スライスでワークロードを実行する準備ができていません。この状態は、初期形成が失敗した場合、またはアクティブなスライスで重大なソフトウェアまたはハードウェアの障害が発生した場合に発生します。
INCOMPLETE: スーパースライスの形成を開始するのに十分なキューブがありません。

Slice カスタムリソースのステータスの詳細については、Slice のステータスをご覧ください。

動的スライスでワークロードを実行する

Slice カスタムリソースが ACTIVE 状態の場合、ワークロードを実行できます。次のセクションでは、動的スライスを使用するワークロードの例を示します。ワークロードは Job または JobSet として送信されます。

例 1: 単一のワークロードが単一のスライスを使用する

次の例は、単一の 4x4x4 動的スーパースライスを使用するワークロードを示しています。

次のサンプルマニフェストを tpu-job-jax-v7x-64.yaml として保存します。

# Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-jax-v7x-64
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-jax-v7x-64
spec:
  backoffLimit: 0
  completions: 16
  parallelism: 16
  completionMode: Indexed
  template:
    metadata:
      annotations:
        cloud.google.com/gke-tpu-slice-topology: 4x4x4
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 4x4x4
        cloud.google.com/gke-tpu-accelerator: tpu7x
        cloud.google.com/gke-tpu-slice: test-slice
      subdomain: headless-svc
      restartPolicy: Never
      containers:
      - name: tpu-job-jax
        env:
        - name: TPU_ACCELERATOR_TYPE
          value: tpu7x-128
        image: python:3.12
        securityContext:
          privileged: false
        command:
        - bash
        - -c
        - |
          set -ex
          pip install -U --pre jax jaxlib libtpu requests -i https://us-python.pkg.dev/ml-oss-artifacts-published/jax/simple/ -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
          pip list
          python -c 'import jax; print("Total TPU devices (cores):", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

このマニフェストの内容:

cloud.google.com/gke-tpu-slice-topology と cloud.google.com/gke-tpu-topology は、動的スライスのトポロジを定義します。
env.value: tpu7x-128 は、TPU アクセラレータタイプとスライスのコアの合計数です。コア数は、トポロジのディメンションにチップあたりのコア数を掛けて計算されます。たとえば、4x4x4 トポロジの場合、計算は 4 × 4 × 4 × 2 = 128 になります。ここで、2 は tpu7x（Ironwood（TPU7x））のチップあたりのコア数です。したがって、TPU_ACCELERATOR_TYPE は tpu7x-128 です。

tpu-job-jax-v7x-64.yaml マニフェストを適用します。
```
kubectl apply -f tpu-job-jax-v7x-64.yaml
```

例 2: JobSet を使用してマルチスライスノードプールにワークロードをデプロイする

この例では、JobSet を使用してマルチスライスノードプールにワークロードをデプロイする方法を示します。

JobSet をインストールします。
```
kubectl apply --server-side -f https://github.com/kubernetes-sigs/jobset/releases/download/JOBSET_VERSION/manifests.yaml
```
JOBSET_VERSION は、必要な JobSet のバージョンに置き換えます。動的サブスライスには、JobSet v0.12.0 以降を使用します。動的スーパースライシングの場合は、JobSet v0.11.1 以降を使用します。

次のサンプルマニフェストを tpu-multislice-jax.yaml として保存します。

# Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu-multislice-jax
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice
spec:
  failurePolicy:
    maxRestarts: 3
  replicatedJobs:
  - name: slice-job
    replicas: 2
    template:
      spec:
        parallelism: 16
        completions: 16
        backoffLimit: 0
        completionMode: Indexed
        template:
          metadata:
            annotations:
              # The shape of the slice
              cloud.google.com/gke-tpu-slice-topology: 4x4x4
          spec:
            hostNetwork: true
            dnsPolicy: ClusterFirstWithHostNet
            nodeSelector:
              cloud.google.com/gke-tpu-topology: 4x4x4
              cloud.google.com/gke-tpu-accelerator: tpu7x
              # IMPORTANT: Do NOT put 'cloud.google.com/gke-tpu-slice' here manually.
              # The exclusive-topology annotation handles the slice assignment automatically.
            containers:
            - name: jax-worker
              image: python:3.12
              securityContext:
                privileged: true
              ports:
              - containerPort: 8471
              command:
              - bash
              - -c
              - |
                set -ex
                pip install -U --pre jax jaxlib libtpu requests -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                # Verify JobSet injected the specific slice ID for this worker
                echo "JobSet Index: $JOB_COMPLETION_INDEX"
                python -c 'import jax; print("Total TPU devices:", jax.device_count())'
              resources:
                requests:
                  google.com/tpu: 4
                limits:
                  google.com/tpu: 4

tpu-multislice-jax.yaml マニフェストを適用します。
```
kubectl apply -f tpu-multislice-jax.yaml
```
このマニフェストの内容:
- replicatedJobs の replicas: 2 フィールドは、JobSet が 2 つの個別の Job を作成し、それぞれが 4x4x4 TPU スライスに対応していることを示しています。
- alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice アノテーションは、各 Job が一意の TPU スライスに割り当てられるようにするために使用します。
- cloud.google.com/gke-tpu-slice-topology: 4x4x4 アノテーションは、各動的スライスのトポロジを定義します。
- この例では、JobSet がスライス割り当てを処理するため、TPU_ACCELERATOR_TYPE 環境変数は明示的に設定されていません。JAX コードは、割り当てられたスライス内で使用可能な TPU デバイスを自動的に検出します。
重要: cloud.google.com/gke-tpu-slice ラベルは手動で編集しないでください。

スライスを削除する

スライスを削除します。

kubectl patch slice $SLICE_NAME --type json \
  -p='[{"op": "remove", "path": "/metadata/finalizers"}]'

スライスが削除されたことを確認します。
```
kubectl get slices
```

ノードプールをアップグレードする

増分プロビジョニングで構成されたノードプールをアップグレードする場合は、容量の競合を回避するために特定のサージパラメータを使用する必要があります。

ノードプールのアップグレードを構成して実行するには:

動的スーパースライシングを使用している場合は、手動メンテナンスを実行する前にアクティブなスライスを削除します。
```
kubectl delete slice SLICE_NAME
```
動的サブスライスを使用している場合は、アクティブなスライスを先に削除する必要はありません。ただし、アップグレード中にアクティブな状態が維持されるサブスライスは失敗し、FAILED 状態に移行します。
ノードプールのアップグレードパラメータを更新します。
```
gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --location=LOCATION \
    --max-surge-upgrade=0 \
    --max-unavailable-upgrade=16
```
--max-surge-upgrade フィールドが 0 の値に設定されていることを確認します。これにより、アップグレード中に GKE が追加の TPU を割り当てようとするのを防ぐことができます。--max-unavailable-upgrade=16 フィールドを設定して、16 ノードのサブブロック全体を同時にアップグレードすることをおすすめします。

ノードプールをアップグレードします。

gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --cluster-version=CLUSTER_VERSION \
    --project=PROJECT_ID \
    --location=LOCATION

ハードウェアのメンテナンスと障害

お客様が開始したメンテナンスをトリガーした場合や、ハードウェアフェイルオーバーが発生した場合、ノードプール全体ではなく、ターゲットノードのみが影響を受けます。

動的スーパースライシングの場合、手動メンテナンスを実行する前に、アクティブな動的スライスを削除する必要があります。動的サブスライスを使用している場合は、最初にアクティブなスライスを削除する必要はありません。動的サブスライスがアクティブなときにメンテナンスやハードウェア障害が発生した場合、システムは次のように復元を処理します。

自動再シェイプ: 関連付けられたホストでメンテナンスが開始されると、GKE はアクティブな動的スライスを自動的に再シェイプします。
Slice カスタムリソースの失敗: Slice カスタムリソースが FAILED 状態に移行します。
スケジューラオブザーバビリティ: スケジューラは Slice カスタムリソースの失敗状態を監視します。
再構成プロセス: スケジューラは、他の使用可能な正常なノードでスライス構成の再作成を自動的に試みます。

スライスコントローラを無効にする

スライスコントローラを無効にするには、クラスタから削除します。

Slice カスタムリソースが空であることを確認します。
```
kubectl get slice -A
```

クラスタを更新して、スライスコントローラを無効にします。

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${REGION} \
    --no-enable-slice-controller

Slice カスタムリソースを削除します。
```
kubectl delete crd slices.accelerator.gke.io
```
Slice カスタムリソースが削除されたことを確認します。
```
kubectl get crd | grep slices.accelerator.gke.io
```
スライスコントローラによって追加されたラベルを削除します。これらのラベルを削除する必要があります。
- cloud.google.com/gke-tpu-slice
- cloud.google.com/gke-tpu-topology
1. 特定のノードから削除するには、ノード名を更新します。
```
export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl label node $NODE_NAME cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
```
1. クラスタ内のすべてのノードからこれらのラベルを削除する場合は:
```
kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
```
1. ノードラベルを確認し、空であることを確認します。
```
export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"
```

次のステップ

詳しくは、動的スライシングのコンセプトをご覧ください。
Slice カスタムリソースについて学習する。

カスタム スケジューラで動的スライスを使用する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

カスタム スケジューラで動的スライスを使用する理由

ワークフローの概要

要件

始める前に

スライス コントローラを有効にする

増分プロビジョニングでノードプールを作成する

ワークロード ポリシーの作成

ノードプールがブロックまたはサブブロックに属するようにターゲットを設定する

ブロック

サブブロック

スーパー スライスまたはサブスライスを使用して動的スライスを形成する

動的スライス パーティション

ノードとパーティションのステータスを確認する

Slice カスタム リソースを作成する

Slice カスタム リソースのステータスをモニタリングする

動的スライスでワークロードを実行する

例 1: 単一のワークロードが単一のスライスを使用する

例 2: JobSet を使用してマルチスライス ノードプールにワークロードをデプロイする

スライスを削除する

ノードプールをアップグレードする

ハードウェアのメンテナンスと障害

スライス コントローラを無効にする

次のステップ

カスタムスケジューラで動的スライスを使用する

カスタムスケジューラで動的スライスを使用する理由

スライスコントローラを有効にする

ワークロードポリシーの作成

スーパースライスまたはサブスライスを使用して動的スライスを形成する

動的スライスパーティション

Slice カスタムリソースを作成する

Slice カスタムリソースのステータスをモニタリングする

例 2: JobSet を使用してマルチスライスノードプールにワークロードをデプロイする

スライスコントローラを無効にする