Как Кибер Бэкап защищает Kubernetes

Введение

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

Когда количество микросервисов вырастает до десятков и сотен, управлять ими вручную становится невозможно. Для автоматизации развертывания, масштабирования и балансировки нагрузок используется оркестрация. Фактическим стандартом в этой области стал Kubernetes (K8s), который берет на себя декларативное управление приложениями.

Однако обеспечение отказоустойчивости в K8s устроено значительно сложнее, чем в классических инфраструктурах. Автоматизировать эти процессы и гарантировать сохранность данных помогают специализированные системы резервного копирования, такие как Кибер Бэкап. В этом обзоре мы разберем архитектурные особенности защиты сред Kubernetes и возможности отечественной СРК по обеспечению киберустойчивости.

Наши предыдущие статьи на тему:

• «Как работают платформы контейнеризации: устройство и ключевые компоненты»
• «Виртуальные машины vs. контейнеры: сравнение технологий и рекомендации по выбору»

Где используется Kubernetes в России

Российский крупный бизнес и госсектор активно переводят системы на микросервисную архитектуру в рамках стратегии технологического суверенитета и импортозамещения. Сегодня Kubernetes применяется в большинстве критических отраслей:

Резервное копирование Kubernetes

Резервное копирование в Kubernetes устроено иначе, чем бэкап обычных серверов, ВМ или приложений. Всё из-за двух вещей: декларативности и распределенности. Когда вы выполняете резервное копирование виртуальной машины, вы обычно берете цельный образ диска или моментальный снимок — со всем сразу: ядром, библиотеками, конфигурационными файлами и данными приложения. Восстановление ВМ выглядит как откат к определенному моменту: возвращается машина с ее IP-адресами, файловой системой и работающими процессами.

В мире Kubernetes инфраструктура эфемерна. Поды и контейнеры могут пересоздаться в любую секунду. Состояние приложения живет не на локальных дисках, а в etcd (ключах, ресурсах, API-объектах) и во внешних PV. Именно поэтому бэкап Kubernetes — это не клонирование дисков узлов кластера. Это выгрузка манифестов (Deployment, ConfigMap, Secret, Service) в сочетании с моментальными снимками и синхронизированными копиями томов с данными.

Логика восстановления здесь также иная. Когда вы восстанавливаете ВМ или обычное приложение, вы по сути запускаете все с нуля или переустанавливаете из резервной копии в подготовленное окружение.

В Kubernetes на первый план выходят селективность и трансформация. В K8s редко требуется восстанавливать кластер целиком — чаще необходимо восстановить конкретное пространство имен (Namespace) или отдельный объект. Кластер живет своей жизнью, контроллеры постоянно меняют состояние. Если просто «вслепую» восстановить etcd — можно нарушить работу приложений.

Поэтому современные системы резервного копирования работают на уровне API-объектов. Они архивируют ресурсы со всеми связями (ownerReferences), умеют подменять storageClass, переписывать образы контейнеров и извлекать данные. В отличие от монолитного подхода «образ ВМ → восстановить всю ВМ целиком», Kubernetes требует декларативного, объектно-ориентированного и зависящего от контекста подхода. Целью является воссоздать нужное состояние приложения на любом работающем кластере.

Возможности Кибер Бэкапа по защите Kubernetes

Кибер Бэкап поддерживает резервное копирование пространств имен и постоянных томов Kubernetes. Для этого используется специальный агент, который выполняет операции резервного копирования, записи резервных копий и восстановления данных. Агент устанавливается на хосте Kubernetes или на удаленном хосте и поддерживает наиболее популярные зарубежные и российские дистрибутивы ОС Linux. Агент подключается к кластеру Kubernetes извне, используя Kubernetes API. Агент использует Docker-образ k8s-backup-and-restore, который расположен в Docker-репозитории https://registry.cyberprotect.ru/registry. В случае использования среды без доступа в Интернет можно разместить Docker-образ, необходимый агенту для Kubernetes, во внутреннем Docker-репозитории.

Сценарии резервного копирования

Кибер Бэкап может выполнять резервное копирование пространств имен Kubernetes, групп пространств имен, конфигурационных файлов платформы и постоянных томов на уровне файлов. Также поддерживается создание резервной копии всего кластера Kubernetes: отдельной копии кластера со всеми его настройками. При настройке планов резервного копирования и при восстановлении возможно использование меток Kubernetes в веб-консоли управления.

Резервное копирование пространств имен

План резервного копирования применяется к пространству имен. Резервная копия содержит только одно пространство имен. Можно применить план к группе пространств имен или ко всему кластеру. Для каждого пространства имен будет создан отдельный архив.

