Pianificare le sezioni dinamiche con Kueue e TAS

Standard

Questo documento spiega come eseguire il provisioning dei pool di nodi TPU e pianificare gli slice dinamici in Google Kubernetes Engine (GKE) utilizzando Kueue e la pianificazione basata sulla topologia (TAS).

Puoi anche utilizzare lo slicing dinamico interagendo direttamente con le risorse personalizzate Slice. Per saperne di più, consulta Utilizza lo slicing dinamico con uno scheduler personalizzato.

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

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 successiva.
  • Per la configurazione del sub-slicing dinamico (topologie più piccole di 4x4x4), utilizza la versione 1.36.0-gke.3712000 o successiva.
• Utilizza la versione Ironwood (TPU7x).
• Utilizza l'immagine sistema operativo Container-Optimized OS per i nodi.
• Per utilizzare il provisioning incrementale, utilizza le prenotazioni in modalità Tutte le capacità. La modalità di capacità All è una funzionalità abilitata da TPU Cluster Director.
• Per il sub-slicing dinamico, 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.
  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, consulta Creazione di un cluster a livello di regione.
• Assicurati di avere una quota sufficiente per Ironwood (TPU7x) nella tua regione.
• Se prevedi di eseguire workload multislice, installa JobSet v0.10.1 o versioni successive
• Richiedi capacità TPU in modalità All Capacity.

Utilizza lo slicing dinamico in GKE con Kueue

Questa sezione descrive il flusso di lavoro per l'utilizzo dello slicing dinamico in GKE.

1. Visualizza la topologia e lo stato di integrità delle prenotazioni in modalità All Capacity.
2. Abilita il controller delle sezioni nel cluster.
3. Installa Kueue, JobSet e LWS.
4. Crea pool di nodi TPU.
5. Configura Kueue per creare una risorsa personalizzata Slice.
6. Esegui i workload sullo slicing dinamico con Kueue.
7. Esegui la pulizia.

Attiva 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:

   • CLUSTER_NAME: il nome del tuo cluster.
   • LOCATION: la regione con la tua capacità TPU disponibile.

2. Recupera le credenziali per poter comunicare con il cluster tramite 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 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
   

Installa Kueue, JobSet e LWS

Se hai già installato Kueue, JobSet e LWS, puoi saltare questa sezione.

Installa Kueue

Segui le istruzioni riportate nella documentazione di Kueue o esegui questo comando:

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

Sostituisci KUEUE_VERSION con la versione di Kueue richiesta in base ai requisiti della topologia. Per il sub-slicing dinamico, utilizza Kueue v0.18.2 o versioni successive. Per il super-slicing dinamico, utilizza Kueue v0.16.6 o versioni successive.

Installa JobSet

Segui le istruzioni riportate nella documentazione di JobSet o esegui questo comando:

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

Sostituisci JOBSET_VERSION con la versione JobSet richiesta in base ai requisiti della topologia. 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.

Installa LWS

LeaderWorkerSet (LWS) è richiesto solo per il sub-slicing dinamico.

Segui le istruzioni riportate nella documentazione di LWS o esegui questo comando:

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

Sostituisci LWS_VERSION con la versione LWS richiesta. Utilizza LWS v0.8.0 o versioni successive.

Crea node pool con provisioning incrementale

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

Puoi scegliere come target il tuo pool di nodi in modo che appartenga a uno dei seguenti elementi:

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

Crea una policy del workload

Per creare un pool di nodi di sezioni TPU con Ironwood (TPU7x), devi prima creare una policy del workload con il campo accelerator-topology-mode impostato su provision_only. Questa impostazione attiva il processo 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 workload.
• PROJECT_ID: il tuo ID progetto Google Cloud .
• REGION: la regione della policy del workload.

In questo comando, segui questi passaggi:

• Imposta sempre il campo accelerator-topology su 4x4x4 in modo che corrisponda al numero totale di chip all'interno di un singolo blocco secondario.
• 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 link ICI o OCS.

Nota: non è necessario creare una nuova policy del workload per ogni pool di nodi. Una policy del workload è univoca per progetto, per regione e per topologia. Puoi riutilizzare la stessa policy del workload per più pool di nodi che condividono queste caratteristiche. Per visualizzare l'elenco delle policy dei workload, utilizza il comando gcloud compute resource-policies list --filter="region:REGION".

Scegli come target il 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à.

• Scegli un blocco come target: ogni pool di nodi utilizza la capacità di un blocco specificato. GKE posiziona il pool di nodi all'interno di un blocco secondario disponibile in quel blocco. Devi creare un numero di pool di nodi pari al numero di blocchi secondari nel blocco che vuoi utilizzare.

