Usa el segmentado dinámico con un programador personalizado

En este documento, se describe cómo usar el segmentado dinámico interactuando directamente con los recursos personalizados de Slice. Puedes crear segmentos, supervisar los estados de las particiones y verificar el estado de los segmentos.

Antes de seguir estas instrucciones, asegúrate de comprender los conceptos del segmentado dinámico.

¿Por qué usar el segmentado dinámico con un programador personalizado?

Usa tu propio programador para administrar los recursos personalizados de Slice si tienes requisitos de programación complejos o si deseas integrar el segmentado dinámico con tu infraestructura de programación existente.

En caso de que prefieras usar un programador en lugar de administrar los recursos personalizados de Slice directamente, GKE proporciona integración con Kueue y Topology Aware Scheduling (TAS). Para obtener más información, consulta Cómo programar segmentos dinámicos con Kueue y TAS.

Descripción general del flujo de trabajo

Para usar la segmentación dinámica con un programador personalizado, realiza las siguientes tareas que se describen en este documento:

  1. Habilita el controlador de segmentos.
  2. Crea grupos de nodos con aprovisionamiento incremental.
  3. Crea recursos personalizados de Slice según los requisitos de tu carga de trabajo. Aplica el recurso personalizado de Slice a tu clúster.
  4. Supervisa los estados de las particiones y el estado de las segmentaciones.
  5. Borra el segmento cuando termines.

Para obtener más información sobre los campos y el estado del recurso personalizado Slice, consulta la información de referencia del recurso personalizado Slice.

Requisitos

Para usar la segmentación dinámica en GKE, debes cumplir con los siguientes requisitos:

  • Usa un clúster estándar en el canal rápido en una de las siguientes versiones:
    • Para la configuración dinámica de supersegmentación (topologías iguales o mayores que 4x4x4), usa la versión 1.35.2-gke.1842000 o posterior.
    • Para la configuración dinámica de división en subsegmentos (topologías más pequeñas que 4x4x4), usa la versión 1.36.0-gke.3712000 o posterior.
  • Usa la versión de Ironwood (TPU7x).
  • Usa la imagen de Container-Optimized OS para tus nodos.
  • Para usar el aprovisionamiento incremental, usa las reservas del modo All Capacity. El modo All Capacity es una función que habilita Cluster Director de TPU.
  • En el caso de la sublicencia dinámica, asegúrate de que tus nodos tengan eventos de mantenimiento pendientes. Supervisa tus instancias para detectar eventos de mantenimiento pendientes. Si alguno de tus nodos tiene un evento de mantenimiento pendiente con una hora de finalización entre el 18 y el 30 de septiembre de 2026, debes activar manualmente el evento de mantenimiento del host en esos nodos antes de poder usar la sublicencia.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Kubernetes Engine.
    • Habilitar la API de Google Kubernetes Engine
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste la gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos que se indican en este documento.

Habilita el controlador de segmentos

Para usar el segmentado dinámico, habilita el controlador de segmentación en tu clúster.

  1. Actualiza tu clúster:

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

    Reemplaza lo siguiente:

  2. Obtén credenciales para que puedas comunicarte con tu clúster con los comandos de kubectl:

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

  3. En el resultado del siguiente comando, verifica que esté presente el valor slices.accelerator.gke.io:

    kubectl get crd slices.accelerator.gke.io

    El resultado es similar a lo siguiente:

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

Crea grupos de nodos con aprovisionamiento incremental

En esta sección, se describe cómo crear los grupos de nodo TPU con aprovisionamiento incremental. GKE convierte toda tu capacidad de TPU en grupos de nodos de grupos de 16 nodos de VMs de TPU o subbloques. GKE aprovisiona estos grupos de nodos incluso cuando no puede encontrar las 16 VMs en buen estado. Para ello, coloca nodos en las partes en buen estado de la máquina anfitrión y aprovisiona de forma incremental las máquinas en mal estado mientras se reparan.

