Pianificare le sezioni dinamiche con Kueue e TAS

Questo documento spiega come eseguire il provisioning dei pool di nodi TPU e pianificare le sezioni dinamiche in Google Kubernetes Engine (GKE) utilizzando Kueue e Topology Aware Scheduling (TAS).

Puoi anche utilizzare la suddivisione dinamica interagendo direttamente con Suddividi risorse personalizzate. Per saperne di più, consulta Utilizzare lo slicing dinamico con uno scheduler personalizzato.

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

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.

Utilizzare lo slicing dinamico in GKE con Kueue

Questa sezione descrive il flusso di lavoro per l'utilizzo della suddivisione dinamica in GKE.

  1. Visualizza la topologia e lo stato di integrità delle prenotazioni in modalità All Capacity.
  2. Abilita il controller di slice 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 sul sezionamento dinamico con Kueue.
  7. Libera spazio.

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

Installa Kueue, JobSet e LWS

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

Installare 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 la suddivisione secondaria dinamica, utilizza Kueue v0.18.2 o versioni successive. Per la suddivisione dinamica, 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 la suddivisione secondaria dinamica, utilizza JobSet v0.12.0 o versioni successive. Per la super-slicing dinamica, utilizza JobSet v0.11.1 o versioni successive.

Installare LWS

LeaderWorkerSet (LWS) è obbligatorio solo per la suddivisione secondaria dinamica.

Segui le istruzioni riportate nella documentazione di LWS o esegui il seguente 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 0.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à TPU in node pool composti da gruppi di 16 nodi di VM Ironwood (TPU7x) o sottoblocchi. GKE esegue il provisioning di questi pool di nodi 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 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 di 16 nodi specifico di VM Ironwood (TPU7x) 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.

Creare una sezione dinamica con Kueue e TAS

In questa sezione, pianifichi i carichi di lavoro GKE con Kueue e TAS.

Installa il controller delle sezioni di Kueue

  1. Per installare il controller delle sezioni di 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: ClusterRole
metadata:
  labels:
    control-plane: controller-manager
  name: slice-controller-manager-role
rules:
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - nodes
  - pods
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - list
  - update
  - 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:
  - admissionregistration.k8s.io
  resources:
  - mutatingwebhookconfigurations
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - batch
  resources:
  - jobs
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - jobset.x-k8s.io
  resources:
  - jobsets
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - leaderworkerset.x-k8s.io
  resources:
  - leaderworkersets
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - kueue.x-k8s.io
  resources:
  - admissionchecks
  - admissionchecks/status
  - workloads/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - kueue.x-k8s.io
  resources:
  - workloads
  verbs:
  - create
  - 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: 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=6m
        command:
        - /manager
        image: tpuongke/kueue-slice-controller:latest
        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: 12000m
            memory: 32Gi
          requests:
            cpu: 8000m
            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

  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 la suddivisione dinamica definendo le seguenti risorse:

    • Topologia dinamica delle slice Ironwood (TPU7x) (superslice-topology): la topologia definisce i livelli che Kueue prende in considerazione quando pianifica i carichi di lavoro 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 sottoblocchi 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 i relativi taint.
    • ResourceFlavor SuperSlice Ironwood (TPU7x) (superslice-rf): il resource flavor per i sottoblocchi 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 carico di lavoro finché il controller delle slice GKE non conferma che la slice è diventata attiva. Il controllo di ammissione viene prima definito e poi aggiunto al ClusterQueue che gestisce i carichi di lavoro 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 gestione della quota e della condivisione equa.
      • Quota illimitata: imposta il campo nominalQuota su un valore molto alto, ad esempio "999999", per simulare una quota illimitata. Per concentrarsi su TAS e sullo slicing dinamico, questa configurazione bypassa la funzionalità di gestione delle quote di Kueue.

Definisci la selezione dello stato di integrità della partizione

Oltre all'integrità e alla disponibilità 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 delle sezioni, ad esempio lo stato dei link TPU. La configurazione del sottosezionamento dinamico (topologie più piccole di 4x4x4) richiede GKE versione 1.36.0-gke.3712000 o successive.

