Как защитить данные в Kubernetes: опыт Киберпротекта и Фланта
При переходе на контейнерные среды у ИТ-специалистов часто возникает иллюзия, что микросервисы не требуют резервного копирования. Распространенный миф о том, что в Kubernetes всё работает в режиме stateless, нередко приводит к потере критически важных данных при серьезных сбоях.
На совместном вебинаре Андрей Крючков (директор по развитию технологических партнерств Киберпротекта) и Анатолий Щедловский (руководитель службы технической совместимости компании «Флант», разработчика платформы Deckhouse) обсудили, как меняются подходы к защите данных в контейнерных средах и как обеспечить консистентность бэкапов в гибридной инфраструктуре.
Контейнеризация в России: тренды, статистика и барьеры миграции
Российский рынок контейнеризации постепенно вступает в фазу зрелости. Согласно исследованиям, к 2030 году его объем может достигнуть 35 миллиардов рублей, а Kubernetes окончательно перестанет быть площадкой исключительно для пилотных проектов. Оркестратор все чаще становится стандартом для запуска критически важных бизнес-систем: stateful-нагрузок, баз данных и ML/AI-приложений.

Основные бизнес-драйверы этого перехода:
- Сокращение времени вывода ИТ-продуктов на рынок (Time to Market)
- Минимизация простоев за счет постепенных обновлений (Rolling Updates)
- Экономия на утилизации физических ресурсов (уплотнение нагрузок до 40% по сравнению с классической виртуализацией)
С технической стороны ИТ-команды получают унификацию окружений, прозрачную управляемость трафиком (например, для канареечных релизов) и возможность сетевой сегментации по модели Zero Trust.
Однако на практике миграция сопряжена со множеством трудностей. Опрос участников вебинара показал состояние дел в российских компаниях, выявив ключевые барьеры и особенности эксплуатации контейнеров:
- Контейнеры стали отраслевым стандартом, но в основном на этапе пилотных проектов. Почти 90% компаний уже так или иначе используют контейнеризацию в своей практике. При этом рынок находится на этапе перехода: 55% респондентов тестируют технологию только в рамках пилотных проектов. Для большинства или всех сервисов контейнеры используют 31% респондентов, и лишь 14% пока не применяют их совсем.
- Паритет автоматизации и ручного запуска. Только 42% компаний используют специализированные оркестраторы для управления инфраструктурой. Столько же участников опроса (42%) продолжают запускать контейнеры вручную или с помощью простых скриптов, а 16% пока не автоматизировали этот процесс.
- Импортозамещение набирает ход. Отечественные платформы выбирают уже 36% респондентов. При этом лидером в российском сегменте стала платформа Deckhouse от компании «Флант» — ее используют 32% участников вебинара. Зарубежные оркестраторы остаются у 32% опрошенных, другие системы применяют 27%, а гибридный стек — 5%.
- Кадры и процессы — главные барьеры. Более половины опрошенных компаний (52%) сталкиваются с нехваткой квалификации ИТ-команды и внутренним сопротивлением изменениям в процессах разработки. Другими значимыми препятствиями стали высокая стоимость переписывания кода и миграции (19%), сложности в работе со stateful-нагрузками и настройке резервного копирования (18%), а также ограничения регуляторов (11%).
- Осторожность в планах. Почти половина участников опроса (48%) планирует в ближайшем будущем использовать контейнеры только для тестовых и некритичных задач. Активно наращивать стек и переводить в микросервисы основные проекты готовы лишь 24%, а 28% респондентов пока сознательно остаются на классических виртуальных или физических серверах.
Что нужно бэкапить в Kubernetes?
Как показывают результаты опроса, почти каждая пятая компания (18%) видит серьезный барьер в сложности резервного копирования контейнеризованных систем. Это во многом связано с тем, что в традиционной инфраструктуре бэкап обычно сводился к созданию снапшота виртуальной машины (ВМ). В динамичной среде Kubernetes этот подход не работает: поды постоянно перемещаются между узлами, масштабируются и пересоздаются.
Надежный бэкап должен покрывать три уровня:
1) Платформенный слой: база данных etcd (состояние кластера), конфигурации RBAC, сетевые политики (Network Policies) и настройки хранилищ
2) Прикладной слой (манифесты): описания контроллеров (Deployments, StatefulSets), секреты (Secrets), конфигурационные карты (ConfigMaps) и ресурсы Ingress
3) Слой данных: постоянные тома (Persistent Volumes, PV) и их содержимое

