Utilizzare la suddivisione dinamica con uno scheduler personalizzato

Questo documento descrive come utilizzare la suddivisione dinamica interagendo direttamente con le risorse personalizzate di suddivisione. Puoi creare slice, monitorare gli stati delle partizioni e verificare l'integrità delle slice.

Prima di seguire queste istruzioni, assicurati di aver compreso i concetti di slicing dinamico.

Perché utilizzare la suddivisione dinamica con uno strumento di pianificazione personalizzato?

Utilizza il tuo scheduler per gestire le risorse personalizzate di Slice se hai requisiti di pianificazione complessi o se vuoi integrare lo slicing dinamico con l'infrastruttura di pianificazione esistente.

Se preferisci utilizzare uno scheduler anziché gestire direttamente le risorse personalizzate Slice, GKE fornisce l'integrazione con Kueue e Topology Aware Scheduling (TAS). Per saperne di più, consulta Pianifica sezioni dinamiche con Kueue e TAS.

Panoramica del flusso di lavoro

Per utilizzare lo slicing dinamico con uno scheduler personalizzato, esegui le seguenti attività in questo documento:

  1. Attiva il controller delle sezioni.
  2. Crea node pool con provisioning incrementale.
  3. Crea risorse personalizzate Slice in base ai requisiti del tuo workload. Applica la risorsa personalizzata Slice al tuo cluster.
  4. Monitora gli stati delle partizioni e l'integrità degli slice.
  5. Elimina la sezione quando hai finito.

Per saperne di più sui campi e sullo stato della risorsa personalizzata Slice, consulta le informazioni di riferimento sulla risorsa personalizzata Slice.

Requisiti

Per utilizzare la suddivisione dinamica in GKE, devi soddisfare i seguenti requisiti:

  • Utilizza un cluster Standard nel canale rapido in una delle seguenti versioni:
    • Per la configurazione del super-slicing dinamico (topologie uguali o superiori a 4x4x4), utilizza la versione 1.35.2-gke.1842000 o successiva.
    • Per la configurazione della suddivisione dinamica (topologie più piccole di 4x4x4), utilizza la versione 1.36.0-gke.3712000 o successive.
  • Utilizza la versione Ironwood (TPU7x).
  • Utilizza l'immagine Container-Optimized OS per i tuoi nodi.
  • Per utilizzare il provisioning incrementale, utilizza le prenotazioni in modalità Tutta la capacità. La modalità di capacità All è una funzionalità abilitata da TPU Cluster Director.
  • Per la suddivisione secondaria dinamica, assicurati che i nodi abbiano eventi di manutenzione in attesa. Monitora le istanze per individuare eventuali eventi di manutenzione in attesa. Se uno dei tuoi nodi ha un evento di manutenzione in attesa con un'ora di fine compresa tra il 18 settembre 2026 e il 30 settembre 2026, devi attivare manualmente l'evento di manutenzione dell'host su questi nodi prima di poter utilizzare la suddivisione in sezioni.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
    • Abilita l'API Google Kubernetes Engine
  • Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Attivare il controller delle sezioni

Per utilizzare lo slicing dinamico, attiva il controller di slice nel cluster.

  1. Aggiorna il cluster:

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

    Sostituisci quanto segue:

  2. Recupera le credenziali per comunicare con il cluster con i comandi kubectl:

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

  3. Nell'output del comando seguente, verifica che il valore slices.accelerator.gke.io sia presente:

    kubectl get crd slices.accelerator.gke.io

    L'output è simile al seguente:

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

Crea node pool con provisioning incrementale

Questa sezione descrive come creare i pool di nodi TPU con provisioning incrementale. GKE converte tutta la capacità TPU in pool di nodi di un gruppo di 16 nodi di VM TPU o blocchi secondari. GKE esegue il provisioning di questi node pool anche quando non riesce a trovare tutte le 16 VM integre posizionando i nodi sulle parti integre della macchina host ed eseguendo il provisioning incrementale delle macchine non integre durante la riparazione.

Puoi impostare come target del pool di nodi uno dei seguenti elementi:

  • Un blocco specifico di TPU, esposto nelle prenotazioni in modalità Tutta la capacità. Il targeting dei blocchi consente a GKE di creare il pool di nodi in qualsiasi blocco secondario disponibile all'interno del blocco specificato.
  • Un sottoblocco specifico o un gruppo specifico di 16 nodi di VM TPU, per un controllo più granulare.

Crea una policy del workload

Per creare un pool di nodi di slice TPU con Ironwood (TPU7x), devi prima creare una policy del workload con il campo accelerator-topology-mode impostato su provision_only. Questa impostazione attiva la procedura di provisioning incrementale.

Crea una policy del workload:

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

Sostituisci quanto segue:

  • WORKLOAD_POLICY_NAME: un nome per la policy del carico di lavoro.
  • PROJECT_ID: il tuo ID progetto Google Cloud .
  • REGION: la regione della policy del workload.

In questo comando, esegui le seguenti operazioni:

  • Imposta sempre il campo accelerator-topology su 4x4x4 in modo che corrisponda al numero totale di chip all'interno di un singolo sottoblocco.
  • Imposta sempre il campo accelerator-topology-mode su provision_only per assicurarti che il processo di provisioning incrementale venga attivato. Quando il campo provision_only è impostato, il pool di nodi esegue il provisioning dei nodi TPU senza formare collegamenti ICI o OCS.

Imposta come target il tuo pool di nodi in modo che appartenga a un blocco o a un sottoblocco

Puoi scegliere come target blocchi o sottoblocchi specifici all'interno della prenotazione in modalità Tutta la capacità.

  • Target di un blocco:ogni pool di nodi utilizza la capacità di un blocco specificato. GKE inserisce ilpool di nodil all'interno di un blocco secondario disponibile in quel blocco. Devi creare tanti pool di nodi quanti sono i sottoblocchi nel blocco che vuoi utilizzare.

  • Target di un sottoblocco:ogni pool di nodi viene mappato a un sottoblocco specifico e disponibile. Quando utilizzi il targeting a livello di sottoblocco, GKE crea il pool di nodi se almeno una VM è integra. Il provisioning incrementale contribuisce a garantire che tutti i nodi vengano posizionati all'interno del sottoblocco specificato.

Blocca

  1. Per recuperare il nome del blocco in una prenotazione e il conteggio dei sottoblocchi disponibili nel blocco, completa i seguenti passaggi nel documento Visualizzare la topologia e lo stato di integrità delle prenotazioni in modalità Tutta la capacità:

    1. Identifica il nome del blocco elencando tutti i blocchi di prenotazione e copiando il valore nel campo name:. Questo valore è il nome del blocco o di BLOCK_NAME in questo documento.

    2. Determina il numero di pool di nodi da creare descrivendo un blocco di prenotazione e identificando il valore nel campo reservationSubBlockCount. Questo valore indica il numero di blocchi secondari disponibili. Ad esempio, il valore reservationSubBlockCount: 4 indica che il blocco ha quattro blocchi secondari disponibili e che devi creare quattro pool di nodi separati.

  2. Imposta il percorso di prenotazione:

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

    Sostituisci quanto segue:

    • RESERVATION_NAME: il nome della prenotazione TPU.
    • BLOCK_NAME: il nome del blocco.

  3. Crea un pool di nodi per ogni sottoblocco identificato nel passaggio precedente. Ad esempio, se il conteggio è 4, esegui questo comando quattro volte. Utilizza un nome univoco per ogni pool di nodi.

    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}

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del nuovo pool di nodi.
    • CLUSTER_NAME: il nome del tuo cluster GKE.
    • WORKLOAD_POLICY_NAME: il nome della policy del workload che hai creato.
    • ZONE: la zona del pool di nodi, ad esempio us-central1-a.

Blocco secondario

  1. Per recuperare il nome del blocco e gli ID dei sottoblocchi disponibili, completa i seguenti passaggi nel documento Visualizzare la topologia e lo stato di integrità di tutte le prenotazioni in modalità All Capacity Mode:

    1. Per identificare il nome del blocco, elenca tutti i blocchi di prenotazione e copia il valore nel campo name:. Questo valore è il nome del blocco o di BLOCK_NAME in questo documento.

    2. Per identificare il nome dei blocchi secondari, elenca tutti i blocchi secondari di un blocco e copia il valore nel campo name: per ogni voce in reservationSubBlocks. Questo valore è il nome del sottoblocco o SUBBLOCK_NAME in questo documento.

  2. Imposta il percorso di prenotazione:

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

    Sostituisci quanto segue:

    • RESERVATION_NAME: il nome della prenotazione TPU.
    • BLOCK_NAME: il nome del blocco.
    • SUBBLOCK_NAME: il nome del sottoblocco.

  3. Crea il pool di nodi:

    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}

    Sostituisci quanto segue:

    • NODE_POOL_NAME: un nome univoco per il nuovo pool di nodi, ad esempio sub-block-pool-1.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • CLUSTER_NAME: il nome del tuo cluster GKE.
    • ZONE: la zona del pool di nodi, ad esempio us-central2-b.
    • WORKLOAD_POLICY_NAME: il nome della policy del carico di lavoro che hai creato.

In questa fase, i nodi vengono creati, ma i loro collegamenti Inter-Chip Interconnect (ICI) non sono ancora attivi. Pertanto, non puoi eseguire direttamente i carichi di lavoro su questi node pool.

Per attivare tutti i collegamenti ICI necessari per formare la sezione e consentire la pianificazione dei carichi di lavoro, crea una sezione dinamica utilizzando uno dei seguenti metodi:

  • Crea una risorsa personalizzata Slice. Anziché i pod, utilizzi una risorsa personalizzata Slice per definire la topologia specificata, che viene attivata dal controller della sezione.
  • Pianifica i workload GKE con Kueue e TAS. Kueue gestisce automaticamente la creazione e l'eliminazione delle risorse personalizzate Slice. Evita di modificare manualmente le risorse personalizzate Slice create da Kueue.

Formare una sezione dinamica con la suddivisione o la suddivisione secondaria

Dopo aver creato i node pool, puoi formare un super-slice dinamico più grande o un sub-slice dinamico più piccolo creando una risorsa personalizzata Slice. Una risorsa personalizzata Slice definisce la topologia specificata, che viene attivata dal controller delle sezioni. I tuoi workload vengono quindi pianificati ed eseguiti su questa sezione dinamica.

Partizioni di slicing dinamico

Le partizioni forniscono le topologie disponibili per formare una sezione dinamica per i tuoi workload. Una partizione mostra tutte le topologie disponibili per ogni nodo, tra cui 2x2x1, 2x2x2, 2x2x4, 2x4x4 e 4x4x4. Le topologie più piccole di 4x4x4 richiedono GKE 1.36.0-gke.3712000 o versioni successive.

Qualsiasi sezione superiore a 4x4x4 non ha un'etichetta di partizione, poiché viene creata associando più partizioni 4x4x4.

Ogni nodo TPU in un pool di nodi di provisioning incrementale deve possedere ogni etichetta del nodo ID partizione e stato partizione specificata.

Verifica lo stato dei nodi e delle partizioni

  1. Per ottenere i nomi dei nodi dal pool di nodi, esegui questo comando:

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

    Il risultato è simile al seguente:

    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. Verifica il modello di provisioning del nodo:

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

    Il risultato è simile al seguente:

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

  3. Recupera le informazioni sull'etichetta del nodo per la partizione della topologia che vuoi scegliere come target:

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

    Sostituisci NODE_NAME con il nome di uno dei nodi nel pool di nodi.

    Il risultato è simile al seguente:

    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. Verifica che il nodo includa l'annotazione node.gke.io/created-by-mig:

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

    Sostituisci NODE_NAME con il nome di uno dei nodi nel pool di nodi.

    Il risultato è simile al seguente:

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

    L'output include l'annotazione node.gke.io/created-by-mig, che consente al piano di controllo GKE di collegare i nodi Kubernetes alle risorse Compute Engine sottostanti.

  5. Recupera le informazioni sull'etichetta del nodo per lo stato della partizione della topologia che vuoi verificare:

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

    Il risultato è simile al seguente:

    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

    L'etichetta cloud.google.com/gke-tpu-partition-[shape]-state (dove [shape] corrisponde alla topologia dell'ID partizione) indica se la partizione è disponibile per formare una sezione dinamica. Questa etichetta di stato supporta i seguenti valori:

    • HEALTHY: la partizione è integra e completamente funzionante.
    • DEGRADED: la partizione è compromessa, ma è ancora utilizzabile per la formazione di slice dinamici. Questo stato si applica solo alla topologia 4x4x4 di primo livello. Le topologie più piccole non hanno uno stato di funzionamento ridotto.
    • UNHEALTHY: la partizione non funziona correttamente e non può essere utilizzata per formare una fetta.
    • UNSET: lo stato non è definito a causa di un'inizializzazione non riuscita del controller degli slice GKE.
    • INCOMPLETE: non tutti i nodi all'interno della partizione vengono sottoposti al provisioning.

Crea una risorsa personalizzata Slice

La risorsa personalizzata Slice varia leggermente a seconda che tu stia creando una superslice dinamica o una sottosezione dinamica.

  1. Definisci la risorsa personalizzata 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

    Sostituisci quanto segue:

    • SLICE_NAME: un nome per la tua sezione. Il nome deve soddisfare le condizioni metadata.name e deve contenere al massimo 49 caratteri.
    • TOPOLOGY: la topologia della sezione dinamica. La topologia deve soddisfare le seguenti condizioni:
      • Per il sub-slicing dinamico: puoi specificare topologie più piccole di 4x4x4, ad esempio 2x2x1, 2x2x2, 2x2x4 o 2x4x4. Queste topologie più piccole richiedono GKE 1.36.0-gke.3712000 o versioni successive.
      • Per la suddivisione dinamica, puoi specificare topologie uguali o superiori a 4x4x4. Per configurare la super-suddivisione dinamica, ogni dimensione della topologia richiesta deve essere un multiplo di quattro, ad esempio 4A x 4B x 4C. I tre valori nelle dimensioni della topologia, AxBxC, devono essere in ordine non decrescente (A ≤ B ≤ C). Ad esempio, 4x4x8 è valido, ma 4x8x4 no. Questo ordine contribuisce a garantire una formazione coerente delle sezioni ed evita comportamenti imprevisti. Il prodotto dei tre valori nelle dimensioni della topologia, A × B × C,non deve superare 9216.
    • PARTITION_ID: un elenco di stringhe che identificano le partizioni che compongono la sezione.
      • Per la suddivisione dinamica, devi specificare esattamente un ID partizione.
      • Per la suddivisione dinamica: devi calcolare il numero di partizioni in base al numero totale di chip, dove ogni partizione è costituita da 64 chip. Il numero di elementi nell'elenco spec.partitionIds deve corrispondere esattamente al numero calcolato di partizioni ((A × B × C) / 64).
      • L'elenco partitionIds deve soddisfare le seguenti condizioni:
        • Ogni partizione deve essere mappata a un sottoblocco di prenotazione.
        • Tutti i blocchi secondari associati devono appartenere alla stessa prenotazione.
        • Tutti i blocchi secondari associati devono trovarsi all'interno della stessa prenotazione.
        • Tutti i nodi dei pool di nodi associati devono essere nello stato ready.
    • Il valore del campo type deve essere tpu7x.
    • (Facoltativo) Per consentire al controller delle sezioni di riprovare automaticamente durante la formazione delle sezioni, puoi aggiungere l'annotazione slice.gke.io/retry-on-failure: "true" alla risorsa personalizzata della sezione. Se la sezione non viene creata a causa del motivo dello stato SliceCreationFailed, il controller riproverà finché la sezione non verrà formata correttamente.

    Ad esempio, per creare una sezione 4x8x8 (super-slicing dinamico), devi fornire quattro ID partizione univoci.

    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"

    Ad esempio, per creare una sezione 2x2x2 (suddivisione dinamica in sezioni), devi fornire un ID partizione univoco.

    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. Applica la risorsa personalizzata Slice:

    kubectl apply -f test-slice-example.yaml

    A questo punto, GKE tenta di creare lo slice. Se si verifica uno dei seguenti problemi, la creazione della sezione non va a buon fine e il motivo dello stato nella risorsa personalizzata Slice viene aggiornato a SliceCreationFailed o FAILED:

    • Se i nodi selezionati nella risorsa personalizzata non esistono, il motivo dello stato è SliceCreationFailed.
    • Se alcuni nodi della risorsa personalizzata vengono utilizzati da un'altra sezione, il motivo dello stato è SliceCreationFailed.
    • Se i nodi della risorsa personalizzata non fanno parte dello stesso blocco secondario di prenotazione, il motivo dello stato è FAILED.
    • Se i nodi non si trovano nella stessa prenotazione, il motivo dello stato è FAILED.
    • Se la topologia non corrisponde al numero di partizioni, il motivo dello stato è SliceCreationFailed.

    Per riprovare automaticamente la formazione delle sezioni quando lo stato è SliceCreationFailed, configura l'annotazione slice.gke.io/retry-on-failure: "true" come descritto in Crea una risorsa personalizzata Slice.

    Per saperne di più sullo stato della risorsa personalizzata Slice, consulta Stato di Slice.

Monitorare lo stato della risorsa personalizzata Slice

Per controllare lo stato della risorsa personalizzata Slice, esegui questo comando:

kubectl describe slice SLICE_NAME

Sostituisci SLICE_NAME con il nome della sezione.

L'output è simile al seguente:

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:

Il campo reason nello stato della risorsa personalizzata Slice indica lo stato del ciclo di vita attuale. Gli stati possibili variano a seconda che tu stia utilizzando la suddivisione dinamica o la suddivisione dinamica avanzata.

Condizioni di stato per la suddivisione dinamica

  • SliceNotCreated: il controller esegue l'inizializzazione e i controlli delle risorse.
    • Se i prerequisiti non sono soddisfatti, lo stato passa a SliceCreationFailed.
    • Se la convalida ha esito positivo, lo stato passa a ACTIVATING.
  • ACTIVATING: GKE sta formando la sezione.
    • In caso di esito positivo, lo stato passa a ACTIVE.
    • Se i blocchi secondari hanno prestazioni ridotte, ma lo slice è utilizzabile, lo stato passa a ACTIVE_DEGRADED.
    • Se la formazione non riesce, lo stato passa a FAILED.
  • DEACTIVATING: se la risorsa personalizzata Slice viene eliminata o si verifica un errore critico in uno stato attivo o non riuscito, lo slice inizia a essere smantellato.
  • INCOMPLETE: il passaggio finale prima dell'eliminazione completa della risorsa.

Condizioni di stato per la suddivisione dinamica avanzata

  • SliceNotCreated: la sezione non è ancora stata creata. Il controller dello slice sta inizializzando ed eseguendo i controlli preflight per la formazione dello slice.
  • SliceCreationFailed: la creazione non è riuscita perché i prerequisiti non sono stati soddisfatti (ad esempio, mancano le risorse Compute Engine richieste) o i controlli preliminari non sono riusciti. Per riprovare automaticamente la creazione dello slice in questo stato, configura l'annotazione slice.gke.io/retry-on-failure: "true".
  • ACTIVATING: la sezione è in fase di formazione (unione).
  • ACTIVE: la sezione è completamente formata, integra e pronta per l'esecuzione dei carichi di lavoro.
  • ACTIVE_DEGRADED: la sezione viene formata, ma include cubi con prestazioni ridotte, supportati dalla resilienza ICI. I carichi di lavoro possono essere eseguiti, ma le prestazioni potrebbero essere influenzate. Il super-slicing dinamico è resiliente agli errori di un singolo switch di circuito ottico (OCS). Se una singola unità OCS non funziona, tutti i collegamenti ottici che attraversano lo switch diventano non disponibili, il che fa sì che tutti i cubi all'interno del superpod funzionino in uno stato degradato.
  • DEACTIVATING: la sezione è in fase di smantellamento.
  • FAILED: la sezione non è più pronta per eseguire i workload. Questo stato si verifica se la formazione iniziale non è riuscita o se una sezione attiva ha subito un errore software o hardware critico.
  • INCOMPLETE: non sono disponibili cubi sufficienti per avviare la formazione di un super-slice.

Per scoprire di più sullo stato della risorsa personalizzata Slice, consulta Stato di Slice.

Esegui carichi di lavoro sullo slicing dinamico

Quando la risorsa personalizzata Slice è nello stato ACTIVE, puoi eseguirvi carichi di lavoro. La sezione seguente include esempi di carichi di lavoro che utilizzano lo slicing dinamico. I workload vengono inviati come job o JobSet.

Esempio 1: un singolo workload utilizza una singola sezione

L'esempio seguente mostra un workload che utilizza una singola superslice dinamica 4x4x4.

  1. Salva il seguente manifest di esempio come 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

    In questo manifest:

    • cloud.google.com/gke-tpu-slice-topology e cloud.google.com/gke-tpu-topology definiscono la topologia della sezione dinamica.
    • env.value: tpu7x-128 è il tipo di acceleratore TPU e il numero totale di core nella sezione. Il numero di core viene calcolato moltiplicando le dimensioni della topologia per il numero di core per chip. Ad esempio, per una topologia 4x4x4, il calcolo è 4 × 4 × 4 × 2 = 128, dove 2 è il numero di core per chip per tpu7x (Ironwood (TPU7x)). Pertanto, il TPU_ACCELERATOR_TYPE è tpu7x-128.

  2. Applica il manifest tpu-job-jax-v7x-64.yaml:

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

Esempio 2: esegui il deployment di un workload su node pool multislice utilizzando JobSet

Questo esempio mostra come eseguire il deployment di un carico di lavoro sui node pool multislice utilizzando JobSet.

  1. Installa JobSet:

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

    Sostituisci JOBSET_VERSION con la versione richiesta di JobSet. Per il sub-slicing dinamico, utilizza JobSet v0.12.0 o versioni successive. Per il super-slicing dinamico, utilizza JobSet v0.11.1 o versioni successive.

  2. Salva il seguente manifest di esempio come 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. Applica il manifest tpu-multislice-jax.yaml:

    kubectl apply -f tpu-multislice-jax.yaml

    In questo manifest:

    • Il campo replicas: 2 in replicatedJobs indica che JobSet crea due job separati, ognuno corrispondente a una fetta di TPU 4x4x4.
    • L'annotazione alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice contribuisce a garantire che ogni job venga assegnato a uno slice TPU univoco.
    • L'annotazione cloud.google.com/gke-tpu-slice-topology: 4x4x4 definisce la topologia di ogni slice dinamica.
    • La variabile di ambiente TPU_ACCELERATOR_TYPE non è impostata in modo esplicito in questo esempio, poiché JobSet gestisce l'assegnazione delle sezioni. Il codice JAX rileva automaticamente i dispositivi TPU disponibili all'interno della slice assegnata.

Elimina la sezione

  1. Elimina la sezione:

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

  2. Verifica che lo slice sia stato eliminato:

    kubectl get slices

Esegui l'upgrade dei node pool

Se esegui l'upgrade dei node pool configurati con il provisioning incrementale, devi utilizzare parametri di sovraccarico specifici per evitare conflitti di capacità.

Per configurare ed eseguire l'upgrade del pool di nodi:

  1. Se utilizzi la suddivisione dinamica, elimina le sezioni attive prima di eseguire la manutenzione manuale:

    kubectl delete slice SLICE_NAME

    Se utilizzi il sub-slicing dinamico, non è necessario eliminare prima le sezioni attive. Tuttavia, le sottosezioni che rimangono attive durante un upgrade non andranno a buon fine e passeranno allo stato FAILED.

  2. Aggiorna i parametri di upgrade per il pool di nodi:

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

    Assicurati che il campo --max-surge-upgrade sia impostato sul valore 0 per impedire a GKE di tentare di allocare TPU aggiuntive durante l'upgrade. Ti consigliamo di impostare il campo --max-unavailable-upgrade=16 in modo da eseguire l'upgrade di un intero sottoblocco di 16 nodi contemporaneamente.

  3. Esegui l'upgrade del pool di nodi:

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

Manutenzione e guasti hardware

Se attivi la manutenzione avviata dal cliente o se si verifica un failover hardware, vengono interessati solo i nodi di destinazione anziché l'intero pool di nodi.

Per il super-slicing dinamico, devi eliminare le sezioni dinamiche attive prima di eseguire la manutenzione manuale. Se utilizzi la suddivisione dinamica, non devi eliminare prima le sezioni attive. Se si verificano guasti hardware o manutenzione mentre è attiva una sottosezione dinamica, il sistema gestisce il ripristino come segue:

  1. Rimodellamento automatico: GKE rimodella automaticamente la slice dinamica attiva quando inizia la manutenzione su un host associato.
  2. Slice custom resource failure: la risorsa personalizzata Slice passa allo stato FAILED.
  3. Osservazione dello scheduler: lo scheduler osserva lo stato di errore della risorsa personalizzata Slice.
  4. Procedura di riformattazione: lo scheduler tenta automaticamente di ricreare le configurazioni delle sezioni su altri nodi integri disponibili.

Disattiva il controller delle sezioni

Per disattivare il controller di sezioni, rimuovilo dal cluster.

  1. Verifica che le risorse personalizzate Slice siano vuote:

    kubectl get slice -A

  2. Aggiorna il cluster per disattivare il controller di sezioni:

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

  3. Elimina la risorsa personalizzata Slice :

    kubectl delete crd slices.accelerator.gke.io

  4. Verifica che la risorsa personalizzata Slice sia stata eliminata:

    kubectl get crd | grep slices.accelerator.gke.io

  5. Rimuovi le etichette aggiunte dal controller di sezioni. Devi rimuovere queste etichette:

    • cloud.google.com/gke-tpu-slice
    • cloud.google.com/gke-tpu-topology
    1. Per rimuovere un nodo specifico, aggiorna il nome del nodo.
    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. Se vuoi rimuovere queste etichette da ogni nodo del cluster:
    kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    1. Controlla le etichette dei nodi e conferma che siano vuote:
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"

Passaggi successivi