Entrena modelos de aprendizaje automático a gran escala en GKE con Multi-Tier Checkpointing

En esta página, se muestra cómo usar los puntos de control de varios niveles para almacenar y administrar puntos de control de forma confiable durante el entrenamiento de modelos de aprendizaje automático en GKE. El almacenamiento y la administración de puntos de control son fundamentales para los trabajos de entrenamiento a gran escala, definidos como aquellos que utilizan más de miles de nodos. Las interrupciones de estos trabajos a gran escala son frecuentes (potencialmente cada hora) y la recuperación de ellos puede ser lenta.

Beneficios

El uso de puntos de control de varios niveles proporciona los siguientes beneficios:

  • Administración de datos de puntos de control completamente organizada, incluidas copias de seguridad, replicación y restablecimiento automático para las siguientes cargas de trabajo:
  • Recuperación rápida de trabajos de entrenamiento desde un punto de control almacenado en el nodo local. También puedes realizar la recuperación con los puntos de control almacenados en otro nodo del clúster de entrenamiento.
  • Restablecimiento rápido de trabajos de entrenamiento desde una copia de seguridad de un punto de control almacenado en Cloud Storage en el peor de los casos, en los que no hay puntos de control en el clúster.

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.

Requisitos

La creación de puntos de control de varios niveles requiere la versión 1.32.4-gke.1415000 o posterior del clúster de GKE.

Limitaciones

  • Los clústeres de Autopilot no son compatibles.

Configura nodos de GKE para usar la creación de puntos de control de varios niveles

En esta sección, se explica cómo configurar los nodos de GKE en clústeres nuevos y existentes.

Configura nodos en un clúster nuevo

  1. Crea un clúster con la creación de puntos de control de varios niveles, el controlador de CSI de Cloud Storage FUSE y la Workload Identity Federation for GKE habilitada. Si usas porciones de TPU para tu carga de trabajo de aprendizaje automático, deberás ajustar el comando de creación del clúster para incluir la configuración de un grupo de nodos de porción de TPU.

    gcloud container clusters create CLUSTER_NAME \
    --addons=HighScaleCheckpointing,GcsFuseCsiDriver  \
    --node-locations=NODE_LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --cluster-version=CLUSTER_VERSION
    --location=CLUSTER_LOCATION \
    --machine-type=MACHINE_TYPE \
    --num-nodes=NUM_NODES

    Reemplaza los siguientes valores:

    • CLUSTER_NAME: el nombre del clúster
    • NODE_LOCATION: Es la zona de los nodos del clúster. Aquí se encuentra tu capacidad de TPU.
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • CLUSTER_VERSION: Es la versión del clúster. La versión mínima compatible es la 1.32.4-gke.1415000.
    • CLUSTER_LOCATION: Es la región en la que deseas crear el clúster.
    • MACHINE_TYPE: Es el tipo de máquina que se usa para los nodos que ejecutan componentes como el controlador de JobSet y el controlador de puntos de control de varios niveles. Para el entrenamiento a gran escala, recomendamos usar al menos e2-standard-4 máquinas. No usarás este tipo de máquina para el entrenamiento de modelos. En cambio, crearás grupos de nodos separados para ese propósito, que a menudo utilizarán familias de VM optimizadas para aceleradores.
    • NUM_NODES: Es la cantidad de nodos que se crearán en cada una de las zonas del clúster.

Configura nodos en un clúster existente

Para usar la creación de puntos de control de varios niveles con un clúster existente, habilítala junto con el controlador de CSI de Cloud Storage FUSE y Workload Identity Federation for GKE con los siguientes comandos. La versión del clúster existente debe ser posterior a 1.32.3-gke.1170000.

  1. Habilita la federación de identidades para cargas de trabajo para GKE:

    gcloud container clusters update CLUSTER_NAME \
    --workload-pool=PROJECT_ID.svc.id.goog \
    --location=CLUSTER_LOCATION

    Reemplaza los siguientes valores:

    • CLUSTER_NAME: el nombre del clúster
    • PROJECT_ID: Es el ID del proyecto de Google Cloud .
    • CLUSTER_LOCATION: es la región del clúster.

  2. Habilita la creación de puntos de control de varios niveles y el controlador de CSI de Cloud Storage FUSE:

    gcloud container clusters update CLUSTER_NAME \
    --update-addons=HighScaleCheckpointing=ENABLED,GcsFuseCsiDriver=ENABLED \
    --location=CLUSTER_LOCATION

