Velero前身 ArkConfig 自定义资源配置完全指南云提供商与备份存储参数详解【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本文以 Velero 仓库历史文档 site/content/docs/v0.7.0/config-definition.md 为主体系统讲解 ArkVelero 的前身由 Heptio 发起用于指定云提供商与备份存储设置的Config自定义资源CRD覆盖完整 YAML 示例、全部主配置参数以及 AWS / GCP / Azure 三朵云的专用参数表。读完本文你将能够独立编写一份可用的 Ark Config 清单理解每个同步周期参数与restoreOnlyMode的实际语义并通过仓库源码了解该设计在后续版本中如何演化为BackupStorageLocation与VolumeSnapshotLocation。OverviewConfig 是 Ark 的“总配置中心”Heptio Ark 定义了自己的 Config 对象一个 Kubernetes 自定义资源用于统一指定 Ark 的备份能力与云提供商设置。与今天 Velero 的“一个 CRD 管一类配置”不同早期的 Ark 把持久卷快照提供商、备份存储提供商以及各类同步周期全部收敛进同一个Config对象中。当 Ark server 首次部署时它会一直等待你创建 Config——具体来说是一个名为default、位于heptio-ark命名空间的 Config然后才开始正常工作。这意味着 Config 是 Ark 启动的前置条件缺失它服务将无法进入可用状态。注意这里有一个隐含假设——Ark server 是以 Kubernetes Deployment 形式运行的。如果修改了defaultConfigserver 会优雅关闭gracefully shut down。待 kubelet 重新拉起 Ark server Pod 后server 才会使用更新后的配置值。也就是说Config 变更不是热加载而是通过“重启服务、重新读取”的方式生效。从源码结构可以推断这一“等待就绪”的机制与当前 Velero 中控制器等待BackupStorageLocation就绪的设计一脉相承只是当年统一由 Config 承载。Example一份完整的 Config YAML文档给出的样例Config如下可复制使用apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default persistentVolumeProvider: name: aws config: region: us-west-2 backupStorageProvider: name: aws bucket: ark config: region: us-west-2 backupSyncPeriod: 60m gcSyncPeriod: 60m scheduleSyncPeriod: 1m restoreOnlyMode: false这份清单的语义可以拆解为四层persistentVolumeProvider指定用于持久卷快照的云提供商这里是 AWSregion 为 us-west-2backupStorageProvider指定用于实际存放备份文件的对象存储AWS S3bucket 名为ark三个同步周期控制 Ark 与对象存储、Schedule 资源的交互频率restoreOnlyMode控制是否进入“只恢复”模式。Main config parameters主配置参数参考文档将主配置参数整理为下表这是 Ark Config 最核心的部分KeyTypeDefaultMeaningpersistentVolumeProviderCloudProviderConfigNone (Optional)集群中用于持久卷待快照的云提供商规格如果有。如果未指定则请求 PV 快照与恢复的 Backup / Restore 会被视为无效。NOTE对于 AzureKubernetes 集群版本需为 1.7.2才能支持对其托管磁盘managed disks做 PV 快照。persistentVolumeProvider/nameStringArk 原生支持aws、gcp、azure其他提供商可通过外部插件支持None (Optional)集群用于持久卷的云提供商名称如果有。persistentVolumeProvider/configmap[string]string见下文 AWS / GCP / Azure 专用配置或提供商文档None (Optional)传递给云提供商用于持久卷的配置键值对。backupStorageProviderCloudProviderConfigRequired Field用于实际存放备份的云提供商规格。backupStorageProvider/nameStringArk 原生支持aws、gcp、azure其他提供商可通过外部插件支持Required Field实际存放备份的云提供商名称。backupStorageProvider/bucketStringRequired Field备份上传的目标存储桶。backupStorageProvider/configmap[string]string见下文 AWS / GCP / Azure 专用配置或提供商文档None (Optional)传递给云提供商用于备份存储的配置键值对。backupSyncPeriodmetav1.Duration60m0sArk 查询对象存储的频率用于确保为已有备份文件创建了对应的 Backup 资源。gcSyncPeriodmetav1.Duration60m0sArk 查询对象存储、删除已超过 TTL 的备份文件的频率。scheduleSyncPeriodmetav1.Duration1m0sArk 检查 Schedule 资源对象、判断是否需要发起一次备份的频率。resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps]有序列表描述 Kubernetes 资源对象的恢复顺序也可用RESOURCE.GROUP格式指定。不在列表中的资源会在所有优先级资源之后恢复。restoreOnlyModeboolfalse开启 RestoreOnly 模式后备份、Schedule 以及过期备份删除功能全部关闭仅从对象存储中已有的备份文件执行恢复。几个值得展开的细节backupSyncPeriod与gcSyncPeriod的区别前者解决“对象存储里已有文件、但集群里还没有 Backup 对象”的对账问题例如直接向 S3 拷贝了备份文件、或备份文件来自其他集群后者解决“备份已过期超过 TTL、对象存储里残留文件”的清理问题。两者都以metav1.Duration类型声明格式为 Go duration如60m、1m、30s。resourcePriorities的恢复顺序语义默认顺序是先恢复命名空间再恢复 PV、PVC、Secret、ConfigMap。这在恢复依赖链上很关键——例如 Secret 和 ConfigMap 往往是许多工作负载引用的前置资源先恢复它们可以避免后续资源校验失败。RESOURCE.GROUP格式允许针对特定 API 分组精确排序。restoreOnlyMode的运维价值它提供了一种“只读”形态的 Ark——适合在灾难恢复现场、或希望完全禁止写入性操作新建备份、定时任务、删除过期备份的场景下运行。开启后 Ark 变成一个纯粹的恢复工具。AWS或其他 S3 兼容存储AWS 同时涉及备份存储与持久卷快照两侧配置。backupStorageProvider/configAWSKeyTypeDefaultMeaningregionstringRequired Field例如us-east-1。完整列表见 AWS 官方区域文档。s3ForcePathStyleboolfalse使用 Minio 之类的本地存储服务时设为true。s3Urlstring非 AWS 托管存储为Required field例如http://minio:9000。可显式指定 AWS S3 URL但 Ark 可以凭region和bucket自行生成该字段主要面向 Minio 等本地存储服务。kmsKeyIdstringEmpty例如502b409c-4da1-419f-a16e-eif453b3i49f或alias/KMS-Key-Alias-Name。指定 AWS KMS key 的 id 或别名可为 S3 中的备份开启加密。仅适用于 AWS S3且可能需要显式授予密钥使用权限。persistentVolumeProvider/config仅 AWSKeyTypeDefaultMeaningregionstringRequired Field例如us-east-1。完整列表见 AWS 官方区域文档。结合仓库中的 Minio 示例 examples/minio/00-minio-deployment.yaml 可以更直观地理解s3ForcePathStyle与s3Url的用途该示例在velero命名空间部署了 Minio 服务端口 9000并通过一个初始化 Job 用mc客户端创建了velero/velero存储桶。使用此类本地 S3 兼容存储时Config 中需要同时设置s3Url: http://minio:9000与s3ForcePathStyle: true因为本地对象存储不提供 AWS 风格的虚拟主机寻址必须用 path-style 访问。这也是文档中“Set this totrueif you are using a local storage service like Minio”的真实应用场景。GCPbackupStorageProvider/configGCP无需任何参数。GCP 的对象存储GCS通过服务账号凭据自动完成鉴权与寻址因此备份存储侧不需要额外配置项。persistentVolumeProvider/configGCPKeyTypeDefaultMeaningprojectstringRequired Field例如project-example-3jsn23。详见 Google Cloud Project ID 文档。GCP 侧唯一需要显式指定的是project——即进行磁盘快照时所属的 GCP 项目 ID。它与 GCS 桶所在的项目的映射关系需要由管理员保证一致否则快照写入会失败。AzurebackupStorageProvider/configAzure无需任何参数。与 GCP 类似Azure 的备份存储鉴权由服务主体service principal凭据完成。persistentVolumeProvider/configAzureKeyTypeDefaultMeaninglocationstringRequired Field例如Canada East。详见 Azure 可用位置列表文档中称为 Regions。apiTimeoutmetav1.Duration2m0s等待 Azure API 请求完成的超时时间。这里有两个容易踩坑的点其一location必须与目标托管磁盘所在区域一致其二apiTimeout控制的是 Azure API 调用超时默认 2 分钟——若集群网络到 Azure API 的延迟较高可能需要调大该值避免快照请求被过早判定失败。源码纵深从 Config 到 BackupStorageLocation / VolumeSnapshotLocation 的演化理解 Config 的最佳方式是看它在后续版本中如何被拆分。仓库中 v0.10.0 的文档 site/content/docs/v0.10.0/api-types/backupstoragelocation.md 明确说明BackupStorageLocationtakes the place of theConfig.backupStorageProviderkey as of v0.10.0也就是说Config中backupStorageProvider的职责在 v0.10.0 起由独立的BackupStorageLocationBSLCRD 承担而persistentVolumeProvider的职责则由VolumeSnapshotLocationVSL承担。这两个 CRD 在当前仓库中依然存在其类型定义位于pkg/apis/velero/v1/backupstoragelocation_types.goBackupStorageLocationSpec包含Provider、Configmap[string]string即原backupStorageProvider/config、ObjectStorage.Bucket即原backupStorageProvider/bucket等字段并新增了Prefix、CACert、AccessMode、ValidationFrequency等能力pkg/apis/velero/v1/volume_snapshot_location_type.goVolumeSnapshotLocationSpec同样由Provider与Config组成对应原persistentVolumeProvider的位置。对照可见v0.7.0 文档中的每一组键都能在当前 BSL / VSL 类型中找到一一对应的字段name对应providerconfig对应configbucket对应objectStorage.bucket。这种“单一 Config → 专用 CRD”的演进本质上是因为备份存储位置可能有多套多集群共享、多桶冗余单一defaultConfig 已无法表达需要独立的、可多实例化的资源对象。对今天的 Velero 用户而言配置方式变为创建BackupStorageLocation与VolumeSnapshotLocation对象但参数语义与本文表格中的解释基本一致——例如 AWS 的s3ForcePathStyle、s3Url、kmsKeyId至今仍在 BSL 的config中使用。仓库中的 CHANGELOG 也保留了这段历史的痕迹在 changelogs/CHANGELOG-0.8.md 等版本记录中可以找到从ark.heptio.comAPI 组向velero.io迁移、以及配置模型调整的相关条目site/content/docs/v0.11.0/migrating-to-velero.md 则记录了从 Ark 到 Velero 的迁移指南。实战建议与常见问题综合文档与仓库实现给出几条实践建议命名与命名空间不可随意Config 必须命名为default并置于heptio-ark命名空间当前 Velero 中对应的默认 BSL 命名空间为velero否则 server 不会进入就绪状态。改动 Config 后需要等 Pod 重启文档明确说明修改后 server 会优雅关闭、由 kubelet 重启后读取新值因此不要在修改后立刻断言配置已生效。本地区域与本地存储使用 Minio 时必须同时满足s3ForcePathStyle: true与s3Url: http://minio:9000两个条件并保证 bucket 已提前创建可参考 examples/minio/00-minio-deployment.yaml 中的初始化 Job 逻辑。AWS KMS 加密是可选增强kmsKeyId为空时备份不做 KMS 加密启用时需确认 IAM 权限中已显式授予该 KMS key 的使用权。只恢复模式适合容灾现场在仅需要从对象存储恢复数据的场景如源集群已损坏开启restoreOnlyMode: true可避免误触发新的备份与清理任务。同步周期按规模调整backupSyncPeriod与gcSyncPeriod默认 60 分钟备份文件很多时适当调大可降低对象存储 API 压力scheduleSyncPeriod默认 1 分钟决定定时备份的触发精度不需要秒级调度时保持默认即可。如果需要对照旧版v0.3.0内联 provider 写法与 v0.7.0nameconfig写法的差异仓库中还保留了 site/content/docs/v0.3.0/config-definition.md 作为历史参考而前文提到的 BSL 文档则展示了 v0.10.0 之后的新式配置范式可作为从 Ark Config 迁移到现代 Velero 配置的直接对照资料。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考