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 habilitar y usar esta función, consulta los siguientes documentos:

  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 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, 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 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 se incluye 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 se incluye en 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.

CustomResourceDefinitions

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

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 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 punto de control y el Pod de destino.

La compatibilidad se determina según las siguientes reglas:

  • Orden de selección: De forma predeterminada, GKE restablece las cargas de trabajo desde el recurso 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 varía según el alcance de la instantánea configurado en tu PodSnapshotPolicy (whole-pod en comparación con rootfs-only).

Coincidencia de alcance whole-pod (predeterminado)

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

  1. Hash de especificación destilada: GKE genera un hash único basado en los campos esenciales del entorno de ejecución en la especificación del Pod. Para que el restablecimiento se realice correctamente, el Pod de destino debe generar un hash idéntico a partir de su especificación destilada. Esta verificación garantiza que los Pods con punto de control y restablecidos sean idénticos en sus configuraciones de entorno 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 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

  2. 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 punto de control (por ejemplo, N2 a N2 o G2 a G2).

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

Coincidencia de alcance rootfs-only

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 especificación de Pod destilado. Esta coincidencia relajada te permite restablecer una instantánea en un Pod de destino que tiene diferentes recursos, entornos o campos de configuración que el Pod original con punto de control, siempre que la imagen de contenedor subyacente y las versiones de nodo sean compatibles.
  • Como no se restablece la memoria del proceso, puedes restablecer las instantáneas tomadas en una familia de máquinas a una diferente (incluidos los tipos de máquinas E2).

Coincidencia de reglas de agrupación

Si la política usa el campo snapshotGroupingRules para agrupar instantáneas por valores de etiquetas específicos (por ejemplo, por usuario o entorno), el Pod restablecido debe tener las mismas claves y valores de etiquetas. El controlador de instantáneas de Pod solo selecciona una instantánea 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 Pods.

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. Debido a esta demora, cuando midas la velocidad de restablecimiento, asegúrate de capturar cuándo 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 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.

Como 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 de pared: El tiempo de reloj de pared 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, como las variables de entorno se almacenan en la memoria de la aplicación, GKE Sandbox no puede encontrarlas ni 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 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.

Multiusuario e identidad

Las instantáneas de Pods requieren vinculaciones manuales de IAM para que la Kubernetes ServiceAccount (KSA) 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 forma 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 cuando se usa el alcance de instantáneas whole-pod predeterminado. Las instantáneas del sistema de archivos (rootfs-only) 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)
  • El contenedor de 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 tipos de máquinas de TPU.

¿Qué sigue?