Kubernetes 1.36 сделал общедоступным VolumeGroupSnapshot Kubernetes — механизм согласованных снапшотов сразу для нескольких PersistentVolumeClaim. Для команд, которые держат PostgreSQL, шардированные хранилища или stateful-сервисы в кластере, это закрывает неприятную дыру: бэкап мог быть формально успешным, но непригодным для восстановления.
Проблему на примере PostgreSQL описывает The New Stack: данные лежат на одном PVC, write-ahead log — на другом, все отдельные снапшоты созданы без ошибок, но при restore база не стартует, потому что журнал ссылается на страницы, которых нет в снимке data volume. Это не поломка инструмента бэкапа и не магия ночного дежурства. Это рассинхрон между томами, снятыми в разные моменты времени.
До Kubernetes 1.36 стандартная модель снапшотов в CSI была привязана к одному тому: один VolumeSnapshot на один PVC. Для простого сервиса с одним диском этого достаточно. Для базы данных с отдельными томами под данные и журналы, для приложений с несколькими дисками или для шардированных систем — уже нет. Инструмент резервного копирования обычно проходил по PVC по очереди: сначала том A, потом B, потом C. Каждый отдельный снимок мог быть crash-consistent, но вместе они описывали состояние, которого приложение никогда не видело.
В классических СХД эта задача давно решалась через consistency group: администратор объединял LUN в группу, а массив снимал их как одну точку во времени. При переезде в Kubernetes часть команд незаметно потеряла эту гарантию. Оркестратор дал переносимость, декларативность и удобную работу с PersistentVolume, но сам по себе не умел сказать: эти несколько PVC относятся к одному приложению, снимайте их вместе.
VolumeGroupSnapshot Kubernetes возвращает эту идею в виде API, а не в виде проприетарной функции конкретного массива. В Kubernetes 1.36 три объекта перешли в версию groupsnapshot.storage.k8s.io/v1: VolumeGroupSnapshot, VolumeGroupSnapshotContent и VolumeGroupSnapshotClass. Администратор задает класс снапшота для CSI-драйвера, пользователь или автоматизация создает VolumeGroupSnapshot, а нужные PVC выбираются через label selector. То есть группа собирается тем же способом, которым Kubernetes обычно связывает ресурсы: метками, а не ручным списком дисков в чужой консоли.
Важная деталь: речь идет о crash-consistent снимке группы томов, а не о волшебной гарантии уровня SQL-транзакций. Если приложению нужна application-consistency, его все равно придется готовить к снапшоту: flush, hooks, checkpoint или логика конкретного оператора. Но для большого класса сценариев VolumeGroupSnapshot убирает самую грубую ошибку — ситуацию, когда несколько томов сняты по отдельности и между ними успели пройти записи. Для загруженной базы даже сотни миллисекунд могут быть достаточны, чтобы WAL и data files разъехались.
История функции тянулась несколько релизов. Volume group snapshots появились как alpha в Kubernetes 1.27, перешли в beta в 1.32, получили вторую beta-итерацию в 1.34 и дошли до GA в 1.36. За работу отвечает SIG Storage в рамках KEP #3476. Для storage-вендоров это не галочка в маркетинговой презентации, а конкретная обязанность: CSI-драйвер должен поддержать group controller service и операции CreateVolumeGroupSnapshot, DeleteVolumeGroupSnapshot и GetVolumeGroupSnapshot. Без поддержки со стороны драйвера новый API останется красивой декларацией в YAML.
Для разработчиков и платформенных команд практический вывод довольно приземленный. Если вы запускаете stateful-нагрузки в Kubernetes, пора проверить не только наличие бэкапов, но и то, на какой модели согласованности они построены. Особенно это касается PostgreSQL-кластеров, систем с отдельными WAL/log/data volume, распределенных БД и приложений, где состояние разложено по нескольким PVC. Старый тест «снапшот создался без ошибки» больше не выглядит достаточным; нормальный тест — восстановить группу и убедиться, что сервис поднимается.
Для бизнеса новость звучит менее эффектно, чем очередной AI-агент, зато бьет прямо в стоимость простоя. Kubernetes давно используют не только для stateless-сервисов, и чем больше баз данных переезжает в кластеры, тем важнее становятся скучные гарантии хранения. VolumeGroupSnapshot не отменяет архитектурные споры о том, где должны жить базы, но делает Kubernetes менее опасным местом для тех, кто уже принял это решение. Следующий вопрос для рынка простой: как быстро CSI-драйверы, backup-операторы и managed Kubernetes-платформы доведут поддержку групповых снапшотов до состояния «включил и спокойно восстановился в 2 ночи».