#Обзор

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

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

Для восстановления данных приложений кластера выполните задачу восстановления приложения на основе существующих файлов резервных копий.

#Сценарии использования

Для различных сценариев резервного копирования и восстановления настройте политики резервного копирования и выполните восстановление следующим образом.

#Резервное копирование и восстановление в текущем Kubernetes кластере

При сбое локального приложения (например, при случайном удалении namespace) восстановите приложение в текущем кластере с помощью файла резервной копии. При восстановлении обычно не требуется изменять ресурсы приложения (например, доменные имена и порты сервисов); восстановите только соответствующие ресурсы кластера.

1. Установите плагин: Установите плагин резервного копирования и восстановления в текущем кластере.

2. Настройте репозиторий резервных копий: Настройте репозиторий резервных копий в текущем кластере.

3. Создайте расписание резервного копирования: Создайте расписание резервного копирования приложения в текущем кластере. Выберите namespaces, в которых размещено приложение, и настройте периодическое расписание.

4. Запустите задачу восстановления: При необходимости восстановления запустите задачу восстановления приложения в текущем кластере.

#Миграция приложений и данных между кластерами

Распространённые сценарии резервного копирования и восстановления между кластерами включают:

• В традиционных сценариях разработки и тестирования приложения могут мигрировать между дата-центрами и восстанавливаться из резервных копий в другие кластеры. После восстановления может потребоваться корректировка ресурсов приложения (например, доменных имён и портов сервисов).

• Миграция ресурсов кластера в другие кластеры.

• Репликация ресурсов производственного кластера в кластеры разработки и тестирования.

#Предварительные условия

• Убедитесь, что CPU, память и другие характеристики исходного и целевого кластеров схожи. Большие различия могут привести к невозможности назначения pod’ов и оставлению их в состоянии Pending после миграции.

• Убедитесь, что сетевой режим исходного и целевого кластеров совпадает; в противном случае некоторые ресурсы могут быть восстановлены некорректно. При различии подсетей IP-адреса pod’ов изменятся после восстановления.

#Рекомендуемый порядок действий

1. Установите плагин: Установите плагин резервного копирования и восстановления в текущем кластере.

2. Настройте репозиторий резервных копий: Настройте репозиторий резервных копий в текущем кластере.

3. Создайте задачу резервного копирования: В исходном кластере создайте задачу резервного копирования приложения, выберите namespaces с работающим приложением и настройте периодическое расписание.

4. Определите необходимость миграции образов: Перед восстановлением данных оцените, требуется ли миграция образов. Если репозиторий образов находится вне обоих кластеров и доступен с обеих сторон, этот шаг можно пропустить. Для сценариев с необходимостью миграции образов смотрите Image Registry Replacement.

5. Запустите задачу восстановления: В целевом кластере запустите задачу восстановления приложения.

6. Импортируйте namespace: После миграции данных вручную импортируйте namespace в соответствующий проект в Project Management. Иначе восстановленное приложение может не отображаться в UI платформы.

#Миграция приложений и данных между платформами

В сценариях межплатформенного аварийного восстановления, когда основной кластер платформы выходит из строя и рабочие нагрузки переключаются на кластер на вторичной платформе, после миграции могут потребоваться корректировки приложения (например, доменные имена и порты сервисов).

#Предварительные условия

• Убедитесь, что CPU, память и другие характеристики исходного и целевого кластеров схожи, чтобы избежать ситуации, когда pod’ы остаются без назначения из-за нехватки ресурсов.

• Убедитесь, что сетевой режим исходного и целевого кластеров совпадает; в противном случае некоторые ресурсы могут быть восстановлены некорректно. При различии подсетей IP-адреса pod’ов изменятся после восстановления.

#Рекомендуемый порядок действий

1. Установите плагин: Установите плагин резервного копирования и восстановления в текущем кластере.

2. Настройте репозиторий резервных копий: Настройте репозиторий резервных копий в текущем кластере.

3. Создайте задачу резервного копирования: В кластере, который подлежит миграции, создайте политику резервного копирования приложения, выберите соответствующие namespaces и настройте периодическое расписание.

4. Определите необходимость миграции образов: Перед восстановлением данных оцените, требуется ли миграция образов. Если репозиторий образов находится вне обоих кластеров и доступен с обеих сторон, этот шаг можно пропустить. Для сценариев с необходимостью миграции образов смотрите Image Registry Replacement.

5. Запустите задачу восстановления: В целевом кластере запустите задачу восстановления приложения.

6. Импортируйте namespace: После миграции данных вручную импортируйте namespace в соответствующий проект в Project Management. Иначе восстановленное приложение может не отображаться в UI платформы.