Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Utilizzare la suddivisione dinamica con uno scheduler personalizzato

Standard

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à degli slice.

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

Perché utilizzare la suddivisione dinamica con uno scheduler 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:

Attiva il controller delle sezioni.
Crea node pool con provisioning incrementale.
Crea risorse personalizzate Slice in base ai requisiti del tuo workload. Applica la risorsa personalizzata Slice al tuo cluster.
Monitora gli stati delle partizioni e l'integrità delle sezioni.
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 la suddivisione dinamica in GKE, devi soddisfare i seguenti requisiti:

Utilizza un cluster Standard nella versione 1.35.2-gke.1842000 o successive nel canale rapido.
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.

Prima di iniziare

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

Attiva l'API Google Kubernetes Engine.

Attiva l'API Kubernetes Engine

Se vuoi 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.
Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Assicurati di avere un cluster Standard esistente nella versione 1.35.2-gke.1842000 o successive nel canale rapido. Per creare un nuovo cluster, vedi Creazione di un cluster a livello di regione.
Assicurati di avere una quota sufficiente per Ironwood (TPU7x) nella tua regione.
Se prevedi di eseguire carichi di lavoro multislice, installa JobSet v0.10.1 o versioni successive.
Richiedi capacità TPU in modalità Tutta la capacità.

Attiva il controller delle sezioni

Per utilizzare la suddivisione dinamica, abilita il controller di suddivisione nel cluster.

Aggiorna il cluster:
```
gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --enable-slice-controller
```
Sostituisci quanto segue:
- CLUSTER_NAME: il nome del tuo cluster.
- LOCATION: la regione con la tua capacità TPU disponibile.

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

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

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 tuo 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 di 16 nodi specifico 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 venga attivato il processo di provisioning incrementale. Quando il campo provision_only è impostato, ilpool di nodil esegue il provisioning dei nodi TPU senza formare link 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

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.
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.
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

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 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.
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.

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

Dopo aver creato i node pool, puoi formare una sezione dinamica più grande creando una risorsa personalizzata Slice. Anziché i pod, utilizzi una risorsa personalizzata Slice per definire la topologia specificata, che viene poi attivata dal controller slice.

Verifica lo stato dei nodi e delle partizioni

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

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
```
Questo valore corrisponde all'impostazione accelerator-topology-mode=provision_only definita durante la creazione della policy del workload.
Recupera le informazioni sull'etichetta del nodo:
```
kubectl describe node NODE_NAME | grep "cloud.google.com/gke-tpu-partition-4x4x4-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
```
L'annotazione cloud.google.com/gke-tpu-partition-4x4x4-state indica se il nodo è disponibile per formare una sezione dinamica. Questa etichetta supporta i seguenti valori:
- HEALTHY: il nodo è integro e perfettamente funzionante.
- DEGRADED: il nodo è danneggiato, ma ancora utilizzabile per la formazione di slice dinamici.
- UNHEALTHY: il nodo non funziona correttamente e non può essere utilizzato per formare una sezione.
- UNSET: lo stato non è definito a causa di un numero insufficiente di nodi nel pool di nodi.
- INCOMPLETE: non tutti i nodi all'interno della partizione vengono sottoposti al provisioning.
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'etichetta node.gke.io/created-by-mig, che consente al piano di controllo GKE di collegare i nodi Kubernetes alle risorse Compute Engine sottostanti.

Crea una risorsa personalizzata Slice

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.
- TOPOLOGY: la topologia della sezione dinamica. La topologia deve soddisfare le seguenti condizioni:
  - 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 4x4x4 che compongono la sezione. Calcola 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 di partizioni calcolato ((A × B × C) / 64). 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 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 delle sezioni esegua automaticamente nuovi tentativi durante la formazione delle sezioni, puoi aggiungere l'annotazione slice.gke.io/retry-on-failure: "true" alla risorsa personalizzata della sezione. Se lo slice non viene creato a causa del motivo di stato SliceCreationFailed, il controller riproverà finché lo slice non viene formato correttamente.
Ad esempio, per creare una sezione 4x8x8, devi fornire quattro ID partizione univoci.
```
apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
    name: test-slice-example
    annotations:
      slice.gke.io/retry-on-failure: "true" # Optional annotation to retry slice formation
spec:
    type: "tpu7x"
    topology: "4x8x8" # (4*8*8)/64 = 4 partitions
    partitionIds:
        - "p0"
        - "p1"
        - "p2"
        - "p3"
```
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 blocco 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 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 attuale della slice. Il ciclo di vita di una risorsa personalizzata Slice segue questa progressione:

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 sottoblocchi 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.

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

Esegui carichi di lavoro sul dynamic slicing

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 sezione di un sottoblocco.

Salva il seguente manifest di esempio come tpu-job-jax-v7x-64.yaml:

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.

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.

Installa JobSet:

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

Salva il seguente manifest di esempio come tpu-multislice-jax.yaml:

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

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 sezione 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.
Importante: non modificare manualmente l'etichetta cloud.google.com/gke-tpu-slice.

Elimina la sezione

Elimina la sezione:

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

Verifica che lo slice sia stato eliminato:
```
kubectl get slices
```

Disattivare il controller delle sezioni

Per disattivare il controller delle sezioni, rimuovilo dal cluster.

Controlla che le risorse personalizzate di Slice siano vuote:
```
kubectl get slice -A
```

Aggiorna il cluster per disattivare il controller delle sezioni:

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

Elimina la risorsa personalizzata Slice :

kubectl delete crd slices.accelerator.gke.io

Verifica che la risorsa personalizzata Slice sia stata eliminata:
```
kubectl get crd | grep slices.accelerator.gke.io
```

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

cloud.google.com/gke-tpu-slice
cloud.google.com/gke-tpu-topology

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-

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-

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

Scopri di più sui concetti di suddivisione dinamica.
Scopri di più sulla risorsa personalizzata Slice.