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 mediante el restablecimiento de 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 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 Pods de GKE. Para obtener información sobre cómo habilitar y usar esta función, consulta Restablece desde una instantánea de Pod.

Cuándo usar instantáneas de Pods

Usa instantáneas de Pods para cargas de trabajo que tengan 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 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 se crean réplicas nuevas, en lugar de inicializar el Pod desde un estado nuevo, el Pod se restablece a partir de una instantánea y se reanuda la ejecución desde el punto en que se tomó la instantánea.

Para usar instantáneas de Pods, crea 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 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 tus instantáneas de Pods.

Contenido de las instantáneas

En la siguiente tabla, se describe lo que se incluye y lo que no en una instantánea de Pod:

Categoría Incluido en una instantánea No incluido en una instantánea
Estado de la aplicación La totalidad del estado de la aplicación: todos los descriptores de archivos abiertos, los subprocesos, los registros de CPU y la memoria.
Sistemas de archivos El sistema de archivos raíz del contenedor (rootfs), los volúmenes EmptyDir y los activadores tmpfs. Todo lo que no esté cubierto por la columna anterior. En particular, los volúmenes persistentes no tienen puntos de control.
Redes Conexiones de bucle invertido, sockets de escucha y sockets de dominio Unix. Las conexiones externas no se restablecen (se finalizan cuando se restablecen). No se restablecen las reglas agregadas por el usuario, como iptables o nftables, ni las rutas.

Definiciones de recursos personalizados

Las instantáneas de Pods 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 tomar como instantáneas según los selectores de etiquetas de Kubernetes. Este recurso contiene la mayoría de las opciones de configuración de la función, incluida la forma en que se activan 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.

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 listo para la carga de trabajo. Este enfoque es mejor para mejorar la latencia de inicio de las cargas de trabajo de escalamiento horizontal.
  • Activador manual: Puedes activar una instantánea a pedido para un Pod específico si creas 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 mediante la creación de un hash único a partir de las especificaciones esenciales del entorno de ejecución del Pod, también llamadas especificaciones de Pod destiladas. Luego, este hash se incorpora en la instantánea de Pod. Para que un Pod posterior se restablezca a partir de esta instantánea de Pod, debe generar un hash idéntico a partir de sus propias especificaciones de Pod destiladas. Este proceso ayuda a garantizar que los Pods con puntos de control y restablecidos sean idénticos en sus configuraciones de entorno de ejecución.

La destilación simplifica la especificación de Pods, ya que solo retiene los campos críticos del entorno de ejecución, 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 el punto de control y el Pod destinado al restablecimiento.

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

  • metadata:
    • annotations: Solo las anotaciones que son relevantes para el entorno de ejecución de gVisor, 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: Los mismos subcampos que containers.
    • dnsPolicy
    • automountServiceAccountToken
    • hostNetwork
    • hostPID
    • hostIPC
    • shareProcessNamespace
    • securityContext
    • dnsConfig
    • runtimeClassName
    • os
    • hostUsers

Se deben cumplir los siguientes criterios adicionales para que se considere una instantánea compatible:

  • Hardware: El Pod nuevo debe ejecutarse en un nodo que tenga una serie de máquinas y una arquitectura idénticas a las del Pod original. La serie de máquinas y la arquitectura 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 con instantáneas. Si GKE encuentra una instantánea compatible, GKE restablece el Pod nuevo a partir de la instantánea. Si no existe una instantánea compatible, el Pod se inicia con normalidad.

Preparación para el restablecimiento y 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 la memoria de la aplicación se cargue por completo. La memoria de la aplicación se restablece mediante 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 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 tener una pequeña cantidad de 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) puede parecer estar en el estado Running y responder a las verificaciones de red, incluso si su memoria de GPU aún se está propagando. 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 restablecimiento, asegúrate de capturar cuándo se inició el servidor de modelos. Puedes verificar cuándo se inicia el servidor de modelos con métricas como el tiempo hasta el primer token (TTFT) o las sondas 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. Esto significa que cualquier dato almacenado en la GPU, por ejemplo, los pesos del modelo, se incluye 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 el Pod, este se restablece a partir de 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.

Considera los siguientes cambios de estado después de un restablecimiento:

  • 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 restablecen. Los sockets de escucha, las conexiones de bucle invertido y las conexiones de sockets de dominio Unix continúan funcionando.
  • Nombre de host: El Pod restablecido asume una identidad nueva y recibe un nombre de host nuevo.
  • Tiempo de reloj: El tiempo de reloj 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 experimento o las semillas de números aleatorios, y debe reinicializarse después de un restablecimiento.
  • 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 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 y reemplazarlas de manera 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 variables de entorno nuevas están disponibles en el archivo /proc/gvisor/spec_environ. El formato del archivo es el mismo que /proc/<pid>/environ.

Multiusuario e identidad

Las instantáneas de Pods requieren vinculaciones manuales de IAM para que la ServiceAccount (KSA) de Kubernetes de cada Pod acceda a Cloud Storage. Las vinculaciones manuales de IAM pueden tardar en propagarse, lo que podría ser un problema si necesitas tomar instantáneas inmediatamente después de crear un Pod.

Para ayudar a abordar las demoras y simplificar la administración de varios usuarios, en lugar de vincular IAM de forma manual a las KSAs, puedes usar de manera opcional 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 objeto PodSnapshotStorageConfig con uno de los siguientes valores:

  • podKSA (predeterminado): Vinculación manual de IAM de la KSA del Pod al bucket de Cloud Storage.
  • federatedP4SA: Usa un token específico de la ruta que genera la cuenta de servicio del nodo.

Limitaciones y requisitos

Las instantáneas de Pods 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 Pods no admiten tipos de máquinas E2.
  • La compatibilidad con GPU para instantáneas de Pods tiene los siguientes requisitos y limitaciones:
    • Los Pods de una sola GPU son compatibles con nodos de una sola GPU y de varias GPUs.
    • Los Pods de varias GPUs solo son compatibles con las GPUs L4 (tipos de máquinas g2-standard-*).
    • No se admite el uso compartido de GPU con la GPU de varias instancias (MIG).
    • En las versiones 1.35.0-gke.1738000 y anteriores de GKE, un Pod que se ejecuta en un nodo de 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.
    • Las instantáneas de Pods admiten los siguientes tipos de máquinas:
      • 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 x A100-40GB)
      • a2-ultragpu-1g (1 x A100-80GB)
      • a3-highgpu-1g (1 x H100-80GB)
  • No se admite el uso del contenedor sidecar del controlador de CSI de Cloud Storage FUSE con instantáneas de Pods.
  • Las instantáneas de Pods no admiten tipos de máquinas de TPU.

¿Qué sigue?