• Scegli come target un blocco secondario: ogni pool di nodi viene mappato a un blocco secondario specifico e disponibile. Quando utilizzi il targeting dei blocchi secondari, GKE crea il pool di nodi se almeno una VM è in stato integro. Il provisioning incrementale contribuisce a garantire che tutti i nodi siano posizionati all'interno del sub-blocco specificato.

Blocca

1. Per recuperare il nome del blocco in una prenotazione e il conteggio dei blocchi secondari disponibili nel blocco, completa i seguenti passaggi nel documento Visualizza la topologia e lo stato di integrità di tutte le 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 node pool 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 blocco secondario 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 blocchi secondari disponibili, completa i seguenti passaggi nel documento Visualizza la topologia e lo stato di integrità di tutte le prenotazioni in modalità 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 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 blocco secondario o di 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 blocco secondario.

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 workload 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 i workload direttamente su questi pool di nodi.

Per attivare tutti i link ICI necessari per formare lo slice e consentire la pianificazione dei workload, crea uno slice dinamico 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.

Crea una sezione dinamica con Kueue e TAS

In questa sezione, pianificherai i workload GKE con Kueue e TAS.

Installa il controller di sezioni Kueue

1. Per installare il controller di sezioni Kueue, salva il seguente manifest come slice-controller.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: Namespace
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-system
   ---
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-leader-election-role
     namespace: slice-controller-system
   rules:
   - apiGroups:
     - ""
     resources:
     - configmaps
     verbs:
     - get
     - list
     - watch
     - create
     - update
     - patch
     - delete
   - apiGroups:
     - coordination.k8s.io
     resources:
     - leases
     verbs:
     - get
     - list
     - watch
     - create
     - update
     - patch
     - delete
   - apiGroups:
     - ""
     resources:
     - events
     verbs:
     - create
     - patch
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-webhook-secrets-role
     namespace: slice-controller-system
   rules:
   - apiGroups:
     - ""
     resources:
     - secrets
     verbs:
     - get
     - list
     - watch
     - update
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-manager-role
   rules:
   - apiGroups:
     - ""
     resources:
     - nodes
     - pods
     verbs:
     - get
     - list
     - watch
   - apiGroups:
     - accelerator.gke.io
     resources:
     - slices
     verbs:
     - create
     - delete
     - get
     - list
     - patch
     - update
     - watch
   - apiGroups:
     - accelerator.gke.io
     resources:
     - slices/finalizers
     verbs:
     - update
   - apiGroups:
     - accelerator.gke.io
     resources:
     - slices/status
     verbs:
     - get
     - patch
     - update
   - apiGroups:
     - admissionregistration.k8s.io
     resources:
     - mutatingwebhookconfigurations
     verbs:
     - get
     - list
     - update
     - watch
   - apiGroups:
     - batch
     resources:
     - jobs
     verbs:
     - get
     - list
     - patch
     - update
     - watch
   - apiGroups:
     - events.k8s.io
     resources:
     - events
     verbs:
     - create
     - patch
     - update
     - watch
   - apiGroups:
     - jobset.x-k8s.io
     resources:
     - jobsets
     verbs:
     - get
     - list
     - patch
     - update
     - watch
   - apiGroups:
     - kueue.x-k8s.io
     resources:
     - admissionchecks
     verbs:
     - get
     - list
     - watch
   - apiGroups:
     - kueue.x-k8s.io
     resources:
     - admissionchecks/status
     - workloads/status
     verbs:
     - get
     - patch
     - update
   - apiGroups:
     - kueue.x-k8s.io
     resources:
     - workloads
     verbs:
     - create
     - get
     - list
     - patch
     - update
     - watch
   - apiGroups:
     - leaderworkerset.x-k8s.io
     resources:
     - leaderworkersets
     verbs:
     - get
     - list
     - patch
     - update
     - watch
   - apiGroups:
     - ray.io
     resources:
     - rayclusters
     - rayjobs
     verbs:
     - get
     - list
     - patch
     - update
     - watch
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-metrics-auth-role
   rules:
   - apiGroups:
     - authentication.k8s.io
     resources:
     - tokenreviews
     verbs:
     - create
   - apiGroups:
     - authorization.k8s.io
     resources:
     - subjectaccessreviews
     verbs:
     - create
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-metrics-reader
   rules:
   - nonResourceURLs:
     - /metrics
     verbs:
     - get
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-leader-election-rolebinding
     namespace: slice-controller-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: slice-controller-leader-election-role
   subjects:
   - kind: ServiceAccount
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-webhook-secrets-rolebinding
     namespace: slice-controller-system
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: slice-controller-webhook-secrets-role
   subjects:
   - kind: ServiceAccount
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-manager-rolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: slice-controller-manager-role
   subjects:
   - kind: ServiceAccount
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-metrics-auth-rolebinding
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: slice-controller-metrics-auth-role
   subjects:
   - kind: ServiceAccount
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-webhook-server-cert
     namespace: slice-controller-system
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-controller-manager-metrics-service
     namespace: slice-controller-system
   spec:
     ports:
     - name: https
       port: 8443
       protocol: TCP
       targetPort: 8443
     selector:
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
   ---
   apiVersion: v1
   kind: Service
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-webhook-service
     namespace: slice-controller-system
   spec:
     ports:
     - port: 443
       protocol: TCP
       targetPort: 9443
     selector:
       control-plane: controller-manager
   ---
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     labels:
       app.kubernetes.io/managed-by: kustomize
       app.kubernetes.io/name: slice-controller
       control-plane: controller-manager
     name: slice-controller-controller-manager
     namespace: slice-controller-system
   spec:
     replicas: 1
     selector:
       matchLabels:
         app.kubernetes.io/name: slice-controller
         control-plane: controller-manager
     template:
       metadata:
         annotations:
           kubectl.kubernetes.io/default-container: manager
         labels:
           app.kubernetes.io/name: slice-controller
           control-plane: controller-manager
       spec:
         containers:
         - args:
           - --metrics-bind-address=:8443
           - --leader-elect
           - --health-probe-bind-address=:8081
           - --zap-log-level=3
           - --feature-gates=UseRetryMechanismForSliceCreation=true
           - --activation-timeout=60m
           - --kube-api-qps=100
           - --kube-api-burst=200
           - --default-slice-health-node-affinity=HEALTHY_AND_DEGRADED
           - --reuse-slices=true
           - --add-preferred-node-affinity=true
           command:
           - /manager
           image: tpuongke/kueue-slice-controller:v0.10
           livenessProbe:
             httpGet:
               path: /healthz
               port: 8081
             initialDelaySeconds: 15
             periodSeconds: 20
           name: manager
           ports:
           - containerPort: 9443
             name: webhook-server
             protocol: TCP
           readinessProbe:
             httpGet:
               path: /readyz
               port: 8081
             initialDelaySeconds: 5
             periodSeconds: 10
           resources:
             limits:
               cpu: 12
               memory: 32Gi
             requests:
               cpu: 8
               memory: 16Gi
           securityContext:
             allowPrivilegeEscalation: false
             capabilities:
               drop:
               - ALL
           volumeMounts:
           - mountPath: /tmp/k8s-webhook-server/serving-certs
             name: cert
             readOnly: true
         securityContext:
           runAsNonRoot: true
           seccompProfile:
             type: RuntimeDefault
         serviceAccountName: slice-controller-controller-manager
         terminationGracePeriodSeconds: 10
         volumes:
         - name: cert
           secret:
             defaultMode: 420
             secretName: slice-controller-webhook-server-cert
   ---
   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   metadata:
     labels:
       control-plane: controller-manager
     name: slice-controller-mutating-webhook-configuration
   webhooks:
   - admissionReviewVersions:
     - v1
     clientConfig:
       service:
         name: slice-controller-webhook-service
         namespace: slice-controller-system
         path: /mutate-batch-v1-job
     failurePolicy: Fail
     name: mjob.kb.io
     rules:
     - apiGroups:
       - batch
       apiVersions:
       - v1
       operations:
       - CREATE
       resources:
       - jobs
     sideEffects: None
   - admissionReviewVersions:
     - v1
     clientConfig:
       service:
         name: slice-controller-webhook-service
         namespace: slice-controller-system
         path: /mutate-jobset-x-k8s-io-v1alpha2-jobset
     failurePolicy: Fail
     name: mjobset.kb.io
     rules:
     - apiGroups:
       - jobset.x-k8s.io
       apiVersions:
       - v1alpha2
       operations:
       - CREATE
       resources:
       - jobsets
     sideEffects: None
   - admissionReviewVersions:
     - v1
     clientConfig:
       service:
         name: slice-controller-webhook-service
         namespace: slice-controller-system
         path: /mutate-leaderworkerset-x-k8s-io-v1-leaderworkerset
     failurePolicy: Fail
     name: mleaderworkerset.kb.io
     rules:
     - apiGroups:
       - leaderworkerset.x-k8s.io
       apiVersions:
       - v1
       operations:
       - CREATE
       resources:
       - leaderworkersets
     sideEffects: None
   - admissionReviewVersions:
     - v1
     clientConfig:
       service:
         name: slice-controller-webhook-service
         namespace: slice-controller-system
         path: /mutate-ray-io-v1-raycluster
     failurePolicy: Fail
     name: mraycluster.kb.io
     rules:
     - apiGroups:
       - ray.io
       apiVersions:
       - v1
       operations:
       - CREATE
       resources:
       - rayclusters
     sideEffects: None
   - admissionReviewVersions:
     - v1
     clientConfig:
       service:
         name: slice-controller-webhook-service
         namespace: slice-controller-system
         path: /mutate-ray-io-v1-rayjob
     failurePolicy: Fail
     name: mrayjob.kb.io
     rules:
     - apiGroups:
       - ray.io
       apiVersions:
       - v1
       operations:
       - CREATE
       resources:
       - rayjobs
     sideEffects: None
   