Puedes segmentar tu grupo de nodos para que pertenezca a cualquiera de los siguientes:

  • Es un bloque específico de TPUs que se expone en las reservas del modo All Capacity. El bloqueo de segmentación permite que GKE cree el grupo de nodos en cualquier subbloque disponible dentro del bloque especificado.
  • Un subbloque específico o un grupo específico de 16 nodos de VMs de TPU para un control más detallado

Crear una política de cargas de trabajo

Para crear un grupo de nodos de porción de TPU con Ironwood (TPU7x), primero debes crear una política de cargas de trabajo con el campo accelerator-topology-mode establecido en provision_only. Este parámetro de configuración activa el proceso de aprovisionamiento incremental.

Crea una política de cargas de trabajo:

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

Reemplaza lo siguiente:

  • WORKLOAD_POLICY_NAME: Es un nombre para tu política de carga de trabajo.
  • PROJECT_ID: Es el ID del proyecto de Google Cloud .
  • REGION: Es la región de la política de carga de trabajo.

En este comando, haz lo siguiente:

  • Siempre configura el campo accelerator-topology como 4x4x4 para que coincida con la cantidad total de chips dentro de un solo subbloque.
  • Siempre establece el campo accelerator-topology-mode en provision_only para garantizar que se active el proceso de aprovisionamiento incremental. Cuando se configura el campo provision_only, el grupo de nodos aprovisiona nodos TPU sin formar vínculos de ICI ni de OCS.

Segmenta tu grupo de nodos para que pertenezca a un bloque o a un subbloque

Puedes segmentar tu reserva en el modo All Capacity para que se muestre en bloques o subbloques específicos.

  • Segmento objetivo: Cada grupo de nodos usa capacidad de un segmento especificado. GKE coloca el grupo de nodos dentro de un subbloque disponible en ese bloque. Debes crear tantos grupos de nodos como subbloques haya en el bloque que quieras usar.

  • Segmenta un subbloque: Cada grupo de nodos se asigna a un subbloque específico y disponible. Cuando se usa la segmentación por subbloque, GKE crea el grupo de nodos si al menos una VM está en buen estado. El aprovisionamiento incremental ayuda a garantizar que todos los nodos se coloquen dentro del subbloque especificado.

Bloquear

  1. Para recuperar el nombre del bloque en una reserva y el recuento de subbloques disponibles en el bloque, completa los siguientes pasos en el documento Visualiza la topología y el estado de las reservas en el modo All Capacity:

    1. Para identificar el nombre del bloque, enumera todos los bloques de reserva y copia el valor del campo name:. Este valor es el nombre del bloque o BLOCK_NAME en este documento.

    2. Para determinar cuántos grupos de nodos crear, describe un bloque de reserva y, luego, identifica el valor en el campo reservationSubBlockCount. Este valor es la cantidad de subbloques disponibles. Por ejemplo, el valor reservationSubBlockCount: 4 indica que el bloque tiene cuatro subbloques disponibles y que debes crear cuatro grupos de nodos separados.

  2. Establece la ruta de reserva:

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

    Reemplaza lo siguiente:

    • RESERVATION_NAME: Es el nombre de tu reserva de TPU.
    • BLOCK_NAME: Es el nombre del bloque.

  3. Crea un grupo de nodos para cada subbloque identificado en el paso anterior. Por ejemplo, si el recuento es 4, ejecuta este comando cuatro veces. Usa un nombre único para cada grupo de nodos.

    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}

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: es el nombre de tu grupo de nodos nuevo.
    • CLUSTER_NAME: Es el nombre del clúster de GKE.
    • WORKLOAD_POLICY_NAME: Es el nombre de la política de cargas de trabajo que creaste.
    • ZONE: Es la zona del grupo de nodos, por ejemplo, us-central1-a.