Главные заблуждения о бэкапе контейнеров:
- «Достаточно бэкапить только etcd». В etcd нет самих данных приложений и образов контейнеров. При аварии восстановить работоспособный бизнес-сервис только из etcd не получится.
- «Достаточно делать снапшоты дисков через CSI». Снапшот диска фиксирует данные, но не логику приложения и не манифесты запуска. Без них СРК не сможет автоматически развернуть приложение в новом или очищенном кластере. Кроме того, снапшот на локальной СХД не защищает от выхода этой СХД из строя.
- «Stateless-приложения не нужно бэкапить». Манифесты stateless-приложений и образы контейнеров в реестре (Registry) также требуют резервирования. Если реестр образов станет недоступен, платформа не сможет перезапустить даже простые веб-интерфейсы.
Интеграция Кибер Бэкапа и платформы Deckhouse
Киберпротект и «Флант» сотрудничают в направлении интеграции продуктов уже около трех лет. Результатом этой работы стала бесшовная связка платформы Deckhouse и системы резервного копирования Кибер Бэкап. Платформа Deckhouse передает Кибер Бэкапу топологию приложения, а СРК формирует на ее основе воспроизводимый план защиты.
Ключевые возможности совместного решения:
1) Управление из единой консоли.Резервное копирование физических серверов, классических виртуальных машин, контейнеров Kubernetes и ВМ в среде Deckhouse Virtualization Platform (DVP) выполняется в рамках единых планов защиты из общего интерфейса.
2) Гранулярное резервное копирование и восстановление через метки (labels). Администраторам не нужно бэкапить весь кластер или пространство имен целиком. Поддержка меток Kubernetes в веб-консоли Кибер Бэкапа позволяет гибко выбирать отдельные поды, манифесты или хранилища. Это существенно сокращает окно бэкапа, снижает RTO и минимизирует нагрузку на сеть.
3) Гибкие режимы хранения постоянных томов (PV):
- Только локальные снимки: быстрое восстановление, но нет защиты от физического сбоя СХД
- Глубокий бэкап: данные переносятся во внешнее хранилище СРК, локальные снапшоты удаляются
- Гибридный режим: данные копируются во внешнюю СРК, но локальные снапшоты сохраняются для мгновенного восстановления при штатных сбоях

Часто задаваемые вопросы (FAQ)
Вопрос: Куда необходимо устанавливать агентов Кибер Бэкапа?
Ответ: Агент для Kubernetes устанавливается на отдельную машину под управлением ОС Linux либо на узел кластера Kubernetes. Процесс установки подробно описан в документации.
Вопрос: Поддерживает ли Кибер Бэкап установку агента внутрь пода (pod), например для резервного копирования СУБД как объекта?
Ответ: В Кибер Бэкапе агент для Kubernetes работает не внутри кластера. Он подключается через API Kubernetes, используя файлы конфигурации kubeconfig.
Вопрос: Может ли Кибер Бэкап создать резервную копию всего пространства имен со всеми приложениями и подключенными томами (PVC)?
Ответ: Да, Кибер Бэкап может выполнять резервное копирование всего пространства имен (namespace) и подключенных к нему PVC. Подробное руководство представлено в документации. Практическую демонстрацию этого процесса вы можете посмотреть в записи совместного вебинара.
Вопрос: Поддерживает ли Кибер Бэкап хранилище секретов Stronghold?
Ответ: Взаимодействие со Stronghold включает два аспекта: доступ СРК к секретам и резервное копирование самих секретов. Оба сценария находятся в разработке.
Вопрос: Какие драйверы CSI точно поддерживаются? Есть ли список? Например, драйвер для Longhorn поддерживается?
Ответ: Агент Кибер Бэкапа для Kubernetes взаимодействует с CSI-драйверами опосредованно — через API Kubernetes. СРК поддерживает любые CSI-драйверы, в которых реализована функция Snapshot. Список совместимых CSI-драйверов и сведения об их возможностях доступны в официальной документации разработчиков Kubernetes.
Вопрос: Можно ли моментальный снимок диска или ВМ делать на другой постоянный том (PV), отличный от того, на котором находится диск ВМ?
Ответ: Моментальный снимок всегда создается в том же хранилище, где размещены данные. Однако при восстановлении из снимка СРК создает новый PV, который обычно не зависит от оригинального (конкретная реализация зависит от бэкенда хранилища). Для миграции снимков в другие пулы или кластеры в платформе Deckhouse есть возможность скачать данные снимка и загрузить их в другое целевое хранилище в рамках существующего кластера.
Вопрос: Обеспечивает ли Кибер Бэкап консистентность между связанными сервисами?
Ответ: При резервном копировании пространства имен Кибер Бэкап одновременно создает моментальные снимки всех PVC, входящих в этот контур. Это гарантирует согласованность данных между взаимосвязанными сервисами.
Вопрос: Есть ли в Кибер Бэкапе политики по количеству или времени хранения (retention) локальных моментальных снимков?
Ответ: Да, сроки и правила хранения настраиваются непосредственно в планах резервного копирования. Подробнее этот процесс описан в документации по резервному копированию Kubernetes (раздел 5b), а также в разделе о правилах хранения копий.
Вопрос: Где могут храниться резервные копии?
Ответ: Кибер Бэкап поддерживает различные варианты хранилищ: локальные папки, сетевые папки, выделенные узлы хранения, продукты Кибер Инфраструктура Кибер Хранилище, а также папки по протоколу SFTP.
Заключение
Переход российских компаний на микросервисную архитектуру и контейнеризацию — это неизбежный шаг в развитии корпоративной ИТ-инфраструктуры. Однако запуск критически важных нагрузок в Kubernetes требует пересмотра классических подходов к резервному копированию.
Технологическое партнерство Киберпротекта и Фланта предлагает готовый сценарий для решения этих задач. Совместное использование платформы Deckhouse и Кибер Бэкапа позволяет унифицировать процессы защиты данных в контейнерных средах и классических виртуальных машинах, снизить риски потери информации и обеспечить непрерывность бизнес-процессов на базе отечественного ПО.
Смотрите полную запись вебинара на RUTUBE и в VK Видео
Связанные статьи:
10.09.2026 11:00