2. Applica il manifest slice-controller.yaml:

   kubectl apply -f slice-controller.yaml
   

3. Per configurare Kueue per lo slicing dinamico, salva il seguente manifest come dynamic-slice-topology.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: kueue.x-k8s.io/v1beta1
   kind: Topology
   metadata:
     name: superslice-topology
   spec:
     levels:
     # Label to identify the physical block a sub-block belongs to.
     # Only sub-blocks from the same block can form a slice.
     - nodeLabel: cloud.google.com/gce-topology-block
     # Label to identify individual TPU sub-blocks (4x4x4 topology).
     - nodeLabel: cloud.google.com/gke-tpu-partition-4x4x4-id
     # Standard Kubernetes label for individual nodes.
     # Required to assign Pods to specific VMs.
     - nodeLabel: kubernetes.io/hostname
   ---
   apiVersion: kueue.x-k8s.io/v1beta1
   kind: ResourceFlavor
   metadata:
     name: superslice-rf
   spec:
     nodeLabels:
       cloud.google.com/gke-tpu-accelerator: tpu7x
     topologyName: superslice-topology
   ---
   apiVersion: kueue.x-k8s.io/v1beta1
   kind: AdmissionCheck
   metadata:
     name: superslice-ac
   spec:
     controllerName: accelerator.gke.io/slice
   ---
   apiVersion: kueue.x-k8s.io/v1beta1
   kind: ClusterQueue
   metadata:
     name: cq
   spec:
     namespaceSelector: {}
     admissionChecks:
     - superslice-ac
     resourceGroups:
     - coveredResources:
       - google.com/tpu
       flavors:
       - name: superslice-rf
         resources:
         - name: google.com/tpu
           nominalQuota: "999999"  # modeling unlimited quota
   ---
   apiVersion: kueue.x-k8s.io/v1beta1
   kind: LocalQueue
   metadata:
     name: lq
     namespace: default
   spec:
     clusterQueue: cq
   

