#Обзор

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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