En subbloque

  1. Para recuperar el nombre del bloque y los IDs de los subbloques disponibles, completa los siguientes pasos en el documento Visualiza la topología y el estado de las reservas en el modo All Capacity:

    1. Para identificar el nombre del bloque, enumera todos los bloques de reserva y copia el valor del campo name:. Este valor es el nombre del bloque o BLOCK_NAME en este documento.

    2. Para identificar el nombre de los subbloques, enumera todos los subbloques de un bloque y copia el valor del campo name: para cada entrada en reservationSubBlocks. Este valor es el nombre del subbloque o SUBBLOCK_NAME en este documento.

  2. Establece la ruta de reserva:

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

    Reemplaza lo siguiente:

    • RESERVATION_NAME: Es el nombre de tu reserva de TPU.
    • BLOCK_NAME: Es el nombre del bloque.
    • SUBBLOCK_NAME: Es el nombre del subbloque.

  3. Crea el grupo de nodos:

    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}

    Reemplaza lo siguiente:

    • NODE_POOL_NAME: Es un nombre único para tu nuevo grupo de nodos, por ejemplo, sub-block-pool-1.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • CLUSTER_NAME: el nombre del clúster de GKE.
    • ZONE: Es la zona del grupo de nodos, por ejemplo, us-central2-b.
    • WORKLOAD_POLICY_NAME: Es el nombre de la política de carga de trabajo que creaste.

En esta etapa, se crean los nodos, pero sus vínculos de interconexión entre chips (ICI) aún no están activos. Por lo tanto, no puedes ejecutar cargas de trabajo en estos grupos de nodos directamente.

Para habilitar todos los vínculos de ICI necesarios para formar la segmentación y permitir que se programen las cargas de trabajo, crea una segmentación dinámica con uno de los siguientes métodos:

  • Crea un recurso personalizado de Slice. En lugar de Pods, usas un recurso personalizado de Slice para definir la topología especificada, que el controlador de segmentación activa.
  • Programa cargas de trabajo de GKE con Kueue y TAS. Kueue controla automáticamente la creación y eliminación de recursos personalizados de Slice. Evita modificar de forma manual los recursos personalizados de Slice creados por Kueue.

Cómo formar una segmentación dinámica con la supersegmentación o la subsegmentación

Después de crear los grupos de nodos, puedes formar una supersegmentación dinámica más grande o una subsegmentación dinámica más pequeña creando un recurso personalizado de Slice. Un recurso personalizado de Slice define la topología especificada, que el controlador de segmentación activa. Luego, tus cargas de trabajo se programan y ejecutan en esta segmentación dinámica.

Particiones de segmentos dinámicos

Las particiones proporcionan las topologías disponibles para formar un segmento dinámico para tus cargas de trabajo. Una partición muestra todas las topologías disponibles para cada nodo, incluidas 2x2x1, 2x2x2, 2x2x4, 2x4x4 y 4x4x4. Las topologías más pequeñas que 4x4x4 requieren la versión 1.36.0-gke.3712000 de GKE o una posterior.

Las segmentaciones mayores que 4x4x4 no tienen una etiqueta de partición, ya que se crean asociando varias particiones de 4x4x4.

Cada nodo TPU de un grupo de nodos de aprovisionamiento incremental debe tener cada ID de partición y etiqueta de nodo de estado de partición especificados.

Verifica el estado de los nodos y las particiones

  1. Para obtener los nombres de los nodos del grupo de nodos, ejecuta el siguiente comando:

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

    El resultado es similar al siguiente:

    NAME                                 STATUS   ROLES    AGE    VERSION
gke-np-status-update-7b4c890c-0jhp   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-377r   Ready    <none>   2d1h   v1.35.1-gke.1396002
gke-np-status-update-7b4c890c-gb51   Ready    <none>   2d1h   v1.35.1-gke.1396002

  2. Verifica el modelo de aprovisionamiento del nodo:

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

    El resultado es similar al siguiente:

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

  3. Recupera la información de la etiqueta del nodo para la partición de la topología a la que deseas segmentar:

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

    Reemplaza NODE_NAME por el nombre de uno de los nodos del grupo de nodos.

    El resultado es similar al siguiente:

    cloud.google.com/gke-tpu-partition-4x4x4-id=fba785f80d18552357dcdef6d3d16c27
