10 октября 2026Команда Сарнас

Снапшоты подов в GKE: что сохраняется, как восстанавливается и где ломается

GKE открыл общий доступ к снапшотам подов — механизму, который сохраняет рабочее состояние пода вместе с памятью CPU и GPU и восстанавливает его без полного холодного старта. Разбираем, что именно попадает в снимок, как GKE подбирает подходящий вариант при перезапуске, какие ограничения по совместимости узлов и версий драйверов нужно учитывать и в каких случаях восстановление не сработает.

Google перевёл GKE Pod snapshots в общий доступ: функция сохраняет рабочее состояние пода вместе с памятью CPU и GPU и восстанавливает его по требованию. По данным InfoQ, общий доступ (general availability) открыт в мае на кластерах версии 1.35.3-gke.1234000 или более поздней. Снимок снимается вручную, а восстановление запускается удалением и повторным развёртыванием пода — GKE сам подбирает подходящий снимок.

Ниже — что именно фиксируется в снимке, как устроен откат, какие цифры ускорения заявляет Google и где механизм перестаёт работать.

Что именно изменилось

Снимок пода сохраняет состояние запущенной рабочей нагрузки, включая память CPU и GPU, и восстанавливает его по требованию. При создании снимка появляется пользовательский ресурс PodSnapshot. Посмотреть все снимки в пространстве имён можно командой kubectl get podsnapshots.podsnapshot.gke.io --namespace NAMESPACE. В выводе есть колонка POLICY — например, example-policy, — то есть снимок связан с политикой.

Настройка идёт через два ресурса. PodSnapshotStorageConfig задаёт место хранения. PodSnapshotPolicy выбирает поды по метке, задаёт триггер и настраивает хранение: как долго хранится снимок после последнего обращения и сколько снимков допускается в группе.

Восстановление запускается удалением существующего пода после снятия снимка и повторным развёртыванием — либо развёртыванием нового пода с идентичной спецификацией. GKE автоматически восстанавливает под из подходящего снимка.

Как устроено восстановление

Обычный старт контейнера включает полный процесс загрузки данных, и на это уходит время. Снимок позволяет обойти эту фазу: инициализация выполняется один раз, GKE фиксирует полностью загруженное состояние вместе с памятью CPU и GPU и сохраняет его в Cloud Storage с высокой пропускной способностью, а новые реплики восстанавливаются прямо из него.

Восстановление не мгновенное. Сначала возвращается ядро gVisor, обычно за несколько секунд, и приложение начинает работу, пока его память ещё догружается в фоне. То есть готовность приложения наступает раньше, чем память загружена целиком.

Доступ к снимку опирается на Workload Identity Federation и IAM-привязки для service account каждого пода — по замечанию Google, они могут требовать времени на распространение. Это ещё одна причина, по которой восстановление не мгновенно.

Как подбирается снимок

GKE строит хеш из существенных runtime-полей пода — так называемой distilled Pod spec — и встраивает его в снимок. Восстанавливаемый под должен дать идентичный хеш. Целевой узел обязан совпадать по machine series и архитектуре CPU (N2 к N2, G2 к G2), а версии ядра gVisor и GPU-драйвера — совпадать с зафиксированными. Если совместимого снимка нет, под запускается обычным образом.

Совместимость определяется и другими правилами: порядком выбора и критериями соответствия. Чтобы GKE использовал конкретный снимок, ресурс PodSnapshot должен иметь статус-условие Ready и находиться в том же пространстве имён, что и под; иначе рабочая нагрузка выполняет холодный старт.

Предыстория: чем заменяли холодный старт

Каждая новая реплика независимо скачивает веса модели и загружает их в память ускорителя, а для моделей с десятками миллиардов параметров этот шаг часто составляет большую часть времени запуска. Инженеры прибегали к избыточному резервированию дорогой инфраструктуры или строили кастомные системы восстановления состояния на уровне приложения.

Пример — Codeway с платформой Retake. У них был собственный слой кэширования скомпилированных артефактов, сокращавший запуск до одной минуты, но он добавлял значительные накладные расходы на сопровождение и всё ещё ограничивал агрессивное автомасштабирование. Замена этой сложности на GKE Pod snapshots снизила задержку запуска до 8 секунд на GPU A3 H100. Теперь H100 поднимаются под конкретную задачу дообучения или инференса и сразу выключаются после завершения, что снижает расходы на простаивающие GPU и упрощает кодовую базу.

Почему это сделали

Проблема в линейном штрафе при масштабировании: каждая новая реплика независимо тянет веса и грузит их в память ускорителя. Задержка запуска ухудшает пользовательский опыт и мешает быстрому автомасштабированию при всплесках трафика.

Для агентных воркфлоу картина другая: изоляция недоверенного кода и команд от LLM означает одну песочницу на пользователя или отдельный воркфлоу, и здесь и задержка запуска, и простаивающие песочницы ведут к значительному избыточному выделению и недоиспользованию ресурсов.

Google обосновывает решение уровнем lifecycle-менеджмента: политика через Pod snapshot CRDs определяет, какие поды снимать и где хранить данные, и обрабатывает жизненный цикл хранения и управления. Снимки можно снимать на любом этапе — при старте рабочей нагрузки по сигналу или во время жизненного цикла пода по on-demand триггеру.

Цифры

Google сообщает о снижении задержки запуска вплоть до 89% для больших моделей вроде llama3-70b. Модель на 70B параметров загружается за 37 секунд, модель на 8B — за 15 секунд. InfoQ приводит те же цифры. Отдельно упоминается ускорение в 45 раз для GKE Agent Sandbox в контексте agentic RL и evaluation research.

Для генеративного ИИ это означает, что инициализацию — загрузку весов модели в память ускорителя — выполняют один раз для создания начального снимка, а новые реплики восстанавливаются прямо из этого состояния, минуя фазу инициализации.

Ограничения

Восстановление не мгновенное: ядро gVisor возвращается первым, обычно в течение нескольких секунд, приложение начинает работу, а память ещё грузится в фоне.

Аппаратная поддержка уже, чем кажется: снапшоты целых подов не работают на типах машин E2, поды с несколькими GPU поддерживаются только на GPU L4, а совместное использование GPU через Multi-Instance GPU не поддерживается.

Что остаётся за приложением и требует ручного вмешательства

Управление жизненным циклом снимков частично автоматизировано: агент на каждой ноде обрабатывает жизненный цикл снимка, а контроллер на плоскости управления удаляет устаревшие. Но часть работы остаётся на разработчике.

Рехидратация — за приложением. Ключи шифрования и сертификаты, созданные до снимка, должны быть пересозданы после, поскольку восстановленный процесс возобновляется с тем, что держал в момент заморозки. Переменные окружения живут в памяти приложения, где gVisor не может надёжно их найти и заменить, поэтому рабочей нагрузке, зависящей от новых значений, приходится считывать их заново после восстановления. Внешние соединения разрываются при восстановлении, постоянные тома не чекпоинтятся, а пользовательские правила iptables или nftables и маршруты не восстанавливаются.

Инвалидация при обновлении окружения остаётся нерешённой. При обновлении пула нод версия ядра gVisor или драйвера GPU может измениться, существующие снимки перестают совпадать, под запускается обычным путём — и выгода просто исчезает, без ошибок.

Удаление политики требует ручного шага:

kubectl delete podsnapshotpolicies.podsnapshot.gke.io SNAPSHOT_POLICY --namespace=NAMESPACE

Работающие поды при удалении политики не затрагиваются, но если удалить её, пока под сохраняется или восстанавливается, он может перейти в состояние отказа.