10 сентября 2026 года CNCF опубликовала руководство, основанное на трёх воспроизводимых сценариях отказа, предназначенное для проверки аварийного восстановления приложений Kubernetes с сохранением состояния, а не для простого наблюдения за тем, что резервное копирование завершилось со статусом Completed. Эксперименты, которые можно запустить на ноутбуке из репозитория лаборатории, использовали приложение PostgreSQL с известным содержимым из четырёх строк, чтобы можно было проверить фактический результат восстановления, а не полагаться на общие индикаторы состояния.
Материал подготовили Saiyam Pathak и Saloni Narang, оба посла CNCF. Его область применения ограничена восстановлением состояния приложений внутри Kubernetes; в нём не рассматриваются нормативные требования, сравнение продуктов, восстановление базовой инфраструктуры облака или центра обработки данных. Такие инструменты, как Velero и интерфейсы CSI Snapshot, представлены в качестве эталонных реализаций сценариев, тогда как описанные модели отказа применимы к инструментам, выполняющим те же роли.
Завершённое резервное копирование не доказывает возможность восстановления
В первом сценарии компоненты резервной копии Kubernetes были разделены на определения ресурсов в формате YAML и данные постоянных томов. В лаборатории использовался Velero с механизмом передачи данных в совместимое с S3 объектное хранилище за пределами обоих кластеров. Проверка объектов DataUpload показала, что 47,989,888 байт данных тома действительно были переданы во внешнее хранилище.
После удаления пространства имён, включая PVC, восстановление вернуло те же четыре строки примерно за две минуты. Однако CNCF предупреждает, что защита данных тома автоматически не делает копию базы данных согласованной на уровне приложения; приложениям могут потребоваться процедуры flush или quiesce. Кроме того, восстановление в другой инфраструктуре может потребовать согласования StorageClass и других преобразований, которые команда должна спроектировать и протестировать.
Важно и то, что инструменты резервного копирования восстанавливают ресурсы в уже существующий кластер, но не создают узлы, сеть, балансировщики нагрузки или DNS. Поэтому план восстановления должен чётко определять среду, которая примет резервную копию, а восстановление Kubernetes при необходимости следует поручить инфраструктуре как коду или Cluster API.
Git возвращает намерение, но не хранимое состояние
Во втором сценарии производственный кластер был остановлен, тогда как кластер восстановления уже существовал и содержал контроллер GitOps, связанный с репозиторием Git, и инструмент резервного копирования, связанный с общим хранилищем. Синхронизация приложения завершилась успешно, StatefulSet был запущен, а панель мониторинга показывала исправное состояние, однако запрос к базе данных вернул ошибку: relation "attendees" does not exist.
Причина заключалась не в сбое Kubernetes или GitOps. Репозиторий содержал только определения, поэтому контроллер заново создал StatefulSet, Service и новый пустой том. На практике Git хранит заявленное состояние или намерение команды, тогда как резервные копии хранят фактические данные; ни один из них по отдельности не способен полностью восстановить приложение.
Метод восстановления в лаборатории включал удаление пустого приложения, созданного синхронизацией, затем восстановление приложения вместе с его томами из хранилища резервных копий и, наконец, сравнение данных с ожидаемым содержимым. Путь от остановки производства до появления проверенных данных занял четыре минуты в живом эксперименте и немного менее двух минут при повторном тестировании. CNCF отмечает, что эти показатели охватывают только запрограммированную часть и не включают обнаружение инцидента, принятие решения, переключение трафика и возврат в исходную среду.
Отдельные снимки могут создать точку восстановления, которой никогда не существовало
В третьем сценарии тестировалось приложение, использующее два взаимосвязанных тома: один для заказов, другой для платежей. Лабораторная установка записывала совпадающие пары пять раз в секунду, при этом каждый платёж должен был соответствовать заказу. Когда два отдельных снимка были сделаны с интервалом в пять секунд, каждый из них по отдельности выглядел готовым и исправным, однако восстановление показало, что последним зарегистрированным заказом был 108352, тогда как платежей было 108377 — то есть 25 платежей не имели соответствующих заказов.
Результат показывает, что успешное создание каждого отдельного снимка не гарантирует согласованность приложения, использующего несколько томов; вместе эти снимки могли описывать момент времени, которого фактически никогда не существовало. В материале отмечается, что в производственной среде разрыв может увеличиваться, когда инструмент резервного копирования последовательно обрабатывает большое количество PVC.
VolumeGroupSnapshot, получивший статус GA в Kubernetes 1.36, предоставляет механизм для выбора томов одним селектором и запроса согласованной точки восстановления через CSI. В согласованном эксперименте последние номера заказов и платежей совпали на значении 109169, а проверка связи между ними завершилась успешно. Однако поддержка зависит от драйвера: поддержка обычных VolumeSnapshots не доказывает поддержку групповых снимков, и большинство основных облачных драйверов, проверенных для лаборатории, не реализовывали их по состоянию на середину 2026 года. Кроме того, CRD, функцию снимков и соответствующие дополнительные компоненты необходимо явно активировать.
Что должно измерять тестирование восстановления?
- Восстановление полного приложения в чистой целевой среде, в которой оно ранее не запускалось, а не простое удаление Pod и наблюдение за его пересозданием.
- Проверку данных и пути доступа пользователя с использованием ожидаемого содержимого, а не только состояния ресурсов или цветов на панелях мониторинга.
- Измерение всего процесса по времени, с пониманием того, что фактическое время восстановления включает обнаружение, принятие решения, переключение трафика и, возможно, возврат в исходную среду.
- Использование двух независимых областей отказа, например производственного кластера и кластера восстановления, при размещении хранилища резервных копий за пределами обоих.
Редакционный вывод: разрыв между инструментами и последовательностью восстановления
Практическое изменение, которое показывают эти эксперименты, заключается в переносе критерия успеха с «резервная копия завершена» на «правильные данные восстановлены и доступны». Более широкое ограничение состоит в том, что базовый Kubernetes не определяет общего соглашения для координации данных, приложения, кластера, трафика и идентификации, а также не предоставляет стандартного устойчивого ресурса, описывающего полный модуль восстановления приложения и его внешние зависимости. Поэтому границы ответственности между GitOps, резервным копированием, инфраструктурой и пользовательским путём остаются на команде даже при наличии зрелых инструментов для каждого уровня. CNCF отмечает, что инициатива Cloud Native Business Continuity, действующая в рамках CNCF TAG Operational Resilience, стремится объединить вклад в анализ пробелов экосистемы, рекомендации по восстановлению и эталонные архитектуры.