cloud.google.com/gke-tpu-partition-2x4x4-id=e18372d627ac412cb24d5ea8ab8912c9
cloud.google.com/gke-tpu-partition-2x2x4-id=7fbd4e29dc1839217fae41a9dd8211b4
cloud.google.com/gke-tpu-partition-2x2x2-id=a9476d1b02bd4f4e75ffffae3bd23c01
cloud.google.com/gke-tpu-partition-2x2x1-id=0bcfe937d1bb3914a8bdcd94e9f73319

  4. Verifica que el nodo incluya la anotación node.gke.io/created-by-mig:

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

    Reemplaza NODE_NAME por el nombre de uno de los nodos del grupo de nodos.

    El resultado es similar al siguiente:

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

    El resultado incluye la anotación node.gke.io/created-by-mig, que permite que el plano de control de GKE vincule los nodos de Kubernetes a sus recursos subyacentes de Compute Engine.

  5. Recupera la información de la etiqueta del nodo para el estado de partición de la topología que deseas verificar:

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

    El resultado es similar al siguiente:

    cloud.google.com/gke-tpu-partition-4x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x4x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x4-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x2-state=HEALTHY
cloud.google.com/gke-tpu-partition-2x2x1-state=HEALTHY

    La etiqueta cloud.google.com/gke-tpu-partition-[shape]-state (en la que [shape] corresponde a la topología del ID de partición) indica si la partición está disponible para formar una segmentación dinámica. Esta etiqueta de estado admite los siguientes valores:

    • HEALTHY: La partición está en buen estado y es completamente funcional.
    • DEGRADED: La partición está dañada, pero aún se puede usar para la formación de segmentos dinámicos. Este estado solo se aplica a la topología 4x4x4 de nivel superior. Las topologías más pequeñas no tienen un estado degradado.
    • UNHEALTHY: La partición no funciona correctamente y no se puede usar para formar un segmento.
    • UNSET: El estado no está definido debido a que no se pudo inicializar el controlador de segmentos de GKE.
    • INCOMPLETE: No se aprovisionaron todos los nodos dentro de la partición.

Crea un recurso personalizado de Slice

El recurso personalizado Slice varía un poco según si creas una superrebanada dinámica o una subrebanada dinámica.

  1. Define el recurso personalizado de Slice:

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  # Name of the slice resource
  name: SLICE_NAME
spec:
  # Specify the type of accelerator for this slice
  type: "tpu7x"
  # Define the desired topology for the accelerator slice
  topology: TOPOLOGY
  partitionIds:
    - PARTITION_ID # Example: a9476d1b02bd4f4e75ffffae3bd23c01
    - PARTITION_ID_2
    # ... add more partition IDs as needed

    Reemplaza lo siguiente:

    • SLICE_NAME: Es un nombre para tu segmento. El nombre debe cumplir con las condiciones de metadata.name y tener 49 caracteres o menos.
    • TOPOLOGY: Es la topología de la porción dinámica. La topología debe cumplir con las siguientes condiciones:
      • Para la división en subsegmentos dinámica: Puedes especificar topologías más pequeñas que 4x4x4, como 2x2x1, 2x2x2, 2x2x4 o 2x4x4. Estas topologías más pequeñas requieren la versión 1.36.0-gke.3712000 de GKE o una posterior.
      • Para el supercorte dinámico: Puedes especificar topologías iguales o superiores a 4x4x4. Para configurar la segmentación dinámica avanzada, cada dimensión de la topología solicitada debe ser un múltiplo de cuatro, por ejemplo, 4A x 4B x 4C. Los tres valores de las dimensiones de la topología, AxBxC, deben estar en orden no decreciente (A ≤ B ≤ C). Por ejemplo, 4x4x8 es válido, pero 4x8x4 no lo es. Este orden ayuda a garantizar una formación de segmentos coherente y evita comportamientos inesperados. El producto de los tres valores en las dimensiones de topología, A × B × C, no debe exceder los 9,216.
    • PARTITION_ID: Es una lista de cadenas que identifican las particiones que componen el segmento.
      • Para la segmentación secundaria dinámica: Debes especificar exactamente un ID de partición.
      • Para el supersegmentado dinámico: Debes calcular la cantidad de particiones en función de la cantidad total de chips, donde cada partición consta de 64 chips. La cantidad de elementos de tu lista de spec.partitionIds debe coincidir exactamente con la cantidad calculada de particiones ((A × B × C) / 64).
      • La lista partitionIds debe cumplir con las siguientes condiciones:
        • Cada partición debe asignarse a un subbloque de reserva.
        • Todos los subbloques asociados deben pertenecer a la misma reserva.
        • Todos los subbloques asociados deben residir en la misma reserva.
        • Los grupos de nodos asociados deben tener todos los nodos en estado ready.
    • El valor del campo type debe ser tpu7x.
    • De manera opcional, para habilitar el controlador de segmentos para que vuelva a intentar automáticamente la formación de segmentos, puedes agregar la anotación slice.gke.io/retry-on-failure: "true" al recurso personalizado de segmento. Si no se crea el segmento debido al motivo de estado SliceCreationFailed, el controlador volverá a intentarlo hasta que se forme correctamente.

    Por ejemplo, para crear un segmento 4x8x8 (segmentación avanzada dinámica), debes proporcionar cuatro IDs de partición únicos.

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
    name: test-super-slice-example
    annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
    type: "tpu7x"
    topology: "4x8x8" # (4*8*8)/64 = 4 partitions
    partitionIds:
        - "p0-4x4x4"
        - "p1-4x4x4"
        - "p2-4x4x4"
        - "p3-4x4x4"

    Por ejemplo, para crear un segmento 2x2x2 (segmentación secundaria dinámica), debes proporcionar un ID de partición único.

    apiVersion: accelerator.gke.io/v1beta1