4. Applica il manifest dynamic-slice-topology.yaml:

   kubectl apply -f dynamic-slice-topology.yaml
   

   In questo manifest, configuri Kueue per lo slicing dinamico definendo le seguenti risorse:

   • Topologia di slicing dinamico di Ironwood (TPU7x) (superslice-topology): la topologia definisce i livelli considerati da Kueue quando pianifica i workload di slicing dinamico. Questi livelli sono i seguenti:
     • Etichetta cloud.google.com/gce-topology-block: questo livello è necessario per capire quali blocchi secondari appartengono a quali blocchi, perché solo i blocchi secondari dello stesso blocco possono formare una sezione.
     • Etichetta cloud.google.com/gke-tpu-partition-4x4x4-id: questo livello rappresenta i singoli blocchi secondari Ironwood (TPU7x) (topologia 4x4x4).
     • Etichetta kubernetes.io/hostname: questo livello è necessario per assegnare i pod a VM specifiche e per osservare le relative etichette e incompatibilità.
   • Ironwood (TPU7x) SuperSlice ResourceFlavor (superslice-rf): il tipo di risorsa per i blocchi secondari Ironwood (TPU7x) include l'etichetta cloud.google.com/gke-tpu-accelerator: tpu7x per abbinare i nodi alle macchine Ironwood (TPU7x).
   • SuperSlice AdmissionCheck (superslice-ac): questo controllo di ammissione indica a Kueue di non pianificare un workload finché il controller dello slice GKE non conferma che lo slice è diventato attivo. Il controllo di ammissione viene prima definito e poi aggiunto al ClusterQueue che gestisce i workload di slicing dinamico.
   • ClusterQueue (cq) e LocalQueue (lq): questi campi gestiscono le risorse google.com/tpu. La ClusterQueue cq include il controllo di ammissione superslice-ac. Il campo nominalQuota per google.com/tpu può essere configurato in due modi:
     • Quota specifica: imposta il campo nominalQuota in modo che corrisponda alla capacità esistente per la condivisione equa e la gestione delle quote.
     • Quota illimitata: imposta il campo nominalQuota su un valore molto alto, ad esempio "999999", per modellare una quota illimitata. Per concentrarsi su TAS e slicing dinamico, questa configurazione bypassa la funzionalità di gestione delle quote di Kueue.

