Acerca de las instantáneas de Pods de GKE

Las instantáneas de Pods de Google Kubernetes Engine (GKE) ayudan a mejorar la latencia de inicio de la carga de trabajo, ya que restablecen instantáneas de los Pods en ejecución. Una instantánea de Pod guarda todo el estado del Pod, incluidos los cambios en la memoria y el sistema de archivos. Cuando creas réplicas nuevas, se restablecen a partir de la instantánea, lo que permite que se reanude la carga de trabajo en lugar de comenzar desde un estado nuevo. Esta capacidad es útil para escalar horizontalmente las cargas de trabajo, como los modelos de inferencia de IA que cargan pesos grandes en la memoria o las aplicaciones que cargan dependencias extensas.

Usa este documento para comprender cómo funcionan las instantáneas de Pods de GKE y evaluar si tus cargas de trabajo pueden beneficiarse de ellas.

Los administradores y operadores de la plataforma, y los desarrolladores de aplicaciones pueden usar este documento para evaluar la compatibilidad de las cargas de trabajo, planificar políticas de almacenamiento de instantáneas y comprender cómo GKE administra la creación de puntos de control y el restablecimiento. Para obtener más información sobre los roles comunes y las tareas de ejemplo a los que se hace referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes del usuario de GKE.

Para preparar y usar instantáneas de Pods en tus clústeres, consulta las siguientes guías:

  1. Prepárate para las instantáneas de Pods
  2. Cómo activar una instantánea de Pod
  3. Restablece una carga de trabajo a partir de una instantánea de Pod

Cuándo usar instantáneas de Pod

Usa instantáneas de Pods para cargas de trabajo que tienen tiempos de inicialización largos. Entre los ejemplos, se incluyen cargas de trabajo de inferencia de IA que cargan modelos grandes en la memoria de la CPU o la GPU, o aplicaciones grandes que cargan muchas bibliotecas y dependencias. Por lo general, las cargas de trabajo que ya tienen tiempos de inicio rápidos no se beneficiarán de las instantáneas de Pod.

Cómo funcionan las instantáneas de Pod

Las instantáneas de Pods de GKE almacenan una copia exacta del estado del proceso de un Pod en un momento específico. Cuando creas réplicas nuevas, en lugar de inicializar el Pod desde un estado nuevo, GKE lo restablece a partir de una instantánea. Este restablecimiento significa que el Pod reanuda la ejecución desde el punto en el que se tomó la instantánea.

Para configurar instantáneas de Pod de forma declarativa, crea recursos personalizados de Kubernetes para definir el comportamiento de las instantáneas. Un agente que se ejecuta en cada nodo de GKE administra el ciclo de vida de la instantánea. Según las políticas que definas, el agente determinará cuándo crear instantáneas nuevas y cuándo usar las existentes para restablecer Pods nuevos. Un controlador que se ejecuta en el plano de control de GKE limpia las instantáneas obsoletas y resuelve problemas. Cloud Storage almacena las instantáneas de tus Pods.

Contenido de la instantánea

En la siguiente tabla, se indica qué se incluye y qué se excluye en una instantánea de Pod:

Categoría Incluido Excluido
Estado de la aplicación
  • Memoria de proceso
  • Subprocesos de ejecución
  • Registros de la CPU
  • Descriptores de archivos abiertos
 Nada (se captura todo el estado del proceso en la memoria)
Sistemas de archivos
  • Sistema de archivos raíz del contenedor (rootfs)
  • Volúmenes de emptyDir
  • tmpfs soportes
  • Objetos PersistentVolumeClaim
  • Cualquier otro tipo de volumen o almacenamiento que no se incluya en la lista
Redes
  • Conexiones de bucle invertido
  • Sockets de escucha
  • Sockets de dominio Unix
  • Conexiones externas activas (se cierran al restablecer)
  • Rutas personalizadas
  • Reglas definidas por el usuario (iptables, nftables)

Recursos personalizados

Para configurar instantáneas de Pod de forma declarativa, usa los siguientes recursos personalizados:

  • PodSnapshotStorageConfig: Especifica la ubicación de almacenamiento de las instantáneas. Solo admite buckets de Cloud Storage.
  • PodSnapshotPolicy: Define qué Pods se deben incluir en la instantánea según los selectores de etiquetas de Kubernetes. Este recurso personalizado contiene la mayoría de las opciones de configuración de la función, incluido cómo se activan las instantáneas, el alcance de las instantáneas y las políticas de retención.
  • PodSnapshotManualTrigger (opcional): Si no usas un activador de carga de trabajo, define un activador manual para crear una instantánea de un Pod específico.

Para obtener especificaciones de referencia, consulta la referencia de CustomResourceDefinition de PodSnapshot.

Activadores de instantáneas

Puedes activar una instantánea de Pod de las siguientes maneras:

  • Activador de carga de trabajo: La aplicación dentro del Pod le indica al agente de GKE que está lista para una instantánea. Este tipo de activador se ejecuta una vez en un ciclo de carga de trabajo, por ejemplo, en un estado de carga de trabajo lista. Este enfoque es el mejor para mejorar la latencia de inicio de las cargas de trabajo con ajuste de escala horizontal.
  • Activador manual: Puedes activar una instantánea a pedido para un Pod específico creando un recurso personalizado PodSnapshotManualTrigger. Este tipo de activador se puede ejecutar tantas veces como sea necesario. Este enfoque es mejor para situaciones en las que no puedes modificar tu aplicación para indicar que está lista.

Compatibilidad y coincidencia de instantáneas

Para garantizar que una instantánea sea compatible con una carga de trabajo restablecida, GKE realiza una correlación de compatibilidad entre el Pod original con puntos de control y el Pod de destino.

GKE usa las siguientes reglas para determinar la compatibilidad:

  • Orden de selección: De forma predeterminada, GKE restablece las cargas de trabajo desde el recurso personalizado PodSnapshot más reciente que coincide con el espacio de nombres y la configuración del Pod.
  • Criterios de coincidencia: La verificación de compatibilidad depende del alcance de la instantánea configurado en tu recurso personalizado PodSnapshotPolicy (whole-pod o rootfs-only).

Coincidencia de alcance whole-pod (predeterminada)

En el caso de las políticas con el alcance predeterminado whole-pod, GKE verifica lo siguiente:

  • Hash de especificación destilada: GKE genera un hash único basado en los campos de tiempo de ejecución esenciales en la especificación del Pod. Para que la restauración se realice correctamente, el Pod de destino debe generar un hash idéntico a partir de su especificación destilada. Esta verificación confirma que los Pods guardados y restablecidos son idénticos en sus configuraciones de tiempo de ejecución.

    Los siguientes campos del objeto Pod forman parte de la especificación destilada y afectan el hash único:

    • metadata:
      • annotations: Solo las anotaciones pertinentes para GKE Sandbox (como las que comienzan con el prefijo dev.gvisor.*).
      • labels: batch.kubernetes.io/job-completion-index
    • spec:
      • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
      • containers:
        • name
        • image
        • command
        • args
        • workingDir
        • ports: name, containerPort, protocol
        • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
        • volumeDevices: name
        • lifecycle: postStart, preStop
        • terminationMessagePath
        • terminationMessagePolicy
        • securityContext (y todos los subcampos)
        • stdin
        • stdinOnce
        • tty
      • initContainers: Son los mismos subcampos que containers.
      • dnsPolicy
      • automountServiceAccountToken
      • hostNetwork
      • hostPID
      • hostIPC
      • shareProcessNamespace
      • securityContext
      • dnsConfig
      • runtimeClassName
      • os
      • hostUsers

  • Compatibilidad de hardware: El Pod de destino debe ejecutarse en un nodo con una serie de máquinas y una arquitectura de la CPU idénticas a las del Pod original con puntos de control (por ejemplo, N2 a N2 o G2 a G2).

  • Compatibilidad de versiones: La versión del kernel de GKE Sandbox y la versión del controlador de GPU deben coincidir con la versión capturada en la instantánea original.

rootfs-only coincidencia de alcance

Cuando configuras tu política con el alcance rootfs-only (disponible en la versión 1.35.3-gke.1031000 de GKE y versiones posteriores), los requisitos de coincidencia son menos estrictos:

  • GKE no calcula ni compara el hash de la especificación del Pod destilado. Esta coincidencia flexible te permite restablecer una instantánea en un Pod de destino con diferentes recursos, entornos o campos de configuración. Sin embargo, las versiones subyacentes de la imagen de contenedor y del nodo deben ser compatibles.
  • Como no se restablece la memoria del proceso, puedes restablecer instantáneas tomadas en una familia de máquinas a otra diferente (incluidos los tipos de máquinas E2).

Coincidencia de reglas de agrupamiento

Si la política usa el campo snapshotGroupingRules para agrupar instantáneas por valores de etiquetas específicos (como el inquilino o el entorno), el Pod restaurado debe tener claves y valores de etiquetas coincidentes. El controlador de instantáneas de Pod selecciona una instantánea solo del grupo coincidente. Para obtener más información sobre cómo configurar etiquetas de agrupación, consulta Configura políticas adicionales de instantáneas de Pod.

Restablece la disponibilidad y la carga en segundo plano

Cuando se restablece un Pod a partir de una instantánea, primero se restablece el kernel de GKE Sandbox, lo que suele tardar unos segundos. Para minimizar la latencia de inicio, la aplicación se reanuda inmediatamente después de que se restablece el kernel. No espera a que se cargue por completo la memoria de la aplicación. La memoria de la aplicación se restablece con un mecanismo de transmisión en segundo plano.

Si la aplicación intenta leer una parte de la memoria que aún no se cargó, se produce un error de página. GKE Sandbox intercepta esta falla, pausa el subproceso de la aplicación y recupera de inmediato la página de memoria requerida del almacenamiento. Esta recuperación a pedido tiene prioridad sobre la transmisión en segundo plano.

Debido a esta carga en segundo plano, el acceso a la memoria puede experimentar una breve latencia durante los primeros segundos después de una restauración si la aplicación solicita memoria no transmitida. Esta latencia desaparece cuando el estado de la memoria está completamente sincronizado.

Este comportamiento de carga en segundo plano también se aplica al estado de la GPU. Por ejemplo, un Pod de modelo de lenguaje grande (LLM) podría parecer estar en el estado Running y responder a las verificaciones de red, aunque su memoria de GPU aún se esté completando. El modelo no responderá por completo a la inferencia hasta que se restablezca por completo el estado de la GPU. Debido a este retraso, cuando midas la velocidad de restauración, asegúrate de medir el momento en que el servidor del modelo esté listo para entregar solicitudes. Puedes verificar si el servidor del modelo está listo con métricas como el tiempo hasta el primer token (TTFT) o las sondas de preparación de Pod.

Estado de la GPU

Las instantáneas de Pod admiten la captura del estado de las GPUs. Cuando activas una instantánea para un Pod que usa GPUs, la herramienta cuda-checkpoint de NVIDIA guarda el estado de la GPU en la memoria del proceso. Este paso ayuda a garantizar que los datos almacenados en la GPU, como los pesos del modelo, se incluyan en la instantánea. GKE pausa el Pod y toma una instantánea. Durante el restablecimiento, GKE revierte esta operación.

Dado que el estado de la GPU se escribe en la memoria del proceso, el uso de memoria del Pod aumenta durante las operaciones de instantáneas y restablecimiento. Ten en cuenta este requisito de memoria adicional cuando establezcas límites de memoria para tus Pods.

Consideraciones para los Pods restablecidos

Desde la perspectiva de la API de Kubernetes, se crea un nuevo objeto Pod. Cuando se inicia el Pod, si hay una instantánea correspondiente para el Pod, GKE lo restablece desde esa instantánea, incluido el estado original de la memoria y el proceso. Sin embargo, algunos aspectos del estado del Pod deben cambiar para que funcione como una instancia nueva y única.

Ten en cuenta los siguientes cambios de estado después de una restauración:

  • Interfaces de red: El Pod restaurado recibe una dirección IP nueva. Se vuelven a configurar todas las interfaces y rutas. Las conexiones de red activas que existían en el momento de la instantánea se cierran durante la restauración. Los sockets de escucha, las conexiones de bucle invertido y las conexiones de socket de dominio Unix siguen funcionando.
  • Nombre de host: El Pod restaurado asume una nueva identidad y recibe un nuevo nombre de host.
  • Tiempo: El tiempo avanza hasta la hora actual.
  • Estado de la aplicación: El estado de la aplicación debe ser único para cada Pod, como los IDs de experimentos o las semillas de números aleatorios, y debe reinicializarse después de una restauración.
  • Secretos: Las claves de encriptación y los certificados creados antes de tomar la instantánea se deben volver a crear.
  • Variables de entorno: Puedes cambiar las variables de entorno entre una instantánea y una restauración. Sin embargo, debido a que las variables de entorno se almacenan en la memoria de la aplicación, GKE Sandbox no puede encontrarlas y reemplazarlas de manera confiable. Si tu carga de trabajo depende de variables de entorno nuevas después de una restauración, el Pod debe actualizarlas manualmente. Las nuevas variables de entorno están disponibles en el archivo /proc/gvisor/spec_environ. El formato de archivo es el mismo que /proc/<pid>/environ.

Identidad y multiusuario

Las instantáneas de Pod requieren vinculaciones manuales de Identity and Access Management (IAM) para que el objeto ServiceAccount de Kubernetes de cada Pod use Cloud Storage. Las vinculaciones de IAM manuales pueden tardar en propagarse, lo que podría ser un problema si necesitas tomar instantáneas inmediatamente después de crear un Pod.

Para abordar las demoras y simplificar la administración de varios inquilinos, en lugar de vincular manualmente IAM a objetos ServiceAccount, puedes usar una cuenta de servicio del nodo de GKE para crear tokens de corta duración a pedido. Para configurar instantáneas de Pod con este enfoque, usa el campo tokenSource en el recurso personalizado PodSnapshotStorageConfig con uno de los siguientes valores:

  • podKSA (predeterminado): Usa vinculaciones manuales de IAM entre el objeto ServiceAccount del Pod y el bucket de Cloud Storage.
  • federatedP4SA: Usa un token específico de la ruta que genera la cuenta de servicio del nodo.

Requisitos

Para usar las instantáneas de Pods de GKE, asegúrate de cumplir con los siguientes requisitos:

  • Los Pods deben ejecutarse en GKE Sandbox porque las instantáneas de Pod dependen del entorno aislado que proporciona GKE Sandbox.
  • Para usar GPUs con instantáneas de Pod, debes cumplir con los siguientes requisitos:
    • Los Pods con una sola GPU se admiten en nodos con una sola GPU y con varias GPUs.
    • Los Pods con varias GPUs solo se admiten en las GPUs L4 (tipos de máquinas g2-standard-*).
    • En las versiones de GKE 1.35.0-gke.1738000 y anteriores, un Pod que se ejecuta en un nodo con varias GPUs debe usar todas las GPUs disponibles en ese nodo. En las versiones 1.35.0-gke.1738000 y posteriores, los Pods pueden usar un subconjunto de las GPUs en un nodo.
    • Debes usar uno de los siguientes tipos de máquinas compatibles:
      • g2-standard-4 (1 GPU L4)
      • g2-standard-8 (1 GPU L4)
      • g2-standard-12 (1 GPU L4)
      • g2-standard-16 (1 GPU L4)
      • g2-standard-32 (1 GPU L4)
      • g2-standard-48 (4 x L4)
      • g2-standard-96 (8 x L4)
      • a2-highgpu-1g (1 x A100-40 GB)
      • a2-ultragpu-1g (1 x A100-80 GB)
      • a3-highgpu-1g (1 x H100-80GB)

Limitaciones

Las instantáneas de Pod de GKE tienen las siguientes limitaciones:

  • Las instantáneas de Pod no admiten tipos de máquinas E2 cuando se usa el alcance de instantánea whole-pod predeterminado. Las instantáneas del sistema de archivos (rootfs-only) admiten tipos de máquinas E2.
  • No se admite el uso compartido de GPU con la GPU de varias instancias (MIG).
  • El contenedor sidecar del controlador de CSI de Cloud Storage FUSE no es compatible con las instantáneas de Pod.
  • Las instantáneas de Pod no admiten TPUs.

¿Qué sigue?