Configura permisos para usar la creación de puntos de control de varios niveles

En esta sección, se explica cómo configurar los permisos para usar los puntos de control de varios niveles.

Otorga acceso a los buckets de Cloud Storage

Los volúmenes efímeros que usa el controlador de CSI de Multi-Tier Checkpointing deben usar buckets de Cloud Storage existentes.

Para almacenar puntos de control en un bucket de Cloud Storage, el sistema de puntos de control de varios niveles necesita acceso al bucket. Otorga el rol de IAM de usuario de objetos de almacenamiento (roles/storage.objectUser) en el bucket a la cuenta de servicio de Kubernetes para la creación de puntos de control de varios niveles.

gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-managed-checkpointing/sa/gke-checkpointing-multitier-node" \
    --role "roles/storage.objectUser"

Reemplaza los siguientes valores:

Otorga acceso a la cuenta de servicio predeterminada de Compute Engine (opcional)

Si tus instancias de Compute Engine necesitan acceso de lectura al bucket de Cloud Storage, otorga el rol de IAM de visualizador de objetos de Storage (roles/storage.objectViewer) a la cuenta de servicio predeterminada de Compute Engine.

gcloud storage buckets add-iam-policy-binding gs://GCS_BUCKET \
    --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
    --role roles/storage.objectViewer

Implementa el controlador de JobSet

El controlador de JobSet es responsable de administrar los trabajos por lotes que ejecutan el entrenamiento de tu modelo en GKE, y su asignación de recursos se ajusta para controlar la carga de trabajo de manera eficiente. Asegúrate de que el selector de trabajos de entrenamiento implemente y use JobSet.

Para aumentar la solicitud de memoria a 1 Gi, el límite de memoria a 2 Gi y la solicitud de CPU a 1 para el contenedor del administrador en tu implementación de JobSet, ejecuta el siguiente comando de parche:

kubectl patch -n jobset-system deploy jobset-controller-manager --type json \
    --patch '[{"op": "add", "path": "/spec/template/spec/containers/0/resources", "value": {"limits": {"memory": "2Gi"}, "requests": {"cpu": "1", "memory": "1Gi"}}}]'

Inicializa el controlador de CSI de Multi-Tier Checkpointing

En esta sección, se describe cómo inicializar el controlador de CSI de puntos de control de varios niveles en los nodos en los que se ejecutarán tus cargas de trabajo. El controlador de CSI es responsable de controlar el almacenamiento y la administración de los puntos de control durante el proceso de entrenamiento de modelos.

Crea un CheckpointConfiguration

Un CheckpointConfiguration es un recurso personalizado de Kubernetes que especifica las propiedades para implementar el controlador de CSI de Multi-Tier Checkpointing. Este recurso tiene alcance de clúster.

  1. Crea el siguiente manifiesto checkpoint.yaml.

    apiVersion: checkpointing.gke.io/v1
kind: CheckpointConfiguration
metadata:
  name: MTC_CONFIG_NAME-configuration