Definisci la selezione dell'integrità della partizione

Oltre all'integrità e all'idoneità standard dei nodi, GKE espone lo stato specifico di ogni forma di partizione utilizzando l'etichetta cloud.google.com/gke-tpu-partition-[shape]-state (dove [shape] corrisponde alla forma dell'ID partizione, ad esempio 2x2x1, 2x2x2, 2x2x4, 2x4x4 o 4x4x4). Questa etichetta consente a GKE di tenere conto dei fattori che influenzano la formazione degli slice, come lo stato dei link TPU. La configurazione di suddivisione dinamica (topologie più piccole di 4x4x4) richiede GKE 1.36.0-gke.3712000 o versioni successive.

Puoi definire il valore dell'etichetta dello stato della partizione come segue:

• HEALTHY: la partizione è integra e completamente funzionante.
• DEGRADED: l'infrastruttura della partizione è in uno stato di degrado, ad esempio a causa del degrado del link OCS. La partizione può comunque formare uno slice, ma le prestazioni complessive potrebbero essere inferiori rispetto alle partizioni integre. Questo stato si applica solo alla topologia 4x4x4 di primo livello. Le topologie più piccole non hanno uno stato di degrado.
• UNHEALTHY: la partizione non è integra e non può formare uno slice.
• UNSET: lo stato non è definito a causa di un'inizializzazione non riuscita del controller di GKE Slice.
• INCOMPLETE: non è stato eseguito il provisioning di tutti i nodi all'interno della partizione.

Il webhook del controller Kueue Slice convalida se un workload include un requisito specifico per l'integrità della partizione. Se non viene indicata alcuna preferenza, il webhook inserisce un'affinità nodo predefinita.

Il comportamento è il seguente:

• Se è presente un nodeSelector o un nodeAffinity che ha come target l'etichetta cloud.google.com/gke-tpu-partition-[shape]-state, rimane invariato.

• Se non esiste una configurazione di etichette di questo tipo, il webhook inserisce la seguente affinità dei nodi predefinita per garantire che vengano utilizzate solo le partizioni disponibili:

  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: cloud.google.com/gke-tpu-partition-4x4x4-state
          operator: In
          values:
          - "HEALTHY"
          - "DEGRADED"
  

La sezione seguente include esempi in cui l'etichetta cloud.google.com/gke-tpu-partition-4x4x4-state è configurata per specificare le diverse configurazioni di integrità dei blocchi secondari.

Esegui workload di test sullo slicing dinamico con Kueue

Questa sezione descrive come eseguire il deployment dei workload sullo slicing dinamico con Kueue e TAS. Include esempi che mostrano come creare un workload di slicing dinamico e un workload composto da più sezioni. I workload vengono inviati come JobSet.

Esempio 1: un singolo workload utilizza un singolo slice dinamico

L'esempio seguente descrive come creare un workload utilizzando una sezione con una topologia 4x12x16, composta da 12 sottoblocchi. Il numero di pod è stato calcolato come: (4 * 12 * 16) / 4 chip per nodo = 192 pod.

