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 las cargas de trabajo restableciendo instantáneas de 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 de forma horizontal 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 plataformas, y los desarrolladores de aplicaciones pueden usar este documento para evaluar la compatibilidad de las cargas de trabajo, planificar las políticas de almacenamiento de instantáneas y comprender cómo GKE administra los puntos de control y el restablecimiento. Para obtener más información sobre los roles comunes y las tareas de ejemplo a las que se hace referencia en el contenido deGoogle Cloud , consulta Roles y tareas comunes del usuario de GKE.

Para prepararte 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. Activa 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 Pods

Usa instantáneas de Pods para cargas de trabajo que tienen tiempos de inicialización largos. Algunos ejemplos son las cargas de trabajo de inferencia de IA que cargan modelos grandes en la memoria de la CPU o la GPU, o las 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 Pods.

Cómo funcionan las instantáneas de Pods

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 Pods 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 las instantáneas. Según las políticas que definas, el agente determina 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 los problemas. Cloud Storage almacena las instantáneas de tus Pods.

Contenido de la instantánea

En la siguiente tabla, se indica lo que incluye y excluye 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
  • Abre los descriptores de archivos.
 Nada (se captura todo el estado del proceso en la memoria)
Sistemas de archivos
  • Sistema de archivos raíz del contenedor (rootfs)
  • emptyDir de volúmenes
  • tmpfs de montajes
  • Objetos PersistentVolumeClaim
  • Cualquier otro tipo de volumen o almacenamiento que no se indique como incluido
Redes
  • Conexiones de bucle invertido
  • Sockets de escucha
  • Sockets de dominio Unix
  • Conexiones externas activas (cerradas durante el restablecimiento)
  • Rutas personalizadas
  • Reglas definidas por el usuario (iptables, nftables)

Recursos personalizados

Para configurar las instantáneas de Pods 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 de qué Pods se deben crear instantáneas 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, incluidas la forma en que 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 escalamiento 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.

Coincidencia y compatibilidad de instantáneas

Para garantizar que una instantánea sea compatible con una carga de trabajo restablecida, GKE realiza una coincidencia de compatibilidad entre el Pod original con un punto 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 coincida con el espacio de nombres y la configuración del Pod.
  • Criterios de coincidencia: La verificación de compatibilidad depende de la ubicación de la instantánea configurada en tu recurso personalizado PodSnapshotPolicy (whole-pod o rootfs-only).

Coincidencia de alcance de whole-pod (predeterminada)

Para las políticas con el permiso predeterminado whole-pod, GKE verifica lo siguiente:

  • Hash de especificación resumido: GKE genera un hash único basado en los campos esenciales del entorno de ejecución en la especificación del Pod. Para que un restablecimiento se realice correctamente, el Pod de destino debe generar un hash idéntico a partir de su especificación destilada. Esta verificación comprueba que los Pods con puntos de control y restablecidos sean idénticos en sus parámetros de configuración del entorno de ejecución.

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

    • metadata:
      • annotations: Solo las anotaciones que son relevantes para GKE Sandbox (como las anotaciones 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 la misma serie de máquinas, el mismo proveedor de CPU y el mismo conjunto de atributos de CPU (marcas CPUID) que el Pod con el punto de control. Por ejemplo, ambos nodos deben usar la misma serie N2 o G2 y las mismas funciones de procesador Intel o AMD. GKE Sandbox verifica las funciones de la CPU antes de restablecer la memoria del proceso y el estado de la CPU, por lo que una instantánea con el permiso whole-pod no se puede restablecer en un nodo con funciones de CPU diferentes.

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

Coincidencia de permisos de rootfs-only

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

  • GKE no calcula ni compara el hash de la especificación del Pod destilado. Esta coincidencia relajada te permite restablecer una instantánea en un Pod de destino con diferentes recursos, entornos o campos de configuración. Sin embargo, la imagen de contenedor y las versiones de nodo subyacentes deben ser compatibles.
  • Debido a que no se restablece la memoria del proceso, puedes restablecer las instantáneas tomadas en una familia de máquinas a una familia de máquinas 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 etiqueta específicos (como el de usuario o el de entorno), el Pod restablecido debe tener claves y valores de etiqueta que coincidan. 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 las etiquetas de agrupación, consulta Establece parámetros de configuración adicionales de la política de instantáneas de Pods.

Recuperación y 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 la memoria de la aplicación se cargue por completo. 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 este error, 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 un restablecimiento si la aplicación solicita memoria no transmitida. Esta latencia desaparece cuando el estado de la memoria se sincroniza por completo.

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) puede parecer que está en 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 para la inferencia hasta que el estado de la GPU se restablezca por completo. Debido a esta demora, cuando midas la velocidad de restablecimiento, asegúrate de medir cuando el servidor de modelos esté listo para entregar solicitudes. Puedes verificar la preparación del servidor de modelos con métricas como el tiempo hasta el primer token (TTFT) o los sondeos de preparación de Pods.

Estado de la GPU

Las instantáneas de Pods 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.

Debido a 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ánea 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 objeto Pod nuevo. Cuando se inicia el Pod, si hay una instantánea correspondiente para el Pod, GKE lo restablece a partir de esa instantánea, incluidos la memoria y el estado del proceso originales. 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 restablecido recibe una dirección IP nueva. Todas las interfaces y rutas se vuelven a configurar. Las conexiones de red activas que existían en el momento de la instantánea se cierran cuando se restablece. Los sockets de escucha, las conexiones de bucle invertido y las conexiones de socket de dominio Unix siguen funcionando.
  • Nombre de host: El Pod restablecido asume una identidad nueva y recibe un nombre de host nuevo.
  • Tiempo real transcurrido: El tiempo real transcurrido 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 se debe reinicializar después de un restablecimiento.
  • Secrets: 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 un restablecimiento. Sin embargo, debido a que las variables de entorno se almacenan en la memoria de la aplicación, GKE Sandbox no puede encontrarlas ni reemplazarlas de forma confiable. Si tu carga de trabajo depende de variables de entorno nuevas después de un restablecimiento, el Pod debe actualizarlas de forma manual. Las nuevas variables de entorno están disponibles en el archivo /proc/gvisor/spec_environ. El formato de archivo es el mismo que el de /proc/<pid>/environ.

Multiusuario e identidad

Las instantáneas de Pods 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 los retrasos y simplificar la administración de múltiples usuarios, en lugar de vincular de forma manual IAM a los objetos ServiceAccount, puedes usar una cuenta de servicio de nodo de GKE para crear tokens de corta duración a pedido. Para configurar instantáneas de Pods con este enfoque, usa el campo tokenSource en el recurso personalizado PodSnapshotStorageConfig con uno de los siguientes valores:

  • podKSA (predeterminado): Usa vinculaciones de IAM manuales entre el objeto ServiceAccount del Pod y el bucket de Cloud Storage.
  • federatedP4SA: Usa un token específico de la ruta de acceso 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 Pods dependen del entorno aislado que proporciona GKE Sandbox.
  • Para el alcance de la instantánea whole-pod predeterminado, el nodo en el que se restablece el Pod debe tener la misma serie de máquinas, el mismo proveedor de CPU y las mismas funciones de CPU que el nodo en el que se tomó la instantánea. Las cargas de trabajo solo de CPU pueden usar cualquier serie de máquinas que no sea E2 compatible con GKE Sandbox y que cumpla con estos requisitos de compatibilidad de hardware. Para obtener más información, consulta Limitaciones.
  • Para usar GPUs con instantáneas de Pods, también debes cumplir con los siguientes requisitos:
    • Los Pods de GPU única se admiten en nodos de GPU única y de varias GPU.
    • Los Pods con varias GPU solo se admiten en GPU L4 (tipos de máquinas g2-standard-*).
    • En las versiones 1.35.0-gke.1738000 y anteriores de GKE, 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 GPU de un nodo.
    • Para las cargas de trabajo de GPU, debes usar uno de los siguientes tipos de máquinas de GPU compatibles:
      • g2-standard-4 (1 L4)
      • g2-standard-8 (1 L4)
      • g2-standard-12 (1 L4)
      • g2-standard-16 (1 L4)
      • g2-standard-32 (1 L4)
      • g2-standard-48 (4 L4)
      • g2-standard-96 (8 L4)
      • a2-highgpu-1g (1 A100 de 40 GB)
      • a2-ultragpu-1g (1 A100 de 80 GB)
      • a3-highgpu-1g (1 H100 de 80 GB)

Limitaciones

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

  • Cuando usas el alcance de instantánea predeterminado whole-pod, una instantánea no se puede restablecer en una VM de Compute Engine con características de CPU diferentes (marcas CPUID) que la VM en la que se tomó la instantánea:
    • Las instantáneas de Pods con el permiso whole-pod no admiten la serie de máquinas E2 ni otras series de máquinas que mezclen de forma dinámica procesadores Intel y AMD o generaciones de CPU. Las instantáneas del sistema de archivos (alcance rootfs-only) admiten la serie de máquinas E2.
    • Incluso dentro de la misma serie de máquinas que no son E2 y el mismo proveedor de CPU, Compute Engine puede aprovisionar VMs con diferentes plataformas de CPU o conjuntos de atributos de CPU por VM. Si se programa un Pod en un nodo con características de CPU que no coinciden, se produce un error cuando se restablece una instantánea con el permiso whole-pod.
  • No se admite el uso compartido de GPU con GPU de instancias múltiples (MIG).
  • El contenedor sidecar del controlador de CSI de Cloud Storage FUSE no es compatible con las instantáneas de Pods.
  • Las instantáneas de Pods no admiten TPU.

¿Qué sigue?