kind: Slice
metadata:
  name: test-sub-slice-example
  annotations:
      slice.gke.io/retry-on-failure: "true"
spec:
  type: "tpu7x"
  topology: "2x2x2"
  partitionIds:
    - "fba785f80d18552357dcdef6d3d16c27" # Only 1 partitionId for sub-slice

  2. Aplica el recurso personalizado Slice:

    kubectl apply -f test-slice-example.yaml

    En este punto, GKE intenta crear el segmento. Si ocurre uno de los siguientes problemas, falla la creación del segmento y el motivo del estado en el recurso personalizado Slice se actualiza a SliceCreationFailed o FAILED:

    • Si los nodos seleccionados en el recurso personalizado no existen, el motivo del estado es SliceCreationFailed.
    • Si otro segmento usa algún nodo del recurso personalizado, el motivo del estado es SliceCreationFailed.
    • Si los nodos del recurso personalizado no forman parte del mismo subbloque de reserva, el motivo del estado es FAILED.
    • Si los nodos no están en la misma reserva, el motivo del estado es FAILED.
    • Si la topología no coincide con la cantidad de particiones, el motivo del estado es SliceCreationFailed.

    Para reintentar automáticamente la formación de segmentos cuando el estado es SliceCreationFailed, configura la anotación slice.gke.io/retry-on-failure: "true" como se describe en Crea un recurso personalizado de Slice.

    Para obtener más información sobre el estado del recurso personalizado Slice, consulta Estado de Slice.

Supervisa el estado del recurso personalizado de Slice

Para verificar el estado del recurso personalizado de Slice, ejecuta el siguiente comando:

kubectl describe slice SLICE_NAME

Reemplaza SLICE_NAME por el nombre de la segmentación.

El resultado es similar a lo siguiente:

Name:         test-slice
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  accelerator.gke.io/v1beta1
Kind:         Slice
Metadata:
  Creation Timestamp:  2026-01-11T23:45:15Z
  Finalizers:
    accelerator.gke.io/slice-finalizer
  Generation:        1
  Resource Version:  1768175347356335006
  UID:               d0b71e5c-be3f-4788-aead-930c7afec4f2
Spec:
  Partition Ids:
    2c79463990ff67c4e3c2648666bfedfa
    ba898ffcac0ad0946e8ff036d771ee53
    [more partition IDs]
  Topology:  8x16x16
  Type:      tpu7x
Status:
  Conditions:
    Last Transition Time:  2026-01-11T23:45:38Z
    Message:               ""
    
    Reason:                FAILED
    
    Status:                False
    Type:                  Ready
Events:

El campo reason en el estado del recurso personalizado de Slice indica el estado actual del ciclo de vida. Los estados posibles varían según si usas la sublicencia dinámica o la superlicencia dinámica.

Condiciones de estado para la segmentación secundaria dinámica

  • SliceNotCreated: El controlador realiza la inicialización y las verificaciones de recursos.
    • Si no se cumplen los requisitos previos, el estado pasa a SliceCreationFailed.
    • Si la validación se aprueba, el estado cambia a ACTIVATING.
  • ACTIVATING: GKE está formando la porción.
    • Si se ejecuta de forma correcta, el estado cambia a ACTIVE.
    • Si los subbloques están degradados, pero el segmento es utilizable, el estado cambia a ACTIVE_DEGRADED.
    • Si falla la formación, el estado pasa a FAILED.
  • DEACTIVATING: Si se borra el recurso personalizado de Slice o se produce una falla crítica en un estado activo o fallido, el segmento comienza a desmantelarse.
  • INCOMPLETE: Es el paso final antes de que se borre el recurso por completo.

Condiciones de estado para el supercorte dinámico

  • SliceNotCreated: Aún no se creó la división. El controlador de segmentación se está inicializando y realizando verificaciones previas para la formación de segmentos.
  • SliceCreationFailed: La creación falló porque no se cumplieron los requisitos previos (por ejemplo, faltan recursos obligatorios de Compute Engine) o fallaron las verificaciones previas al vuelo. Para volver a intentar automáticamente la formación de segmentos en este estado, configura la anotación slice.gke.io/retry-on-failure: "true".
  • ACTIVATING: La división está en proceso de formación (unión).
  • ACTIVE: La segmentación está completamente formada, en buen estado y lista para ejecutar cargas de trabajo.
  • ACTIVE_DEGRADED: La segmentación se forma, pero incluye cubos degradados, con el respaldo de la resiliencia del ICI. Las cargas de trabajo se pueden ejecutar, pero es posible que el rendimiento se vea afectado. La división dinámica de banda ancha es resistente a las fallas de un solo conmutador de circuito óptico (OCS). Si falla una sola unidad de OCS, todos los vínculos ópticos que atraviesan ese conmutador dejan de estar disponibles, lo que provoca que todos los cubos dentro del superpod funcionen en un estado degradado.
  • DEACTIVATING: La segmentación está en proceso de desmantelamiento.
  • FAILED: La segmentación ya no está lista para ejecutar cargas de trabajo. Este estado se produce si falló la formación inicial o si una porción activa experimentó una falla crítica de software o hardware.
  • INCOMPLETE: No hay suficientes cubos disponibles para iniciar la formación de supersegmentos.

Para obtener más información sobre el estado del recurso personalizado Slice, consulta Estado de Slice.

Ejecuta cargas de trabajo en el corte por porciones dinámico

Cuando el recurso personalizado de Slice está en estado ACTIVE, puedes ejecutar cargas de trabajo en él. En la siguiente sección, se incluyen ejemplos de cargas de trabajo que usan la segmentación dinámica. Las cargas de trabajo se envían como Jobs o JobSets.

Ejemplo 1: Una sola carga de trabajo usa un solo segmento

En el siguiente ejemplo, se muestra una carga de trabajo que usa una sola supersegmentación dinámica 4x4x4.

  1. Guarda el siguiente manifiesto de muestra como tpu-job-jax-v7x-64.yaml:

    # Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: v1
kind: Service
metadata:
  name: headless-svc
spec:
  clusterIP: None
  selector:
    job-name: tpu-job-jax-v7x-64
---
apiVersion: batch/v1
kind: Job
metadata:
  name: tpu-job-jax-v7x-64