1. Salva il seguente manifest come big-super-slice.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: big-super-slice
     labels:
       kueue.x-k8s.io/queue-name: lq
   spec:
     replicatedJobs:
       - name: job-jax
         replicas: 1
         template:
           spec:
             parallelism: 192  # pods per slice calculation: 4*12*16 / 4 = 192
             completions: 192
             backoffLimit: 10
             template:
               metadata:
                 annotations:
                   cloud.google.com/gke-tpu-slice-topology: 4x12x16
               spec:
                 tolerations:
                   - key: "google.com/tpu"
                     operator: "Equal"
                     value: "present"
                     effect: "NoSchedule"
                 nodeSelector:
                   cloud.google.com/gke-tpu-accelerator: tpu7x
                 containers:
                   - name: jax
                     image: python:latest
                     command:
                       - bash
                       - -c
                       - |
                         printenv
                         pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                         python -c 'import jax; print("Global device count:", jax.device_count(), "Local device count:", jax.local_device_count())'
                     resources:
                       limits:
                         google.com/tpu: 4
                 restartPolicy: Never
   

   In questo manifest, le seguenti annotazioni indicano a Kueue le caratteristiche e la topologia della sezione per configurare quanto segue:

   • cloud.google.com/gke-tpu-slice-topology: specifica "4x12x16" come topologia di slicing dinamico. I requisiti per la topologia dell'acceleratore tpu7x includono le seguenti regole:
     • 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 il super-slicing dinamico:puoi specificare topologie uguali o superiori a 4x4x4. Per la configurazione di super-slicing dinamico, ogni dimensione della topologia richiesta deve essere un multiplo di quattro, ad esempio 4A x 4B x 4C.
     • La topologia deve essere una stringa tridimensionale nel formato AxBxC, ad esempio 4x8x8.
     • Le dimensioni devono essere ordinate in ordine non decrescente: A <= B <= C. Ad esempio, 4x8x4 non è valido; dovrebbe essere 4x4x8.
     • Il prodotto delle dimensioni (ABC) non deve superare 9216.
     • Le topologie di sezioni più grandi supportate possono includere fino a 32 blocchi secondari. Ad esempio, 8x16x16 con 32 blocchi secondari, 8x12x20 con 30 blocchi secondari o 12x12x12 con 27 blocchi secondari rientrano nei limiti accettati.
   • cloud.google.com/gke-tpu-accelerator: tpu7x: pianifica i pod su VM che eseguono Ironwood (TPU7x).
   • kueue.x-k8s.io/queue-name: assegna il JobSet a una LocalQueue di Kueue.
   • Il webhook inserisce l'affinità dei nodi predefinita per garantire l'utilizzo dei nodi HEALTHY e DEGRADED.

2. Applica il manifest big-super-slice.yaml:

   kubectl apply -f big-super-slice.yaml
   

   Dopo aver applicato il manifest, Kueue crea un JobSet denominato big-super-slice. Kueue tenta quindi di formare una singola sezione dinamica con una topologia 4x12x16. Dopo l'attivazione della sezione, Kueue ammette il workload e i 192 pod vengono pianificati sui nodi per formare la sezione dinamica che esegue i workload.

Esempio 2: workload con più di una replica

L'esempio seguente mostra come creare un workload che utilizza due slice dinamici, ciascuno composto da quattro blocchi secondari che hanno come target solo i nodi HEALTHY.

1. Salva il seguente manifest come two-super-slices.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: two-super-slices
     labels:
       kueue.x-k8s.io/queue-name: lq
   spec:
     replicatedJobs:
       - name: job-jax
         replicas: 2
         template:
           spec:
             parallelism: 64  # Pods per slice calculation: (4*8*8) / 4 = 64
             completions: 64
             backoffLimit: 10
             template:
               metadata:
                 annotations:
                   cloud.google.com/gke-tpu-slice-topology: 4x8x8
               spec:
                 tolerations:
                   - key: "google.com/tpu"
                     operator: "Equal"
                     value: "present"
                     effect: "NoSchedule"
                 nodeSelector:
                   cloud.google.com/gke-tpu-accelerator: tpu7x
                   cloud.google.com/gke-tpu-partition-4x4x4-state: "HEALTHY"
                 containers:
                   - name: jax
                     image: python:latest
                     command:
                       - bash
                       - -c
                       - |
                         printenv
                         pip install "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                         python -c 'import jax; print("Global device count:", jax.device_count(), "Local device count:", jax.local_device_count())'
                     resources:
                       limits:
                         google.com/tpu: 4
                 restartPolicy: Never
   

2. Applica il manifest two-super-slices.yaml:

   kubectl apply -f two-super-slices.yaml
   

In questo manifest, imposta il campo replicas su 2 nella sezione replicatedJobs. Dopo aver applicato il manifest, Kueue tenta di formare due sezioni separate con una topologia 4x8x8. Kueue crea una sezione dinamica per ogni replica definita in jobset.spec.replicatedJobs[].replicas. Se vengono specificate n repliche, Kueue crea n slice dinamici per il workload e attende che tutti gli slice diventino attivi prima di ammettere il workload.

Ottimizza la pianificazione dei workload con il riutilizzo delle sezioni

Per impostazione predefinita, Kueue indica al controller della sezione di eseguire il provisioning di una nuova sezione TPU per ogni esecuzione del workload e di eliminarla al termine del workload. Questo comportamento può causare abbandono e overhead nell'infrastruttura sottostante.

Con il riutilizzo delle sezioni, i nuovi workload possono riutilizzare le sezioni TPU esistenti e inattive che hanno limiti di topologia e hardware identici. Quando attivi il riutilizzo delle sezioni, Kueue contrassegna la sezione come inattiva al termine di un job anziché eliminarla. Un nuovo job che richiede la stessa partizione rivendica e riutilizza immediatamente lo slice, bypassando il ritardo di provisioning dell'hardware.

