跳到主要内容

集群与存储绑定关系

Testudo 通过 Cluster、StorageRepository 和 Velero BackupStorageLocation 把源集群、目标集群和对象存储连接在一起。理解这层绑定关系，可以帮助判断为什么容灾场景要求源集群和目标集群都能访问同一份备份存储。

参与对象​

对象所在位置作用
Cluster管理集群描述一个业务集群的访问方式、状态和 Velero 安装配置
StorageRepository管理集群描述对象存储 endpoint、bucket、region、prefix、凭据、CA 和地址模式
DisasterConfig管理集群把源集群、目标集群、存储仓库和同步策略组合成一个容灾基础配置
BackupStorageLocation源集群和目标集群的 velero 命名空间Velero 真实使用的备份存储位置
AppBackup / AppRestore管理集群平台封装的备份和恢复任务，由 operator 在远端集群创建 Velero Backup / Restore

StorageRepository 是平台层配置，BackupStorageLocation 是 Velero 在业务集群内实际消费的配置。一个 StorageRepository 会被 operator 转换成远端集群中的 BSL。

DisasterConfig 如何绑定集群和存储​

创建容灾基础配置时，需要选择：

  • 源集群。
  • 目标集群。
  • 存储仓库。
  • DataSync 策略。
  • ResourceSync 策略。

这会形成如下关系：

DisasterConfig
  sourceCluster: <sourceCluster>
  targetCluster: <targetCluster>
  storageRepository: <storageRepository>

operator 调谐 DisasterConfig 时，会读取这个 StorageRepository，并把它应用到源集群和目标集群。

BSL 命名规则​

在容灾同步场景中，运行时 BSL 名称使用源集群作为后缀：

BSL name = <StorageRepository>-<sourceCluster>
prefix   = <sourceCluster>

例如：

StorageRepository = s3-default
sourceCluster     = prod-a
targetCluster     = dr-b

BSL name = s3-default-prod-a
prefix   = prod-a

这个 BSL 会同时出现在源集群和目标集群的 velero 命名空间中：

source cluster / velero / BackupStorageLocation s3-default-prod-a
target cluster / velero / BackupStorageLocation s3-default-prod-a

两个 BSL 名称相同，配置也指向同一个对象存储位置。

为什么目标集群要访问源集群的 BSL​

DataSync 的数据链路是：

源集群 Velero Backup
  -> 写入对象存储
  -> 目标集群 Velero Restore
  -> 恢复到目标 PVC

源集群负责写入备份对象，目标集群负责读取这些备份对象。目标集群读取的不是一份新的目标侧备份，而是源集群刚写入的同一份备份数据。

因此目标集群必须具备一个能读取源端备份的 BSL：

BSL name = <StorageRepository>-<sourceCluster>
prefix   = <sourceCluster>

这样 Velero Restore 才能找到源集群 Backup 写入的对象。

为什么可以共用同一个 bucket​

多个集群可以共用同一个 bucket，原因是 Testudo 使用源集群名称作为对象存储 prefix：

bucket/
  prod-a/
    backups/
    kopia/
    restic/
  prod-b/
    backups/
    kopia/
    restic/

不同源集群写入不同 prefix，备份对象不会互相覆盖。目标集群只要读取对应源集群 prefix，就可以恢复该源集群生成的备份。

这种模型的好处是：

  • 容灾切换时，目标集群可以直接读取源集群最新备份。
  • 反向保护时，新的源集群会使用新的源集群 prefix。
  • 同一个对象存储可以承载多个容灾方向，但仍通过 prefix 隔离数据。
  • 运维只需要管理一套存储凭据和生命周期策略。

网络和权限要求​

源集群和目标集群都必须满足：

  • 能解析并访问对象存储 endpoint。
  • 能使用同一套或等价权限的访问凭据。
  • 具备读取 bucket 和 prefix 的权限。
  • 源集群具备写入、列举、读取备份对象的权限。
  • 目标集群至少具备列举和读取源集群备份对象的权限；如果会执行反向保护，也需要写入权限。
  • 如果使用私有 CA，Velero Pod 必须信任该 CA。
  • 如果对象存储使用 path-style 或 virtual-host-style 地址模式，所有集群中的配置必须一致。

生产环境中，建议直接给源集群和目标集群都配置读写权限。只给目标集群读权限会影响反向保护、演练或后续反向同步。

常见误区​

误区正确理解
源集群和目标集群各配置一个不同 bucket容灾同步要求目标集群读取源集群写入的备份对象，推荐使用同一个 bucket 或同一个可共享对象存储位置
目标集群只需要访问自己的 BSL目标集群需要访问以源集群命名的 BSL，例如 <StorageRepository>-<sourceCluster>
管理集群连接测试成功就代表恢复一定成功管理集群测试只证明 server 能访问对象存储，还需要源集群和目标集群中的 Velero BSL 都进入 Available
BSL 名称带目标集群后缀容灾同步恢复读取源端备份，运行时 BSL 使用源集群后缀
bucket 不能被多个集群共用可以共用，但必须通过 prefix、权限、生命周期和审计策略做好隔离

验证方法​

查看源集群和目标集群中的 BSL：

kubectl --context <source-cluster> -n velero get backupstoragelocation
kubectl --context <target-cluster> -n velero get backupstoragelocation

确认目标集群中存在源集群后缀的 BSL：

kubectl --context <target-cluster> -n velero get backupstoragelocation <storageRepository>-<sourceCluster>

BSL 应为 Available：

kubectl --context <target-cluster> -n velero describe backupstoragelocation <storageRepository>-<sourceCluster>

如果 BSL 为 Unavailable，优先检查：

  • 目标集群 Pod 网络到对象存储 endpoint 的连通性。
  • bucket、region、prefix 和地址模式。
  • Access Key / Secret Key 权限。
  • CA 或 TLS 证书。
  • Velero Pod 日志和事件。

相关文档​