Puoi definire il valore dell'etichetta dello stato della partizione nel seguente modo:

  • HEALTHY: la partizione è integra e completamente funzionante.
  • DEGRADED: l'infrastruttura della partizione è in uno stato di degrado, ad esempio a causa del degrado del collegamento OCS. La partizione può comunque formare una sezione, ma il rendimento complessivo potrebbe essere inferiore rispetto alle partizioni integre. Questo stato si applica solo alla topologia 4x4x4 di primo livello. Le topologie più piccole non hanno uno stato degradato.
  • UNHEALTHY: la partizione non è integra e non può formare una sezione.
  • UNSET: lo stato non è definito a causa dell'inizializzazione non riuscita del controller di slice GKE.
  • INCOMPLETE: non tutti i nodi all'interno della partizione vengono sottoposti al provisioning.

Il webhook del controller delle sezioni di Kueue convalida se un carico di lavoro include un requisito di integrità della partizione specifico. Se non viene indicata alcuna preferenza, il webhook inserisce un'affinità del 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 etichetta 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 sottoblocchi.

Esegui workload di test sullo slicing dinamico con Kueue

Questa sezione descrive come eseguire il deployment dei workload sul dynamic slicing con Kueue e TAS. Include esempi che mostrano come creare un workload di slice dinamico e un workload costituito da più slice. I carichi di lavoro vengono inviati come JobSet.

Esempio 1: un singolo workload utilizza una singola sezione dinamica

Il seguente esempio descrive come creare un workload utilizzando una sezione con una topologia 4x12x16, composta da 12 blocchi secondari. 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 slice da configurare:

    • cloud.google.com/gke-tpu-slice-topology: specifica "4x12x16" come topologia della sezione dinamica. I requisiti per la topologia dell'acceleratore tpu7x includono le seguenti regole:
      • 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 la configurazione del 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; deve essere 4x4x8.
      • Il prodotto delle dimensioni (ABC) non deve superare 9216.
      • Le topologie di slice più grandi supportate possono includere fino a 32 sub-blocchi. 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 JobSet a una LocalQueue di Kueue.
    • Il webhook inserisce l'affinità nodo 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. Una volta attiva la 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 dinamiche, ciascuna composta 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 dinamiche per il workload e attende che tutte le slice diventino attive prima di ammettere il workload.

Monitorare la sezione

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

Monitorare lo stato dello slice

Per controllare lo stato delle sezioni dinamiche, esegui questo comando:

kubectl describe slice SLICE_NAME

Sostituisci SLICE_NAME con il nome della tua sezione. Il nome della sezione viene in genere derivato dal nome di JobSet e dall'indice di replica. Per l'esempio 1, una sezione creata da Kueue avrebbe un nome simile a default-jobset-big-super-slice-yyyyy-job-jax-0.

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

Il nome della sezione rispetta le seguenti regole per garantire la compatibilità con le convenzioni di denominazione delle risorse Compute Engine sottostanti:

  • Modello: {namespace}-jobset-{jobset.metadata.name}-kueueHash[5-character]-{jobset.spec.replicatedJobs[].name}-sliceIndex.
  • Lunghezza: il nome contiene al massimo 49 caratteri. Il controller aggiunge un trattino e un hash del cluster di 8 caratteri per creare nomi di risorse Compute Engine, che hanno un limite di 63 caratteri.
  • Format: il nome corrisponde all'espressione regolare ^[a-z]([-a-z0-9]*[a-z0-9])?$. Il nome ha le seguenti caratteristiche:
    • Inizia con una lettera minuscola.
    • Contiene solo lettere minuscole, numeri e trattini (-).
    • Termina con una lettera minuscola o un numero (non può terminare con un trattino).

Monitora le metriche della sezione

Puoi monitorare le seguenti metriche di sistema di GKE che mostrano le condizioni 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 maggiori informazioni sulle metriche, consulta Metriche di sistema di GKE.

Esegui la pulizia

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

  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 JobSet, ad esempio big-super-slice.

  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 pianificatore

Questo documento è incentrato sull'utilizzo di Kueue e TAS. Tuttavia, puoi anche gestire la suddivisione dinamica con il tuo pianificatore personalizzato. Se scegli di utilizzare uno scheduler diverso, segui le informazioni di riferimento della risorsa personalizzata Slice.

Passaggi successivi