В блог

Как защитить данные в Kubernetes: опыт Киберпротекта и Фланта

Статьи 11.08.2026 9 мин
Поделиться
Ссылка скопирована
картинка блога

При переходе на контейнерные среды у ИТ-специалистов часто возникает иллюзия, что микросервисы не требуют резервного копирования. Распространенный миф о том, что в Kubernetes всё работает в режиме stateless, нередко приводит к потере критически важных данных при серьезных сбоях.

На совместном вебинаре Андрей Крючков (директор по развитию технологических партнерств Киберпротекта) и Анатолий Щедловский (руководитель службы технической совместимости компании «Флант», разработчика платформы Deckhouse) обсудили, как меняются подходы к защите данных в контейнерных средах и как обеспечить консистентность бэкапов в гибридной инфраструктуре.

Контейнеризация в России: тренды, статистика и барьеры миграции

Российский рынок контейнеризации постепенно вступает в фазу зрелости. Согласно исследованиям, к 2030 году его объем может достигнуть 35 миллиардов рублей, а Kubernetes окончательно перестанет быть площадкой исключительно для пилотных проектов. Оркестратор все чаще становится стандартом для запуска критически важных бизнес-систем: stateful-нагрузок, баз данных и ML/AI-приложений.

picture

Основные бизнес-драйверы этого перехода:

  • Сокращение времени вывода ИТ-продуктов на рынок (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) и их содержимое

picture

Главные заблуждения о бэкапе контейнеров:

  • «Достаточно бэкапить только etcd». В etcd нет самих данных приложений и образов контейнеров. При аварии восстановить работоспособный бизнес-сервис только из etcd не получится.
  • «Достаточно делать снапшоты дисков через CSI». Снапшот диска фиксирует данные, но не логику приложения и не манифесты запуска. Без них СРК не сможет автоматически развернуть приложение в новом или очищенном кластере. Кроме того, снапшот на локальной СХД не защищает от выхода этой СХД из строя.
  • «Stateless-приложения не нужно бэкапить». Манифесты stateless-приложений и образы контейнеров в реестре (Registry) также требуют резервирования. Если реестр образов станет недоступен, платформа не сможет перезапустить даже простые веб-интерфейсы.

Интеграция Кибер Бэкапа и платформы Deckhouse

Киберпротект и «Флант» сотрудничают в направлении интеграции продуктов уже около трех лет. Результатом этой работы стала бесшовная связка платформы Deckhouse и системы резервного копирования Кибер Бэкап. Платформа Deckhouse передает Кибер Бэкапу топологию приложения, а СРК формирует на ее основе воспроизводимый план защиты.

Ключевые возможности совместного решения:

1) Управление из единой консоли.Резервное копирование физических серверов, классических виртуальных машин, контейнеров Kubernetes и ВМ в среде Deckhouse Virtualization Platform (DVP) выполняется в рамках единых планов защиты из общего интерфейса.
2) Гранулярное резервное копирование и восстановление через метки (labels). Администраторам не нужно бэкапить весь кластер или пространство имен целиком. Поддержка меток Kubernetes в веб-консоли Кибер Бэкапа позволяет гибко выбирать отдельные поды, манифесты или хранилища. Это существенно сокращает окно бэкапа, снижает RTO и минимизирует нагрузку на сеть.
3) Гибкие режимы хранения постоянных томов (PV):

  • Только локальные снимки: быстрое восстановление, но нет защиты от физического сбоя СХД
  • Глубокий бэкап: данные переносятся во внешнее хранилище СРК, локальные снапшоты удаляются
  • Гибридный режим: данные копируются во внешнюю СРК, но локальные снапшоты сохраняются для мгновенного восстановления при штатных сбоях

picture

фон фон фон фон
Кибер Бэкап
Защита данных контейнерных сред
Узнать больше

Часто задаваемые вопросы (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
Кибер Бэкап: защита высоконагруженных инфраструктур Узнайте, как механизмы современной СРК позволяют обеспечить производительную и масштабируемую защиту данных Зарегистрироваться
sbscrIconLight.png
Подпишитесь на нашу рассылку Будьте в курсе всех новостей и событий Подписаться
Вы успешно подписались на рассылку Киберпротект!
Читать также