spec:
  backoffLimit: 0
  completions: 16
  parallelism: 16
  completionMode: Indexed
  template:
    metadata:
      annotations:
        cloud.google.com/gke-tpu-slice-topology: 4x4x4
    spec:
      nodeSelector:
        cloud.google.com/gke-tpu-topology: 4x4x4
        cloud.google.com/gke-tpu-accelerator: tpu7x
        cloud.google.com/gke-tpu-slice: test-slice
      subdomain: headless-svc
      restartPolicy: Never
      containers:
      - name: tpu-job-jax
        env:
        - name: TPU_ACCELERATOR_TYPE
          value: tpu7x-128
        image: python:3.12
        securityContext:
          privileged: false
        command:
        - bash
        - -c
        - |
          set -ex
          pip install -U --pre jax jaxlib libtpu requests -i https://us-python.pkg.dev/ml-oss-artifacts-published/jax/simple/ -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
          pip list
          python -c 'import jax; print("Total TPU devices (cores):", jax.device_count())'
        resources:
          requests:
            google.com/tpu: 4
          limits:
            google.com/tpu: 4

    En el manifiesto se muestra lo siguiente:

    • cloud.google.com/gke-tpu-slice-topology y cloud.google.com/gke-tpu-topology definen la topología del segmento dinámico.
    • env.value: tpu7x-128 es el tipo de acelerador de TPU y la cantidad total de núcleos en la segmentación. La cantidad de núcleos se calcula multiplicando las dimensiones de la topología por la cantidad de núcleos por chip. Por ejemplo, para una topología 4x4x4, el cálculo es 4 × 4 × 4 × 2 = 128, donde 2 es la cantidad de núcleos por chip para tpu7x (Ironwood [TPU7x]). Por lo tanto, el TPU_ACCELERATOR_TYPE es tpu7x-128.

  2. Aplica el manifiesto tpu-job-jax-v7x-64.yaml:

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

Ejemplo 2: Implementa una carga de trabajo en grupos de nodos de Multislice con JobSet

En este ejemplo, se muestra cómo implementar una carga de trabajo en grupos de nodos de Multislice con JobSet.

  1. Instala JobSet:

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

    Reemplaza JOBSET_VERSION por la versión requerida de JobSet. Para el subsegmento dinámico, usa JobSet v0.12.0 o una versión posterior. Para el supercorte dinámico, usa JobSet v0.11.1 o una versión posterior.

  2. Guarda el siguiente manifiesto de muestra como tpu-multislice-jax.yaml:

    # Copyright 2026 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#      http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

apiVersion: jobset.x-k8s.io/v1alpha2
kind: JobSet
metadata:
  name: tpu-multislice-jax
  annotations:
    alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice
spec:
  failurePolicy:
    maxRestarts: 3
  replicatedJobs:
  - name: slice-job
    replicas: 2
    template:
      spec:
        parallelism: 16
        completions: 16
        backoffLimit: 0
        completionMode: Indexed
        template:
          metadata:
            annotations:
              # The shape of the slice
              cloud.google.com/gke-tpu-slice-topology: 4x4x4
          spec:
            hostNetwork: true
            dnsPolicy: ClusterFirstWithHostNet
            nodeSelector:
              cloud.google.com/gke-tpu-topology: 4x4x4
              cloud.google.com/gke-tpu-accelerator: tpu7x
              # IMPORTANT: Do NOT put 'cloud.google.com/gke-tpu-slice' here manually.
              # The exclusive-topology annotation handles the slice assignment automatically.
            containers:
            - name: jax-worker
              image: python:3.12
              securityContext:
                privileged: true
              ports:
              - containerPort: 8471
              command:
              - bash
              - -c
              - |
                set -ex
                pip install -U --pre jax jaxlib libtpu requests -f https://storage.googleapis.com/jax-releases/libtpu_releases.html
                # Verify JobSet injected the specific slice ID for this worker
                echo "JobSet Index: $JOB_COMPLETION_INDEX"
                python -c 'import jax; print("Total TPU devices:", jax.device_count())'
              resources:
                requests:
                  google.com/tpu: 4
                limits:
                  google.com/tpu: 4

  3. Aplica el manifiesto tpu-multislice-jax.yaml:

    kubectl apply -f tpu-multislice-jax.yaml

    En el manifiesto se muestra lo siguiente:

    • El campo replicas: 2 en replicatedJobs indica que JobSet crea dos Jobs separados, cada uno correspondiente a una porción de TPU 4x4x4.
    • La anotación alpha.jobset.sigs.k8s.io/exclusive-topology: cloud.google.com/gke-tpu-slice ayuda a garantizar que cada trabajo se asigne a una porción de TPU única.
    • La anotación cloud.google.com/gke-tpu-slice-topology: 4x4x4 define la topología de cada porción dinámica.
    • La variable de entorno TPU_ACCELERATOR_TYPE no se configura de forma explícita en este ejemplo, ya que JobSet controla la asignación de segmentos. El código de JAX detecta automáticamente los dispositivos TPU disponibles dentro de su segmento asignado.

