Acerca de las instantáneas de pods de GKE

Las copias de seguridad de pods de Google Kubernetes Engine (GKE) ayudan a mejorar la latencia de inicio de las cargas de trabajo restaurando copias de seguridad de los pods en ejecución. Una captura de un Pod guarda todo el estado del Pod, incluidos los cambios en la memoria y en el sistema de archivos. Cuando creas réplicas, se restauran a partir de la captura, lo que permite que la carga de trabajo se reanude en lugar de empezar desde un nuevo estado.

En este documento se ofrece una descripción general conceptual de las capturas de pods de GKE. Para saber cómo habilitar y usar esta función, consulta Restaurar a partir de una instantánea de Pod.

Cuándo usar las capturas de Pod

Usa las copias de seguridad de pods para cargas de trabajo que tengan tiempos de inicialización largos, como 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. Las cargas de trabajo que ya tienen tiempos de inicio rápidos no suelen beneficiarse de las capturas de pods.

Cómo funcionan las capturas de Pod

Las capturas 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 restaura a partir de una captura y reanuda la ejecución desde el punto en el que se hizo la captura.

Para usar las copias de seguridad de pods, debes crear definiciones de recursos personalizados (CRDs) de Kubernetes para configurar de forma declarativa el comportamiento de las copias de seguridad. Un agente que se ejecuta en cada nodo de GKE gestiona el ciclo de vida de las copias de seguridad. En función de las políticas que definas, el agente determinará cuándo crear nuevas copias y cuándo usar las copias existentes para restaurar nuevos pods. Un controlador que se ejecuta en el plano de control de GKE limpia las copias de seguridad obsoletas y resuelve los problemas. Cloud Storage almacena las copias de seguridad de tus pods.

Definiciones de recursos personalizados

Las instantáneas de pods se configuran de forma declarativa con los siguientes CRDs:

  • PodSnapshotStorageConfig: especifica la ubicación de almacenamiento de las capturas. Solo se admiten cubos de Cloud Storage.
  • PodSnapshotPolicy: define qué pods se deben crear en función de los selectores de etiquetas de Kubernetes. Este recurso contiene la mayoría de las opciones de configuración de la función, incluido cómo se activan las copias y las políticas de conservación.
  • 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 capturas

Puedes activar una instantánea de Pod de las siguientes formas:

  • Activador de carga de trabajo: la aplicación del pod 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, cuando la carga de trabajo está lista. Este enfoque es el más adecuado para mejorar la latencia de inicio de las cargas de trabajo de escalado horizontal.
  • Activador manual: puedes activar una captura bajo demanda de un Pod específico creando un recurso personalizado PodSnapshotManualTrigger. Este tipo de activador se puede ejecutar tantas veces como sea necesario. Este enfoque es el más adecuado en situaciones en las que no puedes modificar tu aplicación para indicar que está lista.

Coincidencia de capturas

La coincidencia de pods determina si una instantánea de un pod es compatible con un pod específico. Esta coincidencia se consigue creando un hash único a partir de las especificaciones esenciales del tiempo de ejecución del pod, también llamadas especificaciones destiladas del pod. Este hash se inserta en la instantánea del pod. Para que un Pod posterior se restaure a partir de esta instantánea de Pod, debe generar un hash idéntico a partir de su propia especificación de Pod destilada. Este proceso ayuda a asegurar que los Pods con puntos de control y los restaurados sean idénticos en sus configuraciones de tiempo de ejecución.

La destilación simplifica la especificación del pod conservando solo los campos de tiempo de ejecución críticos, como image, y eliminando los campos no esenciales, como nodeName o nodeSelector. Debe asegurarse de que los valores de estos campos esenciales sean coherentes entre el pod usado para la creación de puntos de control y el pod que se va a restaurar.

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

  • metadata:
    • annotations: solo las anotaciones que sean relevantes para el tiempo de ejecución de gVisor, como las que empiecen por 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 y 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

Para que se considere que una captura es compatible, deben coincidir los siguientes criterios adicionales:

  • Hardware: el nuevo pod debe ejecutarse en un nodo que tenga la misma serie y arquitectura de máquina que el pod original. La serie y la arquitectura de la máquina deben ser las mismas. El número de CPUs y la cantidad de memoria pueden cambiar. No se admiten los tipos de máquina E2 debido a su arquitectura subyacente dinámica.
  • Control de versiones: la versión del kernel de gVisor y la versión del controlador de la GPU deben coincidir.

GKE gestiona la compatibilidad de las instantáneas. Si GKE encuentra una captura compatible, restaura el nuevo pod a partir de la captura. Si no hay ninguna instantánea compatible, el Pod se iniciará con normalidad.

Restaurar la recuperación y la carga en segundo plano

Cuando se restaura un pod a partir de una instantánea, primero se restaura 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 restaure el kernel. No espera a que se cargue por completo la memoria de la aplicación. La memoria de la aplicación se restaura mediante un mecanismo de streaming en segundo plano.

Si la aplicación intenta acceder a una parte de la memoria que aún no se ha cargado, se produce un error de página. gVisor intercepta este error, pausa el hilo de la aplicación y obtiene inmediatamente la página de memoria necesaria del almacenamiento. Esta obtención bajo demanda tiene prioridad sobre el flujo en segundo plano.

Debido a esta carga en segundo plano, el acceso a la memoria puede tener una pequeña latencia durante los primeros segundos después de una restauración si la aplicación necesita memoria que aún no se ha transmitido. 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 el estado Running y responder a las comprobaciones de red aunque su memoria de GPU aún se esté rellenando. El modelo no responderá completamente a las inferencias hasta que el estado de la GPU se haya restaurado por completo. Por este motivo, al medir la velocidad de restauración, asegúrate de registrar cuándo ha empezado el servidor del modelo. Puedes comprobar cuándo se inicia el servidor del modelo mediante métricas como el tiempo hasta el primer token (TTFT) o las pruebas de disponibilidad de pods.

Estado de la GPU

Las capturas de pods admiten el registro del estado de las GPUs. Cuando activas una instantánea de 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, como los pesos del modelo, se incluye en la instantánea. El Pod se pone en pausa y se hace una captura. Durante la restauración, 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 creación y restauración de la instantánea. Debes tener en cuenta este requisito de memoria adicional al definir los límites de memoria de tus pods.

Consideraciones sobre los pods restaurados

Desde la perspectiva de la API de Kubernetes, se crea un nuevo pod. Cuando se inicia el pod, si hay una instantánea correspondiente, el pod se restaura a partir de esa instantánea, incluida 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 restaurado recibe una nueva dirección IP. Se vuelven a configurar todas las interfaces de red y las rutas. Las conexiones de red activas que existían en el momento de la instantánea se cierran al restaurar. 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 experimento o las semillas de números aleatorios, debe reinicializarse después de una restauración.
  • Secretos: las claves de cifrado y los certificados creados antes de que se haga la instantánea deben volver a crearse.
  • Variables de entorno: puedes cambiar las variables de entorno entre una instantánea y una restauración. Sin embargo, como las variables de entorno se almacenan en la memoria de la aplicación, GKE Sandbox no puede encontrarlas ni sustituirlas de forma fiable. Si tu carga de trabajo depende de nuevas variables de entorno después de una restauración, el pod debe actualizarlas manualmente. Las nuevas variables de entorno están disponibles en el archivo /proc/gvisor/spec_environ. El formato del archivo es el mismo que el de /proc/<pid>/environ.

Estado que cambia después de la restauración

No se conserva todo el estado al restaurar. Las siguientes partes del estado del pod cambian para que el pod pueda asumir una nueva identidad:

  • Interfaces de red: el pod restaurado recibe una nueva dirección IP. 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 al restaurar. 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 se adelanta hasta la hora actual.

Limitaciones y requisitos

Las vistas generales de pods de GKE tienen las siguientes limitaciones:

  • Los pods deben ejecutarse en GKE Sandbox porque las instantáneas de pods dependen del tiempo de ejecución de contenedores gVisor que proporciona GKE Sandbox.
  • Las copias de un pod no admiten tipos de máquinas E2.
  • Las capturas de pods 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 x A100-40 GB)
    • a2-ultragpu-1g (1 x A100-80 GB)
    • a3-highgpu-1g (1 x H100-80 GB)
  • 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 las instantáneas de pods con cuatro pods que usen una GPU cada uno en una máquina con cuatro GPUs.
  • No se admite el uso del contenedor sidecar del controlador de CSI de Cloud Storage FUSE con las instantáneas de pods.

Siguientes pasos