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 la carga de trabajo se reanude en lugar de comenzar desde un estado nuevo.

En este documento, se proporciona una descripción general conceptual de las instantáneas de Pod de GKE. Para obtener información sobre cómo habilitar y usar esta función, consulta Cómo restablecer desde una instantánea de Pod.

Cuándo usar instantáneas de Pod

Usa instantáneas de Pod para cargas de trabajo que tienen tiempos de inicialización largos, por ejemplo, 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 benefician con 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 se crean réplicas nuevas, en lugar de inicializar el Pod desde un estado nuevo, se restablece desde una instantánea y se reanuda la ejecución desde el punto en el que se tomó la instantánea.

Para usar las instantáneas de Pod, debes crear definiciones de recursos personalizados (CRD) de Kubernetes para configurar de forma declarativa 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.

Definiciones de recursos personalizados

Las instantáneas de Pod se configuran de forma declarativa con las siguientes CRD:

  • PodSnapshotStorageConfig: Especifica la ubicación de almacenamiento de las instantáneas. Solo se admiten los 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 contiene la mayoría de las opciones de configuración de la función, incluidas las políticas de retención y la forma en que se activan las instantáneas.
  • PodSnapshotManualTrigger: (opcional) Si no se usa un activador de carga de trabajo, define un activador manual para crear una instantánea de un Pod específico.

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.

Coincidencia de instantáneas

La coincidencia de Pods determina si una instantánea de Pod es compatible con un Pod específico. Esta coincidencia se logra creando un hash único a partir de las especificaciones esenciales de tiempo de ejecución del Pod, también llamado especificación destilada del Pod. Luego, este hash se incorpora en la instantánea del Pod. Para que un Pod posterior se restablezca a partir de esta instantánea del Pod, debe generar un hash idéntico a partir de su propia especificación del Pod destilada. Este proceso ayuda a garantizar que los Pods guardados en el punto de control y los Pods restablecidos sean idénticos en sus configuraciones de tiempo de ejecución.

La destilación simplifica la especificación del Pod, ya que solo conserva los campos de tiempo de ejecución críticos, como image, y quita los campos no esenciales, como nodeName o nodeSelector. Debes asegurarte de que los valores de estos campos esenciales sean coherentes entre el Pod que se usa para crear puntos de control y el Pod que se pretende restablecer.

Los siguientes campos del objeto Pod influyen en el hash único:

  • metadata:
    • annotations: Solo las anotaciones relevantes para el tiempo de ejecución de gVisor, 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

Los siguientes criterios adicionales deben coincidir para que se considere que una instantánea es compatible:

  • Hardware: El Pod nuevo debe ejecutarse en un nodo que tenga la misma serie y arquitectura de máquinas que el Pod original. La serie y la arquitectura de la máquina deben ser las mismas. La cantidad de CPU y la cantidad de memoria pueden cambiar. Los tipos de máquinas E2 no son compatibles debido a su arquitectura subyacente dinámica.
  • Control de versiones: La versión del kernel de gVisor y la versión del controlador de GPU deben coincidir.

GKE administra la compatibilidad de las instantáneas. Si GKE encuentra una instantánea compatible, restablece el Pod nuevo a partir de la instantánea. Si no existe ninguna instantánea compatible, el Pod se inicia normalmente.

Restablece la recuperación y la carga en segundo plano

Cuando se restablece un Pod a partir de una instantánea, primero se restablece el kernel de gVisor, 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 acceder a una parte de la memoria que aún no se cargó, se produce un error de página. gVisor 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 podría tener una pequeña latencia durante los primeros segundos después de un restablecimiento si la aplicación necesita memoria que aún no se transmitió. 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. Por este motivo, cuando midas la velocidad de restauración, asegúrate de registrar el momento en que se inició el servidor del modelo. Puedes verificar cuándo se inicia el servidor del modelo con métricas como el tiempo hasta el primer token (TTFT) o las pruebas de disponibilidad del 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. Esto significa que los datos almacenados en la GPU, por ejemplo, los pesos del modelo, se incluyen en la instantánea. Luego, el Pod se pausa y se toma una instantánea. Durante el restablecimiento, el proceso se invierte.

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áneas y restablecimiento. Debes tener 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 Pod nuevo. Cuando se inicia el Pod, si hay una instantánea correspondiente para él, se restaura desde esa instantánea, lo que incluye la memoria original y el estado del 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 restablecido recibe una dirección IP nueva. Se vuelven a configurar todas las interfaces y rutas de red. Las conexiones de red activas que existían en el momento de la instantánea se cierran cuando se restablece. Los sockets de escucha siguen funcionando.
  • Nombre de host: El Pod restaurado asume una nueva identidad y recibe un nuevo nombre de host.
  • Estado de la aplicación: El estado de la aplicación, que debe ser único para cada Pod, como los IDs de experimentos o las semillas de números aleatorios, se debe volver a inicializar después de una restauración.
  • Secretos: Se deben volver a crear las claves de encriptación y los certificados creados antes de que se tome la instantánea.
  • 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 de forma manual. Las nuevas variables de entorno están disponibles en el archivo /proc/gvisor/spec_environ. El formato del archivo es el mismo que /proc/<pid>/environ.

Estado que cambia después de restablecer la configuración

No se conserva todo el estado durante la restauración. Las siguientes partes del estado del Pod cambian para que el Pod pueda asumir una nueva identidad:

  • Interfaces de red: El Pod restablecido 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 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 restaurado asume una nueva identidad y recibe un nuevo nombre de host.
  • Tiempo: El tiempo avanza hasta la hora actual.

Limitaciones y requisitos

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

  • Los Pods deben ejecutarse en GKE Sandbox porque las instantáneas de Pods dependen del entorno de ejecución de contenedores de gVisor que proporciona GKE Sandbox.
  • Las instantáneas de Pod no admiten tipos de máquinas E2.
  • Los snapshots de Pod funcionan con Pods de una sola GPU. Solo se admiten las siguientes configuraciones de varias GPUs:
    • g2-standard-4 (1 x L4)
    • g2-standard-8 (1 x L4)
    • g2-standard-12 (1 x L4)
    • g2-standard-16 (1 x L4)
    • g2-standard-32 (1 x L4)
    • g2-standard-48 (4 x L4)
    • g2-standard-96 (8 x L4)
    • a2-highgpu-1g (1 GPU A100 de 40 GB)
    • a2-ultragpu-1g (1 x A100-80GB)
    • a3-highgpu-1g (1 x H100-80GB)
  • No se admite el uso parcial de la GPU. Si un nodo tiene varias GPUs, un Pod debe usar todas ellas. Por ejemplo, no puedes usar instantáneas de Pods con cuatro Pods que usen una GPU cada uno en una máquina con cuatro GPU.
  • No se admite el uso del contenedor secundario del controlador de CSI de Cloud Storage FUSE con instantáneas de Pod.

¿Qué sigue?