spec:
    cloudStorageBucketName: GCS_BUCKET
    nodeSelector:
        node.kubernetes.io/instance-type: MACHINE_TYPE
    tolerations:
    - key: TOLERATION_KEY
        operator: Exists
        effect: NoSchedule
    inMemoryVolumeSize: IN_MEMORY_VOLUME_SIZE
    gcsFuseMountOptions:
    - implicit-dirs
    - metadata-cache:negative-ttl-secs:0
    - metadata-cache:ttl-secs:-1
    - metadata-cache:stat-cache-max-size-mb:-1
    - metadata-cache:type-cache-max-size-mb:-1
    - file-system:kernel-list-cache-ttl-secs:0
    - read_ahead_kb=1024
    - write:enable-streaming-writes:true

    Reemplaza lo siguiente:

    • MTC_CONFIG_NAME: Es el nombre de tu CheckpointConfiguration. Este nombre es global para el clúster y no es específico del trabajo.
    • GCS_BUCKET: Es el nombre del bucket de Cloud Storage en el que almacenarás los datos de los puntos de control. Usa el bucket que configuraste en el paso Configura un bucket de Cloud Storage con permisos.

    • MACHINE_TYPE: Es el tipo de máquina para los aceleradores correspondientes. El valor puede ser uno de los siguientes:

      • TPU v5p: ct5p-hightpu-4t
      • TPU v5e: ct5e-hightpu-4t
      • TPU v6e: ct6e-standard-4t
      • Ironwood (TPU7x): tpu7x-standard-4t
      • GPU NVIDIA H100 de 80 GB (serie A3):

      Para obtener más información sobre la ejecución de cargas de trabajo distribuidas en GPUs con GKE, consulta Ejecuta GPUs de instancias múltiples. Para las TPU, consulta Crea el grupo de nodos de porción de TPU.

    • TOLERATION_KEY: Este campo permite que el controlador de CSI se programe en nodos con tolerancias coincidentes. Para obtener más información sobre cómo funcionan las taints en diferentes tipos de aceleradores, consulta estas páginas:

    • IN_MEMORY_VOLUME_SIZE: Es el tamaño de la caché de puntos de control en memoria. Especifica la cantidad y la unidad (por ejemplo, 200 Gi).Este valor debe cumplir con los siguientes requisitos:

      • El tamaño del punto de control local para las TPU multiplicado por 2.2
      • El tamaño del punto de control local para las GPUs con un solo par multiplicado por 6.6.

  2. Aplica el manifiesto

    kubectl apply -f checkpoint.yaml

  3. Verifica que el controlador de CSI se esté ejecutando:

    kubectl get pod -n gke-managed-checkpointing

    El resultado debería ser similar al siguiente ejemplo. Habrá varias entradas, una por cada nodo acelerado.

    NAME                                                          READY   STATUS    RESTARTS   AGE
multitier-driver-e2b033a7-a4e7-496a-87a3-ffd7fcc2e57b-2d4fz   5/5     Running   0          114s

Desinstala el controlador de CSI de Multi-Tier Checkpointing

Si quieres anular la implementación del controlador de CSI de Multi-Tier Checkpointing, borra el recurso CheckpointConfiguration. El controlador de Multi-Tier Checkpointing quita el controlador de CSI de los nodos. Esto quita los discos de RAM y libera memoria para otras cargas de trabajo. Por ejemplo:

kubectl delete -f checkpoint.yaml

Administra la retención de datos y la recolección de elementos no utilizados para las copias de seguridad de Cloud Storage

Eres responsable de implementar políticas de retención para las copias de seguridad de los puntos de control de Cloud Storage. La función de Multi-Tier Checkpointing solo escribe copias de seguridad de los puntos de control en Cloud Storage y nunca las modifica ni las borra.

Muchas herramientas de código abierto pueden controlar la retención y la recolección de elementos no utilizados, incluidas las siguientes:

En el siguiente ejemplo, se usa backup-warden, en el que el directorio backup se activa en una ubicación de copia de seguridad que usa Cloud Storage FUSE:

# Add --delete option to actually delete the backups, as is it only shows what would be deleted (dry-run)
backup-warden -p backup \
    --hourly 24 \
    --daily 7 \
    --weekly 5 \
    --monthly always \
    --yearly always \
    --prefer-recent

Actualiza el manifiesto de JobSet de la carga de trabajo

Actualiza el manifiesto de JobSet para que tu trabajo incluya el volumen de puntos de control a gran escala. Los detalles dependen de tu carga de trabajo.

Por ejemplo, para extender el JobSet de ejemplo de Implementa TPU Multislices en GKE, sigue estos pasos:

  1. Agrega las siguientes líneas al contenedor jax-tpu.

    volumeMounts:
- name: checkpoint
  mountPath: CHECKPOINT_DIR

    Reemplaza CHECKPOINT_DIR por la ruta de acceso al directorio de puntos de control. Esta es la ubicación en la que se genera el replicator.yaml y en la que la creación de puntos de control de varios niveles realiza la operación de guardado del punto de control. Para obtener más información, consulta Cómo integrar el registro de puntos de control de varios niveles en tu aplicación.

  2. Agrega las siguientes líneas al campo spec.template.spec de la especificación del trabajo.

    volumes:
- name: checkpoint
  csi:
    driver: multitier-checkpoint.csi.storage.gke.io

Integra la creación de puntos de control de varios niveles en tu aplicación

Para compartir información sobre las ubicaciones de los puntos de control y la preparación de la replicación, modifica tu aplicación para que use el siguiente protocolo para comunicarse con Multi-Tier Checkpointing.

Los siguientes frameworks y bibliotecas ya implementan esta integración:

  1. MaxText (con Orbax): MaxText tiene compatibilidad integrada con el registro de puntos de control de varios niveles (MTC). Para obtener más información, consulta la documentación de MTC de MaxText.
  2. Cualquier modelo que use Orbax: La integración consta de dos componentes principales: el módulo de inicialización de MTC para la configuración inicial (para ver un ejemplo, consulta MaxText) y el administrador de puntos de control de replicador para guardar y restablecer puntos de control desde un disco RAM local (para ver un ejemplo, consulta MaxText).
  3. Ejemplo de referencia de PyTorch: Este ejemplo está disponible para cargas de trabajo que usan NeMo con PyTorch.

Startup

En esta sección, se describen los pasos iniciales que debe seguir la aplicación para interactuar con el sistema de puntos de control de varios niveles.

El replicador es un componente principal de los puntos de control de varios niveles, que se ejecuta en cada nodo como parte del controlador de CSI. El replicador administra la replicación de puntos de control en los niveles de almacenamiento, desde el disco RAM local hasta los nodos de intercambio de tráfico y el almacenamiento externo, como Cloud Storage.

El archivo replicator.yaml actúa como un plano de control dinámico entre tu trabajo de entrenamiento de AA (código del framework) y el componente Replicator. Tu aplicación de AA genera este archivo de forma programática en el volumen local (RAMDisk), al que pueden acceder tanto el trabajo de entrenamiento como el servicio de Replicator. Este manifiesto permite que el framework de AA proporcione instrucciones de configuración del tiempo de ejecución y administración del ciclo de vida al replicador, que son distintas de los parámetros de infraestructura estáticos (por ejemplo, la frecuencia de carga de Cloud Storage) definidos durante la configuración del backend.

Para ver un ejemplo concreto de esta interacción, consulta lo siguiente:

Tu aplicación debe seguir estos pasos durante el inicio:

  1. Espera hasta que el archivo replicator.yaml no esté presente, lo que indica que el replicador está listo para que lo configure tu aplicación. El archivo replicator.yaml se genera en la ubicación CHECKPOINT_DIR que configuraste en la sección Actualiza el manifiesto de JobSet de la carga de trabajo.

    Cuando se crea el trabajo de entrenamiento de modelos por primera vez, el archivo replicator.yaml no existirá y tu aplicación podrá continuar de inmediato. Sin embargo, si el trabajo se reinició (por ejemplo, debido a una falla o una intervención manual), es posible que el sistema aún esté procesando la instancia de trabajo anterior y que el replicator.yaml de esa instancia aún esté presente en el volumen local.

  2. Tu aplicación o trabajo de AA crea el archivo replicator.yaml con la configuración similar a la siguiente.

    Orbax

    job-name: orbax
framework: orbax
assume-data-parallelism: 3
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

    PyTorch

    job-name: nemo
framework: pytorch.distributed
node-rank: 0
nodes: 32
peer-ranks: [1, 16] or peers-per-node: 2
backup-interval-minutes: 30

    Esta configuración de ejemplo tiene los siguientes campos:

    • name: Es el nombre del trabajo de entrenamiento.
    • framework: Es el framework de AA que usa el trabajo de entrenamiento.
    • node-rank: Es el identificador único del nodo actual dentro del trabajo de entrenamiento distribuido. Representa el rango del nodo que crea este archivo. Cada nodo que participe en la ejecución tendrá su propio rango.
    • nodes: Es la cantidad total de nodos que participan en el trabajo de entrenamiento distribuido. Este valor proviene de los metadatos del Pod. El trabajo de entrenamiento de AA también puede ver este valor.
    • peer-ranks o peers-per-node: Dos formas alternativas de especificar la topología de replicación. Solo debe estar presente uno de estos dos parámetros.
      • peer-ranks: Son los rangos explícitos de los nodos de intercambio de tráfico en los que se deben replicar los datos del punto de control del nodo actual. Esto brinda un control detallado sobre qué nodos específicos actúan como socios de replicación.
      • peers-per-node: Es la cantidad de nodos de intercambio de tráfico por nodo que el replicador debe seleccionar automáticamente para la replicación.
    • backup-interval-minutes: Es la frecuencia, en minutos, con la que se crean copias de seguridad de los puntos de control en Cloud Storage. Te recomendamos que establezcas este valor en 30 minutos o más.

  3. Espera hasta que el sistema borre el nuevo archivo replicator.yaml. Esto indica que el replicador se reinició y realizó la limpieza. Este paso te permite evitar archivos temporales o obsoletos en el volumen local cuando tu aplicación realiza los pasos de la siguiente sección.

Restablece el sistema desde el último punto de control correcto conocido (LKG)

  1. Después de que se inicializa el replicador, Multi-Tier Checkpointing crea un vínculo simbólico por trabajador de TPU o GPU. Estos vínculos simbólicos se crean en el mismo volumen local activado que el archivo replicator.yaml, en el que el trabajo guarda los puntos de control.

    Los vínculos simbólicos tienen el formato <job-name>-s{step}-n<node-rank>-w<worker-index>.restore.

  2. Restablece cada trabajador desde el archivo .restore correspondiente. Para ver un ejemplo, consulta el ejemplo del administrador de puntos de control replicados de Orbax en la siguiente sección.

De forma predeterminada, el punto de control LKG es el punto de control completo más reciente que puede encontrar el punto de control de varios niveles. Se prefieren los puntos de control en el clúster (en el disco RAM local y en los nodos de intercambio de tráfico), y las copias de seguridad de Cloud Storage solo se usan cuando no existe un punto de control completo en el clúster. Para anular esta selección, consulta Cómo restablecer desde una copia de seguridad específica.

Restablece desde una copia de seguridad específica

Puedes restablecer un trabajo desde una copia de seguridad específica de Cloud Storage en lugar del punto de control de LKG, por ejemplo, para revertir el entrenamiento a un estado anterior. Antes de que comience el trabajo, sigue estos pasos:

  1. Busca la copia de seguridad desde la que deseas restablecer los datos. La creación de puntos de control de varios niveles escribe copias de seguridad en el bucket que configuraste en CheckpointConfiguration, en un directorio que lleva el nombre del trabajo. Cada copia de seguridad es un subdirectorio con el nombre de la hora en UTC en la que se creó la copia de seguridad, con el formato YYYY-MM-DD_HH-MM:

    gcloud storage ls gs://GCS_PATH/JOB_NAME/

    Reemplaza lo siguiente:

    • GCS_PATH: Es la ruta de acceso de Cloud Storage en la que Multi-Tier Checkpointing escribe copias de seguridad. Este valor es el bucket que especificaste en el campo cloudStorageBucketName de CheckpointConfiguration, incluido cualquier directorio dentro del bucket.
    • JOB_NAME: Es el nombre del trabajo de entrenamiento, como se especifica en el campo job-name del archivo replicator.yaml.

  2. En el directorio del trabajo del bucket, crea un archivo llamado restore.version. El archivo solo debe contener el nombre del directorio de copia de seguridad, por ejemplo:

    echo "BACKUP_NAME" | gcloud storage cp - gs://GCS_PATH/JOB_NAME/restore.version

    Reemplaza BACKUP_NAME por el nombre del directorio de copia de seguridad, por ejemplo, 2025-06-30_14-30.

  3. Inicia el trabajo.

Cuando el archivo restore.version está presente, la creación de puntos de control de varios niveles se comporta de la siguiente manera:

  • Todos los nodos se restablecen a partir de la copia de seguridad especificada. Los puntos de control dentro del clúster se ignoran, incluso si son más recientes que la copia de seguridad.
  • El archivo restore.version se borra automáticamente después de que el trabajo guarda su primer punto de control después del restablecimiento. La anulación se aplica solo una vez: si el trabajo se reinicia más tarde, se restablece desde el punto de control de LKG como de costumbre.
  • Si la copia de seguridad especificada no existe o está incompleta, el trabajo se inicia sin un punto de control. La función de puntos de control de varios niveles no recurre a los puntos de control dentro del clúster ni a otras copias de seguridad.

Guarda el punto de control

Tu aplicación realiza estos pasos varias veces mientras avanza el trabajo de entrenamiento. Las operaciones de guardado se realizan en la ubicación CHECKPOINT_DIR que configuraste en Actualiza el manifiesto de JobSet de la carga de trabajo.

Orbax

Crea puntos de control de Orbax. El directorio se nombra con el número del paso. El replicador detecta el directorio de punto de control recién creado, realiza la replicación o la copia de seguridad según sea necesario y libera espacio automáticamente.

Para obtener más información sobre cómo usar el administrador de puntos de control del replicador de Orbax, consulta el archivo checkpointing de MaxText. Para ver un ejemplo de interacción del servicio de replicador, consulta el archivo max_utils de MaxText.

PyTorch

Usa InClusterLocalCheckpointIO como un pytorch_lightning.CheckpointIO personalizado para habilitar la creación de puntos de control distribuidos correctos con almacenamiento local. En el siguiente comando de ejemplo, se habilita la creación de puntos de control de varios niveles con una implementación de referencia basada en el framework de NVIDIA NeMo:

torchrun train.py <other_train_flags> \
    --local-ckpt-dir=CHECKPOINT_DIR \
    --local-ckpt-interval=20 \
    --job-name=JOB_NAME \
    --enable-high-scale-ckpt

Reemplaza lo siguiente:

  • CHECKPOINT_DIR: Es la ruta de acceso al directorio de puntos de control.
  • JOB_NAME: Es el nombre de la carga de trabajo de tu trabajo de entrenamiento.

Actualizaciones de clústeres

Para las actualizaciones de clústeres, puedes borrar y volver a crear tu objeto CheckpointConfiguration antes o después de la actualización. Esta acción es obligatoria porque el DaemonSet del controlador de puntos de control de nodos, que este objeto implementa de forma dinámica, no se actualizará automáticamente.

Si quieres mantener la misma especificación del DaemonSet, no necesitas hacer nada.

Solucionar problemas

En esta sección, se proporciona orientación para solucionar problemas relacionados con el Multi-Tier Checkpointing. Para solucionar problemas generales de almacenamiento, consulta Soluciona problemas de Cloud Storage en GKE.

No se habilitó la creación de puntos de control de varios niveles

El siguiente error indica que la creación de puntos de control de varios niveles no está habilitada en tu clúster:

error: unable to recognize "checkpoint.yaml": no matches for kind "CheckpointConfiguration" in version "checkpointing.gke.io/v1"

Es posible que se produzca este error después de ejecutar kubectl apply -f checkpoint.yaml en el paso Crea un CheckpointConfiguration.

Para resolver este problema, verifica si habilitaste la creación de puntos de control de varios niveles en tu clúster con el siguiente comando:

gcloud container clusters describe CLUSTER_NAME \
    --project PROJECT_ID
    --location CLUSTER_LOCATION

Si la creación de puntos de control de varios niveles está habilitada, el resultado debería ser similar al siguiente:

addonsConfig:
  gcePersistentDiskCsiDriverConfig:
    enabled: true
  gcsFuseCsiDriverConfig:
    enabled: true
  highScaleCheckpointingConfig:
    enabled: true
  kubernetesDashboard:
    disabled: true
  networkPolicyConfig:
    disabled: true

Si la función de Multi-Tier Checkpointing no está habilitada, actualiza tu clúster para habilitarla.

El controlador de CSI de Multi-Tier Checkpointing no puede activar volúmenes

Es posible que encuentres este problema si el controlador de CSI no puede activar el volumen de Cloud Storage. Es posible que haya varias líneas similares a esta.

kubectl get pod -n gke-managed-checkpointing
NAME                                                          READY   STATUS     RESTARTS   AGE
multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9   0/5     Init:0/1   0          6m32s

Para resolver este problema, verifica los eventos del Pod del controlador de CSI, como se muestra en el siguiente ejemplo:

kubectl describe pod multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 -n gke-managed-checkpointing

Events:
  Type     Reason       Age                 From               Message
  ----     ------       ----                ----               -------
  Normal   Scheduled    17m                 default-scheduler  Successfully assigned gke-managed-checkpointing/multitier-driver-14694e4d-774f-4104-8bba-f0bd82fd7557-5vxr9 to gke-my-cluster-default-pool-353c773f-6d8q
  Warning  FailedMount  82s (x16 over 17m)  kubelet            MountVolume.SetUp failed for volume "gcs" : rpc error: code = PermissionDenied desc = failed to get GCS bucket "checkpointing-test-bucket": googleapi: Error 403: Caller does not have storage.objects.list access to the Google Cloud Storage bucket. Permission 'storage.objects.list' denied on resource (or it may not exist)., forbidden

Si el problema se produce debido al error PermissionDenied del bucket de Cloud Storage, como se muestra en el ejemplo, puedes resolverlo configurando los permisos de forma correcta.

¿Qué sigue?