Nota: il gruppo di API degli eventi utilizzato dal controller è cambiato. Se hai integrazioni personalizzate, devi utilizzare events.k8s.io/v1 anziché core/v1. L'efficienza migliorata del riutilizzo delle sezioni richiede Kueue v0.19.0 o versioni successive.

Abilita il riutilizzo degli slice

Per ottimizzare completamente il riutilizzo delle sezioni, devi configurare sia il controller delle sezioni sia Kueue in modo che funzionino insieme.

1. Configura il controller delle sezioni:aggiorna gli argomenti di deployment del controller delle sezioni Kueue per includere il flag --reuse-slices=true. Per assicurarti che i workload siano pianificati in modo ottimale sugli slice esistenti, aggiungi anche il flag --add-preferred-node-affinity=true.

   Nota: le sezioni riutilizzabili vengono denominate in modo dinamico con un prefisso s-<topology>, disaccoppiandole dai nomi dei workload specifici.

2. Configura Kueue (consigliato): per consentire a Kueue di utilizzare i suggerimenti di affinità dei nodi preferiti del controller, devi attivare il feature gate TASRespectNodeAffinityPreferred nella configurazione di Kueue.

   Ad esempio, modifica l'oggetto ConfigMap kueue-manager-config per aggiungere il feature gate:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: kueue-manager-config
     namespace: kueue-system
   data:
     controller_manager_config.yaml: |
       apiVersion: config.kueue.x-k8s.io/v1beta1
       kind: Configuration
       featureGates:
         TASRespectNodeAffinityPreferred: true
       # ...
   

   Dopo aver modificato ConfigMap, riavvia il deployment kueue-controller-manager per applicare la modifica:

   kubectl rollout restart deploy kueue-controller-manager -n kueue-system
   

   Nota: il riutilizzo delle sezioni funziona con le versioni precedenti di Kueue, ma il miglioramento dell'affinità dei nodi preferita è compatibile solo con Kueue v0.18 o versioni successive.

Forza l'eliminazione delle sezioni per workload

Per fare in modo che un workload specifico esegua la pulizia delle sezioni e ne impedisca il riutilizzo, completa i seguenti passaggi:

1. Applica la seguente etichetta alla definizione del job o del JobSet:

   kueue.gke.io/tpu-enforce-slice-deletion: "true"
   

   Dopo aver applicato questa etichetta, il workload può comunque essere pianificato su una sezione inattiva esistente. Tuttavia, una volta completato il workload, lo slice verrà eliminato definitivamente anziché essere restituito al pool riutilizzabile.

2. Configura Kueue in modo che trasmetta questa etichetta dal job del framework all'oggetto Kueue Workload aggiungendo l'etichetta all'elenco labelKeysToCopy nella configurazione di Kueue:

   labelKeysToCopy:
   - "kueue.gke.io/tpu-enforce-slice-deletion"
   

Monitora la sezione

Puoi visualizzare lo stato della sezione e monitorarne le metriche con le metriche di sistema di GKE.

Monitora lo stato della sezione

Quando una sezione viene creata o utilizzata attivamente da un workload, il controller della sezione applica etichette per identificare il workload che la utilizza. Poiché i nomi delle sezioni vengono generati in modo dinamico (e sono disaccoppiati dal nome del workload quando è abilitato il riutilizzo), devi utilizzare queste etichette per trovare la sezione assegnata al tuo workload.

1. Per trovare le sezioni assegnate a un workload, esegui questo comando:

   kubectl get slice -l kueue.gke.io/tpu-slice-used-by-namespace=NAMESPACE,kueue.gke.io/tpu-slice-used-by-workload=WORKLOAD_NAME
   

   Sostituisci quanto segue:

   • NAMESPACE: lo spazio dei nomi del workload.
   • WORKLOAD_NAME: il nome del workload Kueue, che di solito corrisponde al nome del job o del JobSet.
   Nota: se WORKLOAD_NAME contiene più di 63 caratteri, viene tagliato automaticamente per l'etichetta.

2. Copia il nome dello slice dall'output del comando precedente.

3. Utilizza il nome della sezione per controllare lo stato dettagliato della sezione dinamica:

   kubectl describe slice SLICE_NAME
   

   Sostituisci SLICE_NAME con il nome del tuo slice.

L'output è simile al seguente:

Name:         s-4x4x4-74d3fb0b
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-02-12T23:44:28Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1770939905695871008
  UID:               6dbbfe14-4486-4462-864d-e078d0ca8b5b