Резервное копирование постоянных томов

Для создания моментальных снимков томов в кластере Kubernetes должны быть установлены Container Storage Interface (CSI)-драйвер с поддержкой функций Snapshot и контроллер моментальных снимков томов, включая CRD (Custom Resource Definition). Контроллер отслеживает объекты VolumeSnapshot и выполняет создание снапшота, используя CSI драйвер. Если драйвер поддерживает функцию Raw Block, то резервное копирование тома будет выполнено как блочного устройства — это быстрее.

Создание моментальных снимков PVC выполняется через CSI-драйвер. Создается моментальный снимок данных на уровне хранилища (SAN, NAS). 

При настройке плана защиты можно указать место хранения моментальных снимков:

• На вашей СХД — быстрое восстановление на тот же кластер
• В хранилище Кибер Бэкапа — экономите место на СХД, но восстановление дольше. Варианты: локальная папка, сетевая папка, узел хранения, Кибер Инфраструктура / Кибер Хранилище, папка NFS, SFTP
• Комбинированное — будут использоваться оба хранилища. Этот вариант обеспечит восстановление в случае недоступности СХД

Процесс резервного копирования постоянного тома (PersistentVolume) в хранилище Кибер Бэкапа

Интерфейс CSI (Container Storage Interface) сегодня является фактическим стандартом, но многие заказчики до сих пор используют старые подходы, например, In-Tree драйверы. В этом случае, так как отсутствует совместимость с драйвером CSI, для резервного копирования не может быть использован механизм моментальных снимков. В Кибер Бэкапе реализован дополнительный механизм резервного копирования постоянных томов без использования моментальных снимков. Это обеспечивает более широкое соответствие реализуемым у заказчиков сценариям использования оркестратора.

Сценарии восстановления данных

Поддерживается возможность восстановления данных из резервной копии в тот же кластер Kubernetes, например, для быстрого отката изменений или в другой кластер, например, для тестирования или масштабирования. Это обеспечивает гибкость управления данными и минимизирует простой в случае сбоев. 

Например, если для тома создавался моментальный снимок, то проверяется его наличие и состояние. В случае успеха, через API Kubernetes создается том на основе моментального снимка (создание такого тома обрабатывается CSI драйвером) — на этом восстановление тома завершено. Если невозможно восстановить том из моментального снимка, то производится восстановление данных тома из архива. Класс хранилища (StorageClass) восстанавливается вместе с томом при необходимости.

Восстановление пространств имен

Восстановить можно всё пространство имен целиком или только тома. В процессе восстановления агент использует API Kubernetes. Резервная копия может содержать ресурсы уровня кластера (например, StorageClass или CustomResourceDefinition). При восстановлении таких ресурсов применяются настройки перезаписи. Также доступна функция очистки пространства имен перед восстановлением. При ее включении, сначала все ресурсы пространства имен будут удалены. Каждый ресурс при восстановлении обрабатывается следующим образом:

• Производится попытка создать ресурс
• Если такой ресурс уже существует, то агент пытается его обновить
• Если обновить не удалось, то существующий ресурс удаляется и создается новый

Восстановление томов

В процессе восстановления производится проверка наличия тома с таким же именем в целевом пространстве имен. Если такой том уже есть, то агент останавливает все поды, которые его используют, и удаляет существующий том. Остановленные поды запускаются снова после восстановления тома.

Если для тома создавался моментальный снимок, то проверяется его наличие и состояние. В случае успеха, через API Kubernetes создается том на основе моментального снимка (создание такого тома обрабатывается CSI драйвером) — на этом восстановление тома завершено. Если невозможно восстановить том из моментального снимка, то производится восстановление данных тома из архива. Класс хранилища (StorageClass) восстанавливается вместе с томом при необходимости. Остановленные поды пропатчатся для использования нового тома.

Процесс восстановления данных тома из архива

Kubernetes кардинально изменил подход к развертыванию и масштабированию приложений, но принес с собой новые требования к защите данных. В условиях российской ИТ-экосистемы, где на первый план выходят технологический суверенитет, соответствие регуляторным нормам и устойчивость к внешним угрозам, резервное копирование стало обязательным элементом ИТ-архитектуры.

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

Хотите глубже погрузиться в тему и увидеть, как выстроить защиту данных в Kubernetes на практике? Присоединяйтесь к нашему совместному вебинару с экспертами Deckhouse (АО «Флант») «Как обеспечить сохранность данных в контейнерных средах. Экосистема решений от ведущих российских компаний». Он пройдёт 25 июня в 10:00 МСК. Подробности и регистрация