#Alauda Container Platform Registry 数据备份和恢复

#Overview

本方案提供了在 Alauda Container Platform (ACP) 中，针对使用 S3 兼容对象存储的 Alauda Container Platform Registry 数据备份和恢复的指导。

核心理念：将镜像数据本身（存储于 S3）与 cluster plugin 配置（定义于 Kubernetes 的 ModuleInfo 自定义资源）解耦管理。

• 备份：从 ModuleInfo 资源中获取 S3 配置，并备份指定存储 bucket 中的数据。
• 恢复：在新集群安装 cluster plugin 后，更新其 ModuleInfo 资源中的 S3 配置，指向已恢复数据的 bucket，从而完成数据接入。

优势：

• 操作解耦：数据备份/恢复独立于 ACP cluster plugin 的部署和升级流程。
• 配置驱动：所有连接信息通过声明式的 ModuleInfo 资源管理，确保变更安全可靠。
• 可扩展：该模式可扩展至其他存储后端（如本地文件系统、StorageClass、NAS 等）。

#前提条件

• 拥有对目标 Kubernetes 集群的 kubectl 访问权限及相应操作权限。
• 拥有访问和操作用于存储镜像数据的 S3 兼容存储的凭据和客户端工具（如 awscli、rclone、minio-client）。
• 已安装并配置好 Alauda Container Platform Registry 集群插件，其 ModuleInfo 资源存在且状态健康。
• 准备好独立且容量充足的存储空间用于备份数据（例如另一个 S3 bucket）。

#数据备份

本阶段目标是获取当前生产环境的 S3 配置，并对存储桶中的镜像数据进行全量备份。

#第 1 步：获取当前 S3 配置

从管理 Alauda Container Platform Registry 集群插件的 ModuleInfo 资源中提取 S3 存储配置，该信息是备份操作的基础。

请在 ACP 的 global 集群上执行以下命令：

# 1. 确认 image-registry 模块对应的 ModuleInfo 资源名称
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：实际存储镜像数据的源桶名称。
• S3_ENDPOINT：连接 S3 兼容服务的端点 URL。
• S3_REGION：S3 服务的地域标识。
• S3_SECRET_NAME：存储认证密钥的 Kubernetes Secret 名称。

#第 2 步：执行 S3 存储桶数据备份

使用您选择的 S3 客户端工具，利用上一步获取的配置对源桶数据进行全量备份。

操作逻辑：

• 配置客户端，使用端点（$S3_ENDPOINT）、地域（$S3_REGION）及从 Secret 解码得到的访问密钥。
• 执行同步或复制命令，将源桶（$S3_BUCKET）中的所有数据备份到您准备的独立备份位置（如另一个 S3 bucket 或路径）。
• 记录备份时间戳、所用桶名和端点信息，并与备份文件一并归档。

#数据恢复

本阶段假设 Alauda Container Platform Registry 集群插件已通过平台成功安装到目标环境（新集群或修复集群），目标是修改其配置以访问已恢复的镜像数据。

#第 1 步：准备备份数据

使用您选择的 S3 客户端工具，将备份的镜像数据恢复到一个确定可访问的目标 S3 存储桶，例如恢复到名为 registry-bucket-restored 的新桶。确保您对该目标桶拥有写权限。

#第 2 步：更新 ModuleInfo 配置

恢复的关键在于更新新 cluster plugin 的 ModuleInfo 资源，将其 S3 配置指向包含备份数据的目标桶。

1. 确定新的 S3 连接信息：

• NEW_BUCKET：备份数据已恢复的目标桶名称（例如 registry-bucket-restored）。
• NEW_ENDPOINT：目标 S3 服务的端点，如果 S3 服务地址与备份时相同，则保持不变。
• NEW_REGION：目标 S3 服务的地域。
• NEW_SECRET_NAME：拥有目标桶读写权限的 Kubernetes Secret 名称。如果访问密钥未变，则仍为 $S3_SECRET_NAME。

2. 更新 ModuleInfo 资源： 使用 kubectl patch 命令直接更新 ModuleInfo 的 S3 配置部分，平台控制器会自动同步该变更到所有相关的 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"'"
          }
        }
      }
    }'

关键点：此操作会触发 Alauda Container Platform Registry 相关 Pod 的滚动更新，新启动的 Pod 将使用新的配置连接指定的目标存储桶。

#验证

更新完成后，按以下步骤验证数据恢复成功及服务正常运行。

#检查模块状态（在 global 集群）

# 查看 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 测试）

通过 Registry 的 API 接口直接验证是否能读取恢复的镜像数据。

# 获取 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",...]}

#功能测试

尝试从恢复的 Registry 拉取已知镜像，或向其推送新镜像，全面验证读写功能。

#方案通用性

虽然本方案以 S3 存储为例，但其设计模式适用于 Registry 支持的各种存储后端（如本地文件系统、StorageClass、NAS 等）。

通用原则：无论存储类型如何，核心备份和恢复流程一致。首先从 ModuleInfo 资源对应配置块（如 s3storage、persistence）中提取存储连接参数，再使用相应存储工具备份数据。恢复时，将数据恢复到目标位置后，更新 ModuleInfo 中对应配置字段，平台自动引导新部署的实例访问该位置。

核心价值：通过利用统一的配置抽象层（ModuleInfo），本方案实现了数据备份/恢复流程与具体存储实现及 Kubernetes 应用部署的解耦，达成标准化管理与可扩展性。