Utilizzare la suddivisione dinamica con uno scheduler personalizzato

Questo documento descrive come utilizzare lo slicing dinamico interagendo direttamente con le risorse personalizzate Slice. Puoi creare slice, monitorare gli stati delle partizioni e verificare l'integrità delle slice.

Prima di seguire queste istruzioni, assicurati di comprendere i concetti di suddivisione dinamica.

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 ulteriori informazioni, vedi Pianificare le sezioni dinamiche con Kueue e TAS.

Panoramica del flusso di lavoro

Per utilizzare la suddivisione dinamica 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à delle sezioni.
  5. Elimina la sezione al termine.

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 lo slicing dinamico 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 successive.
    • Per la configurazione del sottosezionamento dinamico (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à Capacità è una funzionalità abilitata da TPU Cluster Director.
  • Per la suddivisione dinamica, assicurati che i tuoi nodi abbiano eventi di manutenzione in attesa. Monitora le istanze per rilevare eventi di manutenzione in attesa. Se uno dei tuoi nodi ha un evento di manutenzione in attesa con un orario di fine compreso 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.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva 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.

Attiva il controller delle sezioni

Per utilizzare la suddivisione dinamica, abilita il controller di suddivisione 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 seguente comando, verifica che sia presente il valore slices.accelerator.gke.io:

    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 node pool di gruppi di 16 nodi di VM TPU o in sottoblocchi. GKE esegue il provisioning di questi pool di nodi anche quando non riesce a trovare tutte le 16 VM integre posizionando i nodi su 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 a blocchi consente a GKE di creare il pool di nodi in qualsiasi sottoblocco disponibile all'interno del blocco specificato.
  • Un sottoblocco specifico o un gruppo specifico di 16 nodi di VM TPU, di 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 venga attivato il processo di provisioning incrementale. Quando il campo provision_only è impostato, il pool di nodi esegue il provisioning dei nodi TPU senza formare collegamenti ICI o OCS.

Imposta il targeting del 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 sottoblocco 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 sotto-blocco 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à All Capacity:

    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 è il numero di blocchi secondari disponibili. Ad esempio, il valore reservationSubBlockCount: 4 indica che il blocco ha quattro sottoblocchi disponibili e 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à Tutte le capacità:

    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 sottoblocchi, elenca tutti i sottoblocchi 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 relativi link Inter-Chip Interconnect (ICI) non sono ancora attivi. Pertanto, non puoi eseguire direttamente i carichi di lavoro su questi pool di nodi.

Per abilitare 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 slice.
  • Pianifica i carichi di lavoro 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 pool di nodi, puoi formare una super-slice dinamica più grande o una sotto-slice dinamica più piccola 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 dinamiche delle sezioni

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

Qualsiasi slice maggiore di 4x4x4 non ha un'etichetta di partizione, in quanto viene creato associando più partizioni 4x4x4.

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

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 di cui vuoi eseguire il targeting:

    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 control plane 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 è danneggiata, ma può comunque essere utilizzata 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 degradato.
    • UNHEALTHY: la partizione non funziona correttamente e non può essere utilizzata per formare una fetta.
    • UNSET: lo stato non è definito a causa dell'inizializzazione non riuscita del controller 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 super-fetta dinamica o una sottofetta 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 la suddivisione secondaria dinamica, puoi specificare topologie più piccole di 4x4x4, ad esempio 2x2x1, 2x2x2, 2x2x4 o 2x4x4. Queste topologie più piccole richiedono GKE versione 1.36.0-gke.3712000 o 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 non lo è. 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 è composta 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 sottoblocchi associati devono trovarsi all'interno della stessa prenotazione.
        • Tutti i nodi dei node pool associati devono essere nello stato ready.
    • Il valore del campo type deve essere tpu7x.
    • Se vuoi che il controller di slice ritenti automaticamente durante la formazione dello slice, puoi aggiungere l'annotazione slice.gke.io/retry-on-failure: "true" alla risorsa personalizzata dello slice. Se la sezione non viene creata a causa del motivo di stato SliceCreationFailed, il controller riprova finché la sezione non viene formata correttamente.

    Ad esempio, per creare una sezione 4x8x8 (super-sezionamento 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), 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 dello slice non riesce 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 sottoblocco 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 corrente. 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 viene superata, lo stato passa a ACTIVATING.
  • ACTIVATING: GKE sta formando la sezione.
    • Se l'operazione ha esito positivo, lo stato passa a ACTIVE.
    • Se i blocchi secondari sono degradati, ma la sezione è 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 della sezione è in fase di inizializzazione ed esegue i controlli preflight per la formazione della sezione.
  • SliceCreationFailed: la creazione non è riuscita perché i prerequisiti non sono stati soddisfatti (ad esempio, mancano le risorse di Compute Engine richieste) o i controlli preliminari non sono riusciti. Per riprovare automaticamente la formazione delle sezioni in questo stato, configura l'annotazione slice.gke.io/retry-on-failure: "true".
  • ACTIVATING: la sezione è in fase di formazione (unione).
  • ACTIVE: la slice è completamente formata, integra e pronta per l'esecuzione dei carichi di lavoro.
  • ACTIVE_DEGRADED: la sezione è formata ma include cubi degradati, supportati dalla resilienza ICI. I carichi di lavoro possono essere eseguiti, ma le prestazioni potrebbero essere compromesse. Il super-slicing dinamico è resiliente ai singoli guasti dell'Optical Circuit Switch (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 guasto critico del software o dell'hardware.
  • INCOMPLETE: non sono disponibili cubi sufficienti per avviare la formazione della superslice.

Per saperne 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 la suddivisione dinamica. 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 slice. 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 pool di nodi multislice utilizzando JobSet

Questo esempio mostra come eseguire il deployment di un carico di lavoro su 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 la suddivisione secondaria dinamica, utilizza JobSet v0.12.0 o versioni successive. Per la suddivisione dinamica, 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, ciascuno 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 una sezione TPU univoca.
    • 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 sezione 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 pool di nodi 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 la suddivisione secondaria dinamica, non devi prima eliminare 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 la suddivisione dinamica, devi eliminare le suddivisioni dinamiche attive prima di eseguire la manutenzione manuale. Se utilizzi la suddivisione dinamica, non devi prima eliminare le sezioni attive. Se si verificano manutenzione o guasti hardware mentre è attiva una sottosezione dinamica, il sistema gestisce il ripristino come segue:

  1. Rimodellamento automatico: GKE rimodella automaticamente la sezione 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.

Disattivare il controller della sezione

Per disattivare il controller delle sezioni, rimuovilo dal cluster.

  1. Controlla che le risorse personalizzate di Slice siano vuote:

    kubectl get slice -A

  2. Aggiorna il cluster per disattivare il controller delle 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 delle 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