Borra el segmento

  1. Borra la segmentación:

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

  2. Verifica que se haya borrado el segmento:

    kubectl get slices

Actualiza los grupos de nodos

Si actualizas grupos de nodos configurados con aprovisionamiento incremental, debes usar parámetros de aumento específicos para evitar conflictos de capacidad.

Para configurar y ejecutar la actualización del grupo de nodos, haz lo siguiente:

  1. Si usas el supercorte dinámico, borra los cortes activos antes de realizar el mantenimiento manual:

    kubectl delete slice SLICE_NAME

    Si usas la segmentación secundaria dinámica, no es necesario que borres primero los segmentos activos. Sin embargo, las subsegmentaciones que permanezcan activas durante una actualización fallarán y pasarán a un estado FAILED.

  2. Actualiza los parámetros de actualización de tu grupo de nodos:

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

    Asegúrate de que el campo --max-surge-upgrade esté establecido en un valor de 0 para evitar que GKE intente asignar TPU adicionales durante la actualización. Te recomendamos que configures el campo --max-unavailable-upgrade=16 para actualizar un subbloque completo de 16 nodos de forma simultánea.

  3. Actualiza el grupo de nodos:

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

Mantenimiento y fallas de hardware

Si activas el mantenimiento iniciado por el cliente o si se produce una conmutación por error de hardware, solo se verán afectados los nodos objetivo, y no todo el grupo de nodos.

En el caso del supercorte dinámico, debes borrar los cortes dinámicos activos antes de realizar el mantenimiento manual. Si usas la segmentación secundaria dinámica, no es necesario que borres primero los segmentos activos. Si se producen fallas de hardware o de mantenimiento mientras una porción secundaria dinámica está activa, el sistema controla la recuperación de la siguiente manera:

  1. Cambio de forma automatizado: GKE cambia automáticamente la forma de la porción dinámica activa cuando comienza el mantenimiento en un host asociado.
  2. Falla del recurso personalizado de segmentación: El recurso personalizado de Slice pasa a un estado FAILED.
  3. Observación del programador: El programador observa el estado de error del recurso personalizado Slice.
  4. Proceso de reformación: El programador intenta automáticamente volver a crear las configuraciones de segmentos en otros nodos disponibles en buen estado.

Inhabilita el Slice Controller

Para inhabilitar el controlador de segmentación, quítalo del clúster.

  1. Verifica que los recursos personalizados de Slice estén vacíos:

    kubectl get slice -A

  2. Actualiza el clúster para inhabilitar el controlador de segmentación:

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

  3. Borra el recurso personalizado de Slice :

    kubectl delete crd slices.accelerator.gke.io

  4. Verifica que se haya borrado el recurso personalizado Slice:

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

  5. Quita las etiquetas agregadas por el controlador de segmentación. Debes quitar estas etiquetas:

    • cloud.google.com/gke-tpu-slice
    • cloud.google.com/gke-tpu-topology
    1. Para quitarlo de un nodo específico, actualiza el nombre del nodo.
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl label node $NODE_NAME cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    1. Si quieres quitar estas etiquetas de todos los nodos de tu clúster, haz lo siguiente:
    kubectl label nodes --all cloud.google.com/gke-tpu-slice- cloud.google.com/gke-tpu-slice-topology-
    1. Verifica las etiquetas del nodo y confirma que estén vacías:
    export NODE_NAME="gke-tpu-bdac9600-3bdg"
kubectl describe node $NODE_NAME | grep "cloud.google.com/gke-tpu-slice"

¿Qué sigue?