Menggunakan pengirisan dinamis dengan penjadwal kustom

Dokumen ini menjelaskan cara menggunakan pengelompokan dinamis dengan berinteraksi langsung dengan resource kustom Slice. Anda dapat membuat slice, memantau status partisi, dan memverifikasi status slice.

Sebelum mengikuti petunjuk ini, pastikan Anda memahami konsep pengirisan dinamis.

Mengapa menggunakan pengirisan dinamis dengan penjadwal kustom?

Gunakan penjadwal Anda sendiri untuk mengelola resource kustom Slice jika Anda memiliki persyaratan penjadwalan yang kompleks atau jika Anda ingin mengintegrasikan pengirisan dinamis dengan infrastruktur penjadwalan yang ada.

Jika Anda lebih memilih menggunakan penjadwal daripada mengelola resource kustom Slice secara langsung, GKE menyediakan integrasi dengan Kueue dan Penjadwalan yang Mendukung Topologi (TAS). Untuk mengetahui informasi selengkapnya, lihat Menjadwalkan slice dinamis dengan Kueue dan TAS.

Ringkasan alur kerja

Untuk menggunakan pengirisan dinamis dengan penjadwal kustom, Anda akan melakukan tugas berikut dalam dokumen ini:

  1. Aktifkan pengontrol slice.
  2. Buat node pool dengan penyediaan inkremental.
  3. Buat resource kustom Slice berdasarkan persyaratan workload Anda. Terapkan resource kustom Slice ke cluster Anda.
  4. Pantau status partisi dan kondisi slice.
  5. Hapus irisan setelah selesai.

Untuk mengetahui informasi selengkapnya tentang kolom dan status resource kustom Slice, lihat informasi referensi resource kustom Slice.

Persyaratan

Untuk menggunakan pengelompokan dinamis di GKE, Anda harus memenuhi persyaratan berikut:

  • Gunakan cluster Standard di saluran Cepat dalam salah satu versi berikut:
    • Untuk konfigurasi super-slicing dinamis (topologi sama dengan atau lebih besar dari 4x4x4), gunakan versi 1.35.2-gke.1842000 atau yang lebih baru.
    • Untuk konfigurasi sub-slice dinamis (topologi yang lebih kecil dari 4x4x4), gunakan versi 1.36.0-gke.3712000 atau yang lebih baru.
  • Gunakan versi Ironwood (TPU7x).
  • Gunakan image Container-Optimized OS untuk node Anda.
  • Untuk menggunakan penyediaan inkremental, gunakan pemesanan mode Semua Kapasitas. Semua Mode kapasitas adalah fitur yang diaktifkan oleh TPU Cluster Director.
  • Untuk sub-pengirisan dinamis, pastikan node Anda memiliki peristiwa pemeliharaan tertunda. Pantau instance Anda untuk mengetahui peristiwa pemeliharaan yang tertunda. Jika ada node yang memiliki peristiwa pemeliharaan tertunda dengan waktu berakhir antara 18 September 2026 dan 30 September 2026, Anda harus memicu peristiwa pemeliharaan host secara manual di node tersebut sebelum dapat menggunakan sub-slicing.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
  • Aktifkan Google Kubernetes Engine API
  • Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.

Aktifkan pengontrol slice

Untuk menggunakan pengelompokan dinamis, aktifkan pengontrol slice di cluster Anda.

  1. Perbarui cluster Anda:

    gcloud container clusters update CLUSTER_NAME \
        --location=LOCATION \
        --enable-slice-controller
    

    Ganti kode berikut:

  2. Dapatkan kredensial agar Anda dapat berkomunikasi dengan cluster menggunakan perintah kubectl:

    gcloud config set container/cluster CLUSTER_NAME
    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION
    
  3. Di output perintah berikut, pastikan nilai slices.accelerator.gke.io ada:

    kubectl get crd slices.accelerator.gke.io
    

    Outputnya mirip dengan hal berikut ini:

    slices.accelerator.gke.io                2026-01-09T23:58:02Z
    

Membuat node pool dengan penyediaan inkremental

Bagian ini menjelaskan cara membuat kumpulan node TPU dengan penyediaan inkremental. GKE mengonversi semua kapasitas TPU Anda menjadi node pool grup 16 node VM TPU, atau sub-blok. GKE menyediakan node pool ini meskipun tidak dapat menemukan semua 16 VM yang sehat dengan menempatkan node di bagian yang sehat dari mesin host dan menyediakan mesin yang tidak sehat secara bertahap saat diperbaiki.

Anda dapat menargetkan node pool agar termasuk dalam salah satu opsi berikut:

  • Blok TPU tertentu, yang ditampilkan dalam pemesanan mode Semua Kapasitas. Penargetan blok memungkinkan GKE membuat node pool di sub-blok yang tersedia dalam blok yang ditentukan.
  • Sub-blok tertentu, atau grup 16 node tertentu dari VM TPU, untuk kontrol yang lebih terperinci.

Membuat kebijakan beban kerja

Untuk membuat node pool slice TPU dengan Ironwood (TPU7x), Anda harus membuat kebijakan workload terlebih dahulu dengan kolom accelerator-topology-mode disetel ke provision_only. Setelan ini akan memicu proses penyediaan inkremental.

Buat kebijakan beban kerja:

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

Ganti kode berikut:

  • WORKLOAD_POLICY_NAME: nama untuk kebijakan workload Anda.
  • PROJECT_ID: Google Cloud Project ID Anda.
  • REGION: region untuk kebijakan workload.

Dalam perintah ini, lakukan hal berikut:

  • Selalu setel kolom accelerator-topology ke 4x4x4 agar sesuai dengan jumlah total chip dalam satu sub-blok.
  • Selalu tetapkan kolom accelerator-topology-mode ke provision_only untuk memastikan proses penyediaan inkremental dipicu. Jika kolom provision_only ditetapkan, node pool akan menyediakan node TPU tanpa membentuk link ICI atau OCS.
.

Menargetkan node pool Anda agar termasuk dalam blok atau sub-blok

Anda dapat menargetkan sub-blok atau blok tertentu dalam reservasi mode Semua Kapasitas.

  • Menargetkan blok: setiap node pool menggunakan kapasitas dari blok tertentu. GKE menempatkan node pool dalam sub-blok yang tersedia di blok tersebut. Anda harus membuat node pool sebanyak jumlah sub-blok dalam blok yang ingin Anda gunakan.
  • Menargetkan sub-blok: setiap node pool dipetakan ke sub-blok tertentu yang tersedia. Saat menggunakan penargetan sub-blok, GKE akan membuat node pool jika setidaknya ada satu VM yang berfungsi dengan baik. Penyediaan inkremental membantu memastikan bahwa semua node ditempatkan dalam sub-blok yang ditentukan.

Blokir

  1. Untuk mengambil nama blok dalam reservasi dan jumlah sub-blok yang tersedia dalam blok, selesaikan langkah-langkah berikut dalam dokumen Melihat topologi dan status kondisi semua reservasi Mode Kapasitas:

    1. Identifikasi nama blok dengan mencantumkan semua blok reservasi dan menyalin nilai di kolom name:. Nilai ini adalah nama blok atau BLOCK_NAME dalam dokumen ini.

    2. Tentukan jumlah node pool yang akan dibuat dengan mendeskripsikan blok pemesanan dan mengidentifikasi nilai di kolom reservationSubBlockCount. Nilai ini adalah jumlah sub-blok yang tersedia. Misalnya, nilai reservationSubBlockCount: 4 menunjukkan bahwa blok memiliki empat sub-blok yang tersedia, dan Anda perlu membuat empat kumpulan node terpisah.

  2. Menetapkan jalur reservasi:

    export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME"
    

    Ganti kode berikut:

    • RESERVATION_NAME: nama reservasi TPU Anda.
    • BLOCK_NAME: nama blok.
  3. Buat node pool untuk setiap sub-blok yang diidentifikasi pada langkah sebelumnya. Misalnya, jika jumlahnya adalah 4, jalankan perintah ini empat kali. Gunakan nama unik untuk setiap node pool.

    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}
    

    Ganti kode berikut:

    • NODE_POOL_NAME: nama node pool baru.
    • CLUSTER_NAME: nama cluster GKE Anda.
    • WORKLOAD_POLICY_NAME: nama kebijakan workload yang Anda buat.
    • ZONE: zona untuk node pool, misalnya, us-central1-a.

Sub-blok

  1. Untuk mengambil nama blok dan ID sub-blok yang tersedia, selesaikan langkah-langkah berikut dalam dokumen Melihat topologi dan status kondisi reservasi Semua Mode Kapasitas:

    1. Untuk mengidentifikasi nama blok, cantumkan semua blok reservasi dan salin nilai di kolom name:. Nilai ini adalah nama blok atau BLOCK_NAME pada dokumen ini.

    2. Untuk mengidentifikasi nama sub-blok, cantumkan semua sub-blok dari suatu blok dan salin nilai di kolom name: untuk setiap entri di bagian reservationSubBlocks. Nilai ini adalah nama sub-blok atau SUBBLOCK_NAME dalam dokumen ini.

  2. Menetapkan jalur reservasi:

    export RESERVATION_PATH="projects/PROJECT_ID/reservations/RESERVATION_NAME/reservationBlocks/BLOCK_NAME/reservationSubBlocks/SUBBLOCK_NAME"
    

    Ganti kode berikut:

    • RESERVATION_NAME: nama reservasi TPU Anda.
    • BLOCK_NAME: nama blok.
    • SUBBLOCK_NAME: nama sub-blok.
  3. Buat node pool:

    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}
    

    Ganti kode berikut:

    • NODE_POOL_NAME: nama unik untuk node pool baru Anda, misalnya, sub-block-pool-1.
    • PROJECT_ID: Google Cloud Project ID Anda.
    • CLUSTER_NAME: nama cluster GKE Anda.
    • ZONE: zona untuk node pool, misalnya, us-central2-b.
    • WORKLOAD_POLICY_NAME: nama kebijakan workload yang Anda buat.

Pada tahap ini, node dibuat, tetapi link Inter-Chip Interconnect (ICI)-nya belum aktif. Oleh karena itu, Anda tidak dapat menjalankan workload di node pool ini secara langsung.

Untuk mengaktifkan semua link ICI yang diperlukan untuk membentuk slice dan memungkinkan penjadwalan beban kerja, buat slice dinamis menggunakan salah satu metode berikut:

  • Buat Slice custom resource. Sebagai ganti Pod, Anda menggunakan resource kustom Slice untuk menentukan topologi yang ditentukan, yang diaktifkan oleh pengontrol slice.
  • Menjadwalkan workload GKE dengan Kueue dan TAS. Kueue secara otomatis menangani pembuatan dan penghapusan resource kustom Slice. Hindari memodifikasi secara manual resource kustom Slice yang dibuat oleh Kueue.

Membentuk irisan dinamis dengan super-slicing atau sub-slicing

Setelah membuat node pool, Anda dapat membentuk super-slice dinamis yang lebih besar atau sub-slice dinamis yang lebih kecil dengan membuat resource kustom Slice. Resource kustom Slice menentukan topologi yang ditentukan, yang diaktifkan oleh pengontrol slice. Workload Anda kemudian dijadwalkan dan dijalankan di slice dinamis ini.

Partisi slice dinamis

Partisi menyediakan topologi yang tersedia untuk membentuk slice dinamis bagi workload Anda. Partisi menampilkan semua topologi yang tersedia untuk setiap node, termasuk 2x2x1, 2x2x2, 2x2x4, 2x4x4, dan 4x4x4. Topologi yang lebih kecil dari 4x4x4 memerlukan GKE versi 1.36.0-gke.3712000 atau yang lebih baru.

Slice yang lebih besar dari 4x4x4 tidak memiliki label partisi, karena dibuat dengan mengaitkan beberapa partisi 4x4x4.

Setiap node TPU di node pool penyediaan inkremental harus memiliki setiap label node status partisi dan ID partisi yang ditentukan.

Verifikasi status node dan partisi

  1. Untuk mendapatkan nama node dari node pool, jalankan perintah berikut:

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

    Output-nya mirip dengan berikut ini:

    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
    
  2. Verifikasi model penyediaan node:

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

    Output-nya mirip dengan berikut ini:

    cloud.google.com/gke-accelerator-topology-mode: PROVISION_ONLY
    
  3. Ambil informasi label node untuk partisi topologi yang ingin Anda targetkan:

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

    Ganti NODE_NAME dengan nama salah satu node di node pool.

    Output-nya mirip dengan berikut ini:

    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
    
  4. Verifikasi bahwa node menyertakan anotasi node.gke.io/created-by-mig:

    kubectl describe node NODE_NAME | grep "node.gke.io/created-by-mig"
    

    Ganti NODE_NAME dengan nama salah satu node di node pool.

    Output-nya mirip dengan berikut ini:

    node.gke.io/created-by-mig: projects/735972712744/zones/us-central1-ai1a/team/string
    

    Output mencakup anotasi node.gke.io/created-by-mig, yang memungkinkan bidang kontrol GKE menautkan node Kubernetes ke resource Compute Engine yang mendasarinya.

  5. Ambil informasi label node untuk status partisi topologi yang ingin Anda verifikasi:

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

    Output-nya mirip dengan berikut ini:

    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
    

    Label cloud.google.com/gke-tpu-partition-[shape]-state (dengan [shape] sesuai dengan topologi ID partisi) menunjukkan apakah partisi tersedia untuk membentuk slice dinamis. Label status ini mendukung nilai berikut:

    • HEALTHY: partisi dalam kondisi baik dan berfungsi penuh.
    • DEGRADED: partisi terganggu, tetapi masih dapat digunakan untuk pembentukan slice dinamis. Status ini hanya berlaku untuk topologi 4x4x4 tingkat teratas. Topologi yang lebih kecil tidak memiliki status yang menurun.
    • UNHEALTHY: partisi tidak berfungsi dan tidak dapat digunakan untuk membentuk slice.
    • UNSET: status tidak ditentukan karena inisialisasi pengontrol slice GKE tidak berhasil.
    • INCOMPLETE: tidak semua node dalam partisi disediakan.

Membuat resource kustom Slice

Resource kustom Slice sedikit berbeda bergantung pada apakah Anda membuat super-slice dinamis atau sub-slice dinamis.

  1. Tentukan resource kustom 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
    

    Ganti kode berikut:

    • SLICE_NAME: nama untuk irisan Anda. Nama harus memenuhi kondisi metadata.name dan panjangnya maksimal 49 karakter.
    • TOPOLOGY: topologi untuk slice dinamis. Topologi harus memenuhi kondisi berikut:
      • Untuk sub-pengirisan dinamis: Anda dapat menentukan topologi yang lebih kecil dari 4x4x4, seperti 2x2x1, 2x2x2, 2x2x4, atau 2x4x4. Topologi yang lebih kecil ini memerlukan GKE versi 1.36.0-gke.3712000 atau yang lebih baru.
      • Untuk super-slicing dinamis: Anda dapat menentukan topologi yang sama dengan atau lebih besar dari 4x4x4. Untuk mengonfigurasi super-slicing dinamis, setiap dimensi topologi yang diminta harus kelipatan empat, misalnya 4A x 4B x 4C. Tiga nilai dalam dimensi topologi, AxBxC, harus dalam urutan tidak menurun (A ≤ B ≤ C). Misalnya, 4x4x8 valid, tetapi 4x8x4 tidak. Urutan ini membantu memastikan pembentukan slice yang konsisten dan menghindari perilaku yang tidak terduga. Hasil perkalian ketiga nilai dalam dimensi topologi, A × B × C,tidak boleh melebihi 9.216.
    • PARTITION_ID: daftar string yang mengidentifikasi partisi yang membentuk slice.
      • Untuk sub-pengirisan dinamis: Anda harus menentukan tepat satu ID partisi.
      • Untuk super-slicing dinamis: Anda harus menghitung jumlah partisi berdasarkan jumlah total chip, dengan setiap partisi terdiri dari 64 chip. Jumlah item dalam daftar spec.partitionIds harus sama persis dengan jumlah partisi yang dihitung ((A × B × C) / 64).
      • Daftar partitionIds harus memenuhi kondisi berikut:
        • Setiap partisi harus dipetakan ke sub-blok reservasi.
        • Semua sub-blok terkait harus termasuk dalam pemesanan yang sama.
        • Semua sub-blok terkait harus berada dalam reservasi yang sama.
        • Kumpulan node terkait harus memiliki semua node dalam status ready.
    • Nilai kolom type harus tpu7x.
    • Jika ingin mengaktifkan pengontrol slice untuk mencoba ulang secara otomatis selama pembentukan slice, Anda dapat menambahkan anotasi slice.gke.io/retry-on-failure: "true" ke resource kustom slice. Jika slice tidak dibuat karena alasan status SliceCreationFailed, pengontrol akan mencoba lagi hingga slice berhasil dibuat.

    Misalnya, untuk membuat slice 4x8x8 (super-slicing dinamis), Anda harus memberikan empat ID partisi unik.

    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"
    

    Misalnya, untuk membuat slice 2x2x2 (sub-slicing dinamis), Anda harus memberikan satu ID partisi unik.

    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
    
  2. Terapkan resource kustom Slice:

    kubectl apply -f test-slice-example.yaml
    

    Pada tahap ini, GKE mencoba membuat slice. Jika salah satu masalah berikut terjadi, pembuatan slice akan gagal, dan alasan status di resource kustom Slice akan diperbarui menjadi SliceCreationFailed atau FAILED:

    • Jika node yang dipilih di resource kustom tidak ada, alasan statusnya adalah SliceCreationFailed.
    • Jika ada node pada resource kustom yang digunakan oleh slice lain, alasan statusnya adalah SliceCreationFailed.
    • Jika node pada resource kustom bukan bagian dari sub-blok reservasi yang sama, alasan statusnya adalah FAILED.
    • Jika node tidak berada dalam reservasi yang sama, alasan statusnya adalah FAILED.
    • Jika topologi tidak cocok dengan jumlah partisi, alasan statusnya adalah SliceCreationFailed.

    Untuk mencoba kembali pembentukan slice secara otomatis saat statusnya SliceCreationFailed, konfigurasi anotasi slice.gke.io/retry-on-failure: "true" seperti yang dijelaskan dalam Membuat resource kustom Slice.

    Untuk mempelajari lebih lanjut status resource kustom Slice, lihat Status slice.

Memantau status resource kustom Slice

Untuk memeriksa status resource kustom Slice, jalankan perintah berikut:

kubectl describe slice SLICE_NAME

Ganti SLICE_NAME dengan nama slice.

Outputnya mirip dengan hal berikut ini:

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:

Kolom reason dalam status resource kustom Slice menunjukkan status siklus proses saat ini. Kemungkinan status bervariasi, bergantung pada apakah Anda menggunakan sub-slice dinamis atau super-slice dinamis.

Kondisi status untuk sub-pengelompokan dinamis

  • SliceNotCreated: pengontrol melakukan inisialisasi dan pemeriksaan resource.
    • Jika prasyarat tidak terpenuhi, status akan bertransisi ke SliceCreationFailed.
    • Jika validasi lulus, status akan bertransisi ke ACTIVATING.
  • ACTIVATING: GKE sedang membentuk slice.
    • Jika berhasil, status akan bertransisi ke ACTIVE.
    • Jika sub-blok mengalami penurunan kualitas, tetapi slice dapat digunakan, status akan bertransisi ke ACTIVE_DEGRADED.
    • Jika pembentukan gagal, status akan bertransisi ke FAILED.
  • DEACTIVATING: jika resource kustom Slice dihapus atau terjadi kegagalan kritis dalam status aktif atau gagal, slice akan mulai dibongkar.
  • INCOMPLETE: langkah terakhir sebelum resource dihapus sepenuhnya.

Kondisi status untuk super-pengirisan dinamis

  • SliceNotCreated: irisan belum dibuat. Pengontrol slice sedang melakukan inisialisasi dan pemeriksaan awal untuk pembentukan slice.
  • SliceCreationFailed: pembuatan gagal karena prasyarat tidak terpenuhi (misalnya, resource Compute Engine yang diperlukan tidak ada) atau pemeriksaan awal gagal. Untuk mencoba lagi pembentukan slice secara otomatis dalam status ini, konfigurasi anotasi slice.gke.io/retry-on-failure: "true".
  • ACTIVATING: slice sedang dalam proses dibentuk (digabungkan).
  • ACTIVE: slice terbentuk sepenuhnya, responsif, dan siap menjalankan workload.
  • ACTIVE_DEGRADED: slice dibentuk, tetapi mencakup kubus yang mengalami penurunan kualitas, didukung oleh ketahanan ICI. Workload dapat berjalan, tetapi performa mungkin terpengaruh. Super-slicing dinamis tahan terhadap kegagalan switch sirkuit optik (OCS) tunggal. Jika satu unit OCS gagal, semua link optik yang melintasi switch tersebut akan menjadi tidak tersedia, yang menyebabkan semua kubus dalam superpod beroperasi dalam kondisi yang menurun.
  • DEACTIVATING: slice sedang dalam proses dibongkar.
  • FAILED: slice tidak lagi siap untuk menjalankan workload. Status ini terjadi jika pembentukan awal gagal atau jika slice aktif mengalami kegagalan software atau hardware yang kritis.
  • INCOMPLETE: tidak ada cukup kubus yang tersedia untuk memulai pembentukan super-slice.

Untuk mempelajari lebih lanjut status resource kustom Slice, lihat Status slice.

Menjalankan workload pada pengirisan dinamis

Saat resource kustom Slice dalam status ACTIVE, Anda dapat menjalankan workload di dalamnya. Bagian berikut menyertakan contoh workload yang menggunakan pengelompokan dinamis. Workload dikirimkan sebagai Tugas atau JobSet.

Contoh 1: satu workload menggunakan satu slice

Contoh berikut menunjukkan beban kerja yang menggunakan satu super-slice dinamis 4x4x4.

  1. Simpan manifes contoh berikut sebagai 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
    

    Dalam manifes ini:

    • cloud.google.com/gke-tpu-slice-topology dan cloud.google.com/gke-tpu-topology menentukan topologi slice dinamis.
    • env.value: tpu7x-128 adalah jenis akselerator TPU dan jumlah total inti dalam slice. Jumlah core dihitung dengan mengalikan dimensi topologi dengan jumlah core per chip. Misalnya, untuk topologi 4x4x4, perhitungannya adalah 4 × 4 × 4 × 2 = 128, dengan 2 adalah jumlah core per chip untuk tpu7x (Ironwood (TPU7x)). Oleh karena itu, TPU_ACCELERATOR_TYPE adalah tpu7x-128.
  2. Terapkan manifes tpu-job-jax-v7x-64.yaml:

    kubectl apply -f tpu-job-jax-v7x-64.yaml
    

Contoh 2: men-deploy workload pada kumpulan node multislice menggunakan JobSet

Contoh ini menunjukkan cara men-deploy workload di kumpulan node multislice menggunakan JobSet.

  1. Instal JobSet:

    kubectl apply --server-side -f https://github.com/kubernetes-sigs/jobset/releases/download/JOBSET_VERSION/manifests.yaml
    

    Ganti JOBSET_VERSION dengan versi JobSet yang diperlukan. Untuk sub-pengirisan dinamis, gunakan JobSet v0.12.0 atau yang lebih baru. Untuk super-slicing dinamis, gunakan JobSet v0.11.1 atau yang lebih baru.

  2. Simpan manifes contoh berikut sebagai 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
    
  3. Terapkan manifes tpu-multislice-jax.yaml:

    kubectl apply -f tpu-multislice-jax.yaml
    

    Dalam manifes ini:

    • Kolom replicas: 2 di bagian replicatedJobs menunjukkan bahwa JobSet membuat dua Tugas terpisah, yang masing-masing sesuai dengan slice TPU 4x4x4.
    • Anotasi alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice membantu memastikan bahwa setiap Tugas ditetapkan ke slice TPU yang unik.
    • Anotasi cloud.google.com/gke-tpu-slice-topology: 4x4x4 menentukan topologi setiap slice dinamis.
    • Variabel lingkungan TPU_ACCELERATOR_TYPE tidak ditetapkan secara eksplisit dalam contoh ini, karena JobSet menangani penetapan slice. Kode JAX secara otomatis mendeteksi perangkat TPU yang tersedia dalam slice yang ditetapkan.

Menghapus irisan

  1. Hapus slice:

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

    kubectl get slices
    

Mengupgrade node pool

Jika mengupgrade node pool yang dikonfigurasi dengan penyediaan inkremental, Anda harus menggunakan parameter lonjakan tertentu untuk mencegah konflik kapasitas.

Untuk mengonfigurasi dan menjalankan upgrade node pool:

  1. Jika Anda menggunakan super-slicing dinamis, hapus slice aktif Anda sebelum menjalankan pemeliharaan manual:

    kubectl delete slice SLICE_NAME
    

    Jika Anda menggunakan sub-pengirisan dinamis, Anda tidak perlu menghapus irisan aktif terlebih dahulu. Namun, sub-slice yang tetap aktif selama upgrade akan gagal dan bertransisi ke status FAILED.

  2. Perbarui parameter upgrade untuk node pool Anda:

    gcloud container node-pools update NODE_POOL_NAME \
        --cluster=CLUSTER_NAME \
        --project=PROJECT_ID \
        --location=LOCATION \
        --max-surge-upgrade=0 \
        --max-unavailable-upgrade=16
    

    Pastikan kolom --max-surge-upgrade disetel ke nilai 0 untuk mencegah GKE mencoba mengalokasikan TPU tambahan selama upgrade. Sebaiknya setel kolom --max-unavailable-upgrade=16 ke mengupgrade sub-blok 16 node secara bersamaan.

  3. Upgrade node pool:

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

Pemeliharaan dan kegagalan hardware

Jika Anda memicu pemeliharaan yang dimulai pelanggan atau jika terjadi failover hardware, hanya node yang ditargetkan yang terpengaruh, bukan seluruh node pool.

Untuk super-pengirisan dinamis, Anda harus menghapus irisan dinamis aktif sebelum menjalankan pemeliharaan manual. Jika Anda menggunakan sub-pengirisan dinamis, Anda tidak perlu menghapus irisan aktif terlebih dahulu. Jika pemeliharaan atau kegagalan hardware terjadi saat sub-slice dinamis aktif, sistem akan menangani pemulihan sebagai berikut:

  1. Pembentukan ulang otomatis: GKE secara otomatis membentuk ulang slice dinamis aktif saat pemeliharaan dimulai di host terkait.
  2. Kegagalan resource kustom slice: resource kustom slice bertransisi ke status FAILED.
  3. Pengamatan penjadwal: penjadwal mengamati status gagal resource kustom Slice.
  4. Proses reformasi: penjadwal otomatis mencoba membuat ulang konfigurasi slice pada node lain yang berfungsi dengan baik.

Menonaktifkan Pengontrol Slice

Untuk menonaktifkan pengontrol slice, hapus pengontrol dari cluster.

  1. Periksa apakah resource kustom Slice kosong:

    kubectl get slice -A
    
  2. Perbarui cluster untuk menonaktifkan pengontrol slice:

    gcloud container clusters update ${CLUSTER_NAME} \
        --location=${REGION} \
        --no-enable-slice-controller
    
  3. Hapus resource kustom Slice :

    kubectl delete crd slices.accelerator.gke.io
    
  4. Pastikan resource kustom Slice dihapus:

    kubectl get crd | grep slices.accelerator.gke.io
    
  5. Menghapus label yang ditambahkan oleh pengontrol irisan. Perlu menghapus label ini:

    • cloud.google.com/gke-tpu-slice
    • cloud.google.com/gke-tpu-topology
    1. Untuk menghapus dari node tertentu, perbarui nama node
    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. Jika Anda ingin menghapus label ini dari setiap node di cluster Anda:
    kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    
    1. Periksa label node dan pastikan label tersebut kosong:
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
    kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"
    

Langkah berikutnya