#Резервное копирование и восстановление данных Alauda Container Platform Registry

#Обзор

Данное решение предоставляет рекомендации по резервному копированию и восстановлению данных Alauda Container Platform Registry, использующего объектное хранилище, совместимое с S3, в Alauda Container Platform (ACP).

Основная идея: разделить управление самими данными образов (хранящимися в S3) и конфигурацией cluster plugin (определяемой в пользовательском ресурсе Kubernetes ModuleInfo).

• Резервное копирование: получить конфигурацию S3 из ресурса ModuleInfo и выполнить резервное копирование данных из указанного хранилища bucket.
• Восстановление: после установки cluster plugin в новом кластере обновить его конфигурацию S3 в ресурсе ModuleInfo, указав bucket с восстановленными данными, тем самым завершив интеграцию данных.

Преимущества:

• Разделение операций: резервное копирование и восстановление данных не зависят от процессов развертывания и обновления ACP cluster plugin.
• Управление через конфигурацию: вся информация о подключении управляется декларативным ресурсом ModuleInfo, что обеспечивает безопасные и надежные изменения.
• Расширяемость: данный шаблон можно применить к другим типам хранилищ (например, локальная файловая система, StorageClass, NAS).

#Требования

• Наличие доступа kubectl и соответствующих прав для работы с целевым Kubernetes кластером.
• Наличие учетных данных и клиентских инструментов (например, awscli, rclone, minio-client) для доступа и управления объектным хранилищем, совместимым с S3, используемым для данных образов.
• Установленный и настроенный Alauda Container Platform Registry cluster plugin, ресурс ModuleInfo которого существует и находится в здоровом состоянии.
• Подготовленное независимое и достаточное по объему хранилище для резервных данных (например, другой S3 bucket).

#Резервное копирование данных

Цель этого этапа — получить текущую рабочую конфигурацию S3 и выполнить полное резервное копирование данных образов из bucket хранилища.

#Шаг 1: Получение текущей конфигурации S3

Извлеките конфигурацию S3 из ресурса ModuleInfo, управляющего Alauda Container Platform Registry cluster plugin. Эта информация является основой для резервного копирования.

Команды следует выполнять в global кластере ACP:

# 1. Определить имя ресурса ModuleInfo для модуля image-registry
MODULE_INFO_NAME=$(kubectl get moduleinfo -l cpaas.io/module-name=image-registry -o jsonpath='{.items[0].metadata.name}')
echo "Целевой ресурс ModuleInfo: $MODULE_INFO_NAME"

# 2. Извлечь ключевую информацию конфигурации S3
S3_BUCKET=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.bucket}')
S3_ENDPOINT=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.regionEndpoint}')
S3_REGION=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.region}')
S3_SECRET_NAME=$(kubectl get moduleinfo $MODULE_INFO_NAME -o jsonpath='{.spec.config.s3storage.secretName}')

# 3. Получить ключи доступа из Secret (обычно access-key-id и secret-access-key)
# Примечание: вывод закодирован в Base64 и требует соответствующего декодирования.
kubectl get secret -n cpaas-system $S3_SECRET_NAME -o jsonpath='{.data}'

Описание ключевых переменных:

• S3_BUCKET: имя исходного bucket, где фактически хранятся данные образов.
• S3_ENDPOINT: URL-адрес подключения к сервису, совместимому с S3.
• S3_REGION: регион S3 сервиса.
• S3_SECRET_NAME: имя Kubernetes Secret, содержащего ключи аутентификации.

#Шаг 2: Резервное копирование данных bucket S3

Используя выбранный клиент S3, примените полученную на предыдущем шаге конфигурацию для полного резервного копирования данных из исходного bucket.

Логика операции:

• Настройте клиент с использованием endpoint ($S3_ENDPOINT), региона ($S3_REGION) и декодированных ключей доступа из Secret.
• Выполните команду синхронизации или копирования для резервного копирования всех данных из исходного bucket ($S3_BUCKET) в подготовленное независимое место хранения (например, другой S3 bucket или путь).
• Зафиксируйте время резервного копирования, имя bucket и endpoint, используемые для операции, и сохраните эту информацию вместе с файлами резервной копии.

#Восстановление данных

Этот этап предполагает, что Alauda Container Platform Registry cluster plugin успешно установлен в целевой среде (новом или восстановленном кластере) через платформу. Цель — изменить его конфигурацию для доступа к восстановленным данным образов.

#Шаг 1: Подготовка резервных данных

Используя выбранный клиент S3, восстановите резервные данные образов в целевой S3 bucket, к которому гарантирован доступ. Например, восстановите их в новый bucket с именем registry-bucket-restored. Убедитесь, что у вас есть права записи в этот bucket.

#Шаг 2: Обновление конфигурации ModuleInfo

Ключ к восстановлению — обновить ресурс ModuleInfo нового cluster plugin, указав в конфигурации S3 целевой bucket с резервными данными.

1. Определите новую информацию для подключения к S3:

• NEW_BUCKET: имя целевого bucket, куда восстановлены данные (например, registry-bucket-restored).
• NEW_ENDPOINT: endpoint целевого S3 сервиса. Остается без изменений, если адрес S3 сервиса совпадает с тем, что был при резервном копировании.
• NEW_REGION: регион целевого S3 сервиса.
• NEW_SECRET_NAME: имя Kubernetes Secret с правами чтения/записи для целевого bucket. Если ключи доступа не изменились, это тот же $S3_SECRET_NAME.

2. Обновите ресурс ModuleInfo: Используйте команду kubectl patch для прямого обновления секции конфигурации S3 в ModuleInfo. Контроллер платформы автоматически синхронизирует это изменение со всеми соответствующими Deployment, Pod и другими ресурсами.

   # Выполнить обновление конфигурации
    kubectl patch moduleinfo $MODULE_INFO_NAME --type=merge -p '{
      "spec": {
        "config": {
          "s3storage": {
            "bucket": "'"$NEW_BUCKET"'",
            "regionEndpoint": "'"$NEW_ENDPOINT"'",
            "region": "'"$NEW_REGION"'",
            "secretName": "'"$NEW_SECRET_NAME"'"
          }
        }
      }
    }'

Важный момент: Эта операция инициирует rolling update Pod-ов, связанных с Alauda Container Platform Registry. Новые Pod-ы будут использовать обновленную конфигурацию для подключения к указанному целевому bucket.

#Проверка

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

#Проверка статуса модуля (в глобальном кластере)

# Проверить, что Pod-ы успешно перезапустились и работают с новой конфигурацией
kubectl get pods -n cpaas-system -l app=image-registry
# Просмотреть логи Pod-ов для подтверждения отсутствия ошибок подключения к S3
kubectl logs -n cpaas-system -l app=image-registry -c registry --tail=50

#Проверка доступа к данным (тест API)

Используйте API Registry для прямой проверки возможности чтения восстановленных данных образов.

# Получить адрес доступа к сервису Registry (предполагается тип ClusterIP)
REGISTRY_SVC_IP=$(kubectl get svc -n cpaas-system image-registry -o jsonpath='{.spec.clusterIP}')

# Тест 1: Запрос каталога репозиториев
curl -s http://$REGISTRY_SVC_IP/v2/_catalog | jq .
# Ожидаемый успешный ответ: {"repositories":["image1","image2",...]}

# Тест 2: Запрос списка тегов для конкретного образа (например, образа с именем `myns/nginx`)
curl -s http://$REGISTRY_SVC_IP/v2/myns/nginx/tags/list | jq .
# Ожидаемый успешный ответ: {"name":"myns/nginx","tags":["v1.0","latest",...]}

#Функциональное тестирование

Попробуйте скачать известный образ из восстановленного реестра или загрузить в него новый образ для полной проверки функциональности чтения и записи.

#Универсальность решения

Хотя в данном решении в качестве примера используется хранилище S3, его архитектурный шаблон применим к различным типам хранилищ, поддерживаемых Registry (например, локальная файловая система, StorageClass, NAS).

Общий принцип: независимо от типа хранилища, основной процесс резервного копирования и восстановления остается одинаковым. Сначала извлекаются параметры подключения к хранилищу из соответствующего блока конфигурации (например, s3storage, persistence) в ресурсе ModuleInfo, затем с помощью соответствующих инструментов выполняется резервное копирование данных. Для восстановления после переноса данных в целевое место достаточно обновить соответствующие поля конфигурации в ModuleInfo. Платформа автоматически направит вновь развернутый экземпляр к этому месту.

Основная ценность: используя единый уровень абстракции конфигурации (ModuleInfo), данное решение отделяет процесс резервного копирования и восстановления данных от конкретных реализаций хранилищ и развертываний приложений в Kubernetes, обеспечивая стандартизированное управление и расширяемость.