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, el Pod se restablece a partir de 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.

Contenido de la instantánea

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

Categoría Se incluye en una instantánea No se incluye en una instantánea
Estado de la aplicación Todo el estado de la aplicación: todos los descriptores de archivos abiertos, los subprocesos, los registros de la 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 se incluye en la columna anterior. En particular, los volúmenes persistentes no se guardan en puntos de control.
Redes Conexiones de bucle invertido, sockets de escucha y sockets de dominio Unix No se restablecen las conexiones externas (se finalizan cuando se restablece la instancia). No se restablecen las reglas agregadas por el usuario, como iptables o nftables, ni las rutas.

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 del 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 de máquinas y arquitectura que el 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 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 preparació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 restablecimiento, 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 detiene y se toma una instantánea. Durante el restablecimiento, el proceso se invierte.

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. 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, 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 cuando se restablece. Los sockets de escucha, las conexiones de bucle invertido y las conexiones de sockets de dominio Unix siguen funcionando.
  • Nombre de host: El Pod restaurado asume una nueva identidad y recibe un nuevo nombre de host.
  • Tiempo real: El tiempo real 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: 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 de archivo es el mismo que el de /proc/<pid>/environ.

Identidad y multiusuario

Las instantáneas de Pod requieren vinculaciones manuales de IAM para que la ServiceAccount (KSA) de Kubernetes de cada Pod acceda a 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 ayudar a abordar las demoras y simplificar la administración de varios inquilinos, en lugar de vincular manualmente IAM a las KSA, puedes usar de forma opcional una cuenta de servicio de nodos 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 objeto PodSnapshotStorageConfig con uno de los siguientes valores:

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

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.
  • La compatibilidad con GPU para las instantáneas de Pod tiene los siguientes requisitos y limitaciones:
    • Los Pods con una sola GPU se admiten en nodos con una sola GPU y con varias GPUs.
    • Los Pods con varias GPU solo son compatibles con las GPU L4 (tipos de máquinas g2-standard-*).
    • No se admite el uso compartido de la GPU con la GPU de instancias múltiples (MIG).
    • En las versiones 1.35.0-gke.1738000 y anteriores de GKE, un Pod que se ejecuta en un nodo con varias GPU debe usar todas las GPU 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 Pod 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-40 GB)
      • 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 Pod.
  • Las instantáneas de Pod no admiten tipos de máquinas de TPU.

¿Qué sigue?