Spec:
  Partition Ids:
    5eae6a4f59d59cf30a9bf49de618eb2b
  Topology:  4x4x4
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-02-12T23:45:05Z
    Message:
    Reason:                ACTIVE
    Status:                True
    Type:                  Ready
    Last Transition Time:  2026-02-12T23:45:05Z
    Message:               NodeLabelingCompleted
    Reason:                NodeLabelIsAdded
    Status:                True
    Type:                  NodeLabeled
Events:                    <none>

Monitora le metriche della sezione

Puoi monitorare le seguenti metriche di sistema di GKE che mostrano la condizione di una sezione:

• kubernetes.io/accelerator/slice/state
• kubernetes.io/accelerator/partition/state
• kubernetes.io/accelerator/slice/deformation_durations
• kubernetes.io/accelerator/slice/formation_durations

Per saperne di più sulle metriche, consulta Metriche di sistema di GKE.

Metriche del controller Kueue Slice

Puoi anche monitorare le seguenti metriche di Prometheus esposte dal controller Kueue Slice per osservare il ciclo di vita, il riutilizzo e i controlli di ammissione delle sezioni:

Metriche del ciclo di vita di Slice

Le metriche del ciclo di vita delle sezioni monitorano la creazione e l'eliminazione delle sezioni:

• tpu_ac_slice_create_time: istogramma che misura il tempo impiegato per la creazione della sezione.
• tpu_ac_slices_created: sezioni create dal monitoraggio dei contatori (include un'etichetta is_reusable).
• tpu_ac_slices_status: indicatore che monitora il numero attuale di sezioni in base allo stato, incluse le etichette is_reusable e in_use.
• tpu_ac_slice_delete_time: istogramma che misura il tempo impiegato per l'eliminazione della sezione.
• tpu_ac_slices_deleted: contatore che monitora le sezioni eliminate.
• tpu_ac_slices_gc: il monitoraggio dei contatori ha eseguito automaticamente la pulizia delle sezioni.

Metriche di riutilizzo delle sezioni

Le metriche di riutilizzo degli slice monitorano il riutilizzo riuscito e i conflitti degli slice TPU:

• tpu_ac_slices_reused: il monitoraggio dei contatori ha riutilizzato correttamente le sezioni.
• tpu_ac_slices_conflict: contatore che monitora le sezioni eliminate a causa di mancate corrispondenze di topologia o forma.

Metriche relative a workload e ammissione

Le metriche relative ai workload e alle ammissioni monitorano la durata e i risultati dei controlli di ammissione:

• tpu_ac_admission_time: istogramma che misura la durata del processo di controllo di ammissione. Nota: questo valore misura la durata del controllo di ammissione del controller di sezione e non include il tempo di ammissione complessivo del workload Kueue.
• tpu_ac_workload_processed: contatore delle decisioni di controllo di ammissione, contenente un'etichetta target_state.

Metriche generali

Le metriche generali monitorano i problemi operativi e gli errori:

• tpu_ac_problem: un contatore che monitora problemi o errori operativi. Questa metrica include un'etichetta problem che indica il tipo di errore specifico.

  Nota: a causa della riconciliazione simultanea, potresti visualizzare occasionali errori del server API (etichettati come API_SERVER_ERROR). Questi errori possono verificarsi, ad esempio, quando il sistema modifica una risorsa obsoleta. Non indicano necessariamente un errore di sistema.

Esegui la pulizia

Per evitare addebiti imprevisti, elimina le sezioni prima di eliminare i node pool.

1. Elimina il JobSet. Questa azione attiva Kueue per eliminare le risorse personalizzate Slice associate.

   kubectl delete jobset JOBSET_NAME
   

   Sostituisci JOBSET_NAME con il nome del tuo JobSet, ad esempio big-super-slice.

   Nota: le risorse personalizzate Active Slice bloccano l'eliminazione del pool di nodi per garantire che le risorse vengano ripulite correttamente. L'eliminazione del JobSet garantisce che Kueue esegua la pulizia delle risorse personalizzate Slice prima di procedere con l'eliminazione del pool di nodi pool.

2. Elimina il pool di nodi TPU:

   gcloud container node-pools delete NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION
   

(Facoltativo) Utilizza lo slicing dinamico con il tuo scheduler

Questo documento si concentra sull'utilizzo di Kueue e TAS. Tuttavia, puoi anche gestire lo slicing dinamico con il tuo scheduler personalizzato. Se scegli di utilizzare uno scheduler diverso, segui le informazioni di riferimento sulla risorsa personalizzata Slice.

Passaggi successivi

• Scopri di più sul TPU Cluster Director.
• Scopri come gestire gli eventi di manutenzione con le TPU in modalità All Capacity.
• Scopri come eseguire il deployment dei workload Cloud TPU con lo slicing dinamico in Cluster Toolkit.