GKE Pod Snapshots llega a GA: hasta un 89% menos de latencia al arrancar

Google ha publicado los resultados de Pod Snapshots en GKE y la cifra que llama la atención es la latencia de arranque: hasta un 89% menos. Un modelo de 70.000 millones de parámetros carga en 37 segundos y uno de 8.000 millones en 15. La función alcanzó disponibilidad general en mayo, en clústeres con la versión 1.35.3-gke.1234000 o superior.

Qué se guarda y qué hace falta

No es una caché. Es checkpoint y restore: el snapshot guarda los descriptores de fichero abiertos, los hilos, los registros de CPU y la memoria, más el rootfs del contenedor, los volúmenes EmptyDir y los montajes tmpfs. La réplica nueva arranca desde ahí sin ejecutar la inicialización que carga el modelo, que es donde se va casi todo el tiempo en modelos grandes.

Esto solo funciona en GKE Sandbox, porque el runtime de gVisor vive ahí. Autopilot ya lo trae; los clústeres Standard necesitan un node pool con gVisor activado. Un agente por nodo gestiona el ciclo de vida, un controlador en el plano de control limpia los snapshots obsoletos y Cloud Storage guarda los datos. Dos recursos personalizados lo configuran: PodSnapshotStorageConfig apunta al bucket, y PodSnapshotPolicy selecciona pods por etiqueta, fija el disparador en workload o manual y define la retención con un lastAccessTimeout y un tope de snapshots por grupo.

El caso que Google enseña es Codeway. Su plataforma Retake tenía una capa propia de caché de artefactos compilados que dejaba el arranque en un minuto. El ingeniero jefe de DevOps Ahmet Furkan Çomak dice que con los snapshots bajó a "solo 8 segundos", y que ahora levantan instancias H100 para un trabajo concreto y las apagan al terminar.

La invalidación es el trabajo pendiente

La reacción de los profesionales se ha centrado menos en la captura que en lo que viene después. Mohana Narasimha G., ingeniero senior de DevOps y MLOps, escribió que "la ruta de restauración es convincente, pero sospecho que la invalidación de snapshots será el problema de plataforma más difícil que la propia captura", y enumeró el digest del modelo, la versión de CUDA y del driver, el tipo y la topología de GPU y la configuración del runtime como partes de la clave de compatibilidad.

Google responde a la mitad de eso. GKE calcula un hash de los campos esenciales del runtime del pod —lo llama spec destilada— y lo incrusta en el snapshot; el pod que restaure tiene que producir un hash idéntico. El nodo destino debe tener la misma serie de máquina y arquitectura de CPU (N2 con N2, G2 con G2), y coincidir la versión del kernel de gVisor y la del driver de GPU. Si no hay snapshot compatible, el pod arranca con normalidad. El ámbito limitado al rootfs relaja las reglas: se salta el hash y, como no restaura memoria de proceso, admite familias distintas, E2 incluida.

La rehidratación queda del lado de la aplicación. Las claves de cifrado y los certificados creados antes del snapshot hay que recrearlos después. Las variables de entorno viven en la memoria del proceso y gVisor no las puede sustituir de forma fiable, así que un workload que dependa de valores nuevos tiene que leerlos de un fichero en /proc/gvisor/spec_environ. Las conexiones externas se cortan al restaurar, los volúmenes persistentes no se capturan y las reglas iptables o nftables y las rutas añadidas por el usuario no vuelven.

El soporte de hardware es más estrecho de lo que sugiere el titular: los snapshots de pod completo no funcionan en tipos E2, los pods multi-GPU solo están soportados en GPU L4 y MIG no entra.

De ahí sale el problema real de operación. Actualizas un node pool y la versión del kernel de gVisor o del driver cambia, los snapshots existentes dejan de coincidir, el pod arranca normal según el fallback documentado y no salta ningún error. El beneficio simplemente desaparece. Y restaurar no es instantáneo: el kernel de gVisor vuelve primero, en unos segundos, la aplicación empieza a correr y su memoria sigue cargándose por detrás.

A esto se suma la gobernanza. Un fichero en Cloud Storage contiene la memoria completa de un workload en ejecución, que en el caso del sandbox de agentes es memoria que ejecutó código no confiable generado por un modelo. El acceso depende de Workload Identity Federation y de enlaces IAM por cuenta de servicio, y Google avisa de que pueden tardar en propagarse.

Encima se apoya Agent Sandbox, también en disponibilidad general desde mayo, con un pool en caliente que asigna hasta 300 sandboxes por segundo y por clúster, el 90% en menos de 200 milisegundos, y que usa estos snapshots para suspender agentes inactivos en vez de mantener cómputo vivo. Agent Substrate, el proyecto abierto presentado a la vez, explora lo mismo a más densidad y su repositorio avisa de que no está listo para producción.

Google lo describe como agnóstico al workload y nombra aplicaciones Java, servidores de juego y monolitos heredados junto a la inferencia. Las decisiones que deja a los equipos son qué node pools llevan gVisor, qué bucket guarda los snapshots y quién puede leerlo, cuánto persisten y qué refresca el workload cuando reanuda desde un estado que no esperaba tener congelado.