Аварийное восстановление в Kubernetes: уроки трех сценариев сбоев¶
9.0/10
Контекст¶
Наличие резервных копий и статус «Completed» в Kubernetes не гарантируют реального восстановления stateful-приложений после аварии. Основные сбои происходят на стыках между слоями системы — когда кластер, сетевые пути, декларативные манифесты и данные томов восстанавливаются изолированно друг от друга.
Суть¶
Авторы разобрали три воспроизводимых сценария сбоев на локальном стенде с PostgreSQL. Во-первых, успешный статус бэкапа проверяет лишь завершение операции, поэтому необходимо валидировать перемещение байтов тома в хранилище (например, через Velero `DataUploads`) и использовать хуки заморозки СУБД. Во-вторых, GitOps-контроллер при аварии точно воссоздает объявленное состояние из Git, но провизионирует пустую БД, так как Git хранит намерение, а бэкап — состояние; восстановление требует явного совмещения бэкапа данных и манифестов. В-третьих, раздельное создание снимков нескольких PVC с интервалом в несколько секунд приводит к рассинхронизации данных (в тесте — 25 платежей без заказов). Для решения этой проблемы в Kubernetes 1.36 представлен API `VolumeGroupSnapshot`, создающий согласованный срез группы томов, однако его поддержка облачными CSI-драйверами пока ограничена, а сам срез обеспечивает лишь crash-согласованность на уровне томов.
Вывод¶
Подтверждением катастрофоустойчивости является не зеленый статус в панели бэкапов, а регулярное сквозное тестирование восстановления приложения на чистом кластере с проверкой целостности данных и хронометражем RTO.