新闻详情

新闻详情

首页 / 资讯中心 / 详情

Velero 配置详解:从 Ark Config 到 BackupStorageLocation 的完整指南

发布时间:2026/9/17 3:54:59来源:尧图网络
Velero 配置详解:从 Ark Config 到 BackupStorageLocation 的完整指南
Velero 配置详解从 Ark Config 到 BackupStorageLocation 的完整指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本指南以 Velero曾用名 Heptio Ark早期版本的Config自定义资源为核心系统讲解备份存储与持久化卷快照的云提供商配置方式包括defaultConfig 的启动约定、完整 YAML 示例、全部主配置参数以及 AWS / GCP / Azure 三大云厂商的专属配置项。同时结合当前仓库源码梳理Config如何演进为今天仍在使用的BackupStorageLocationBSL与VolumeSnapshotLocationVSLCRD帮助读者理解参数背后的实现原理并能够迁移到现代配置写法。背景Ark 时代的统一 Config 自定义资源在 Heptio ArkVelero 的前身阶段项目通过一个名为Config的**自定义资源Custom Resource**来集中描述两类设置备份与恢复相关的全局行为同步周期、资源恢复顺序、只读模式等云提供商的接入设置持久化卷快照persistent volume snapshot所用的云提供商以及备份文件实际存储所用的对象存储。一个关键约定是Ark server 首次部署后会一直等待你创建名为default的 Config并且必须位于heptio-ark命名空间中之后服务才会真正开始工作。这一默认位置 固定命名的设计后来被继承到BackupStorageLocation与VolumeSnapshotLocation中详见下文演进章节。注意该设计假设 Ark server 以 Kubernetes Deployment 形式运行。一旦defaultConfig 被修改Ark server 会优雅关闭kubelet 重启 Ark server Pod 后服务端才会使用更新后的配置值。因此修改 Config 后通常需要等待 Pod 自动重启以生效。完整示例一个典型的 Config YAML原文档给出的示例含 AWS 持久化卷快照 AWS S3 备份存储如下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持久化卷快照服务使用 AWS区域us-west-2backupStorageProvider备份文件存储服务使用 AWS S3桶名ark区域us-west-2两者都可以是不同的提供商例如你可以用 AWS 做 PV 快照同时把备份文件存到 GCP 的 GCS 中——它们各自拥有独立的name与config段。主配置参数参考以下表格完整列出Config的主配置参数默认值、类型与语义均以原文档为准KeyTypeDefaultMeaningpersistentVolumeProviderCloudProviderConfig无可选集群持久化卷需要被快照所使用的云提供商规格如不指定则请求 PV 快照的 Backup、请求 PV 恢复的 Restore 都会被判定为无效。注意Azure 集群需要 Kubernetes 1.7.2 才能对其托管磁盘做 PV 快照。persistentVolumeProvider/nameStringArk 原生支持aws、gcp、azure其他提供商可通过外部插件提供无可选集群持久化卷所使用的云提供商名称。persistentVolumeProvider/configmap[string]string参见 AWS / GCP / Azure 专属配置无可选传递给云提供商用于持久化卷的配置键值对。backupStorageProviderCloudProviderConfig必填实际存储备份文件的云提供商规格。backupStorageProvider/nameString同上原生支持aws、gcp、azure必填实际存储备份文件的云提供商名称。backupStorageProvider/bucketString必填备份文件上传到的存储桶。backupStorageProvider/configmap[string]string参见各云专属配置无可选传递给云提供商用于备份存储的配置键值对。backupSyncPeriodmetav1.Duration60m0sArk 查询对象存储、为已有备份文件创建对应 Backup 资源的频率。gcSyncPeriodmetav1.Duration60m0sArk 查询对象存储、删除已超过 TTL 的备份文件的频率。scheduleSyncPeriodmetav1.Duration1m0sArk 检查 Schedule 资源对象、判断是否需要发起备份的频率。resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps]有序列表描述恢复 Kubernetes 资源对象的先后顺序也支持RESOURCE.GROUP格式。不在列表中的资源将在所有优先级资源之后被恢复。restoreOnlyModeboolfalse开启 RestoreOnly 模式后备份、Schedule 以及过期备份删除功能全部关闭仅可从对象存储中的已有备份文件执行恢复。其中与同步相关的三个周期参数有明确分工backupSyncPeriod负责把对象存储里已有的备份元数据同步为 Backup CRgcSyncPeriod负责清理过期备份文件scheduleSyncPeriod负责按 Schedule 定时触发新备份。三者独立配置可根据运维节奏分别调整。restoreOnlyMode 的现代实现restoreOnlyMode在服务端对应--restore-only启动标志。当前仓库中该标志在 pkg/cmd/server/config/config.go 中定义并明确标注DEPRECATED将在 v2.0 移除官方推荐改用只读ReadOnly的备份存储位置服务端在 pkg/cmd/server/server.go 中根据该配置决定是否关闭备份、Schedule 与垃圾回收相关控制器。现代等价写法见 main 版 BackupStorageLocation 文档BSL 的accessMode字段可取值ReadWrite/ReadOnly配以backupSyncPeriod与validationFrequency等字段即可实现更细粒度的只读灾备站点效果而不必关闭整个服务端的备份能力。云提供商专属配置AWS以及其他 S3 兼容存储backupStorageProvider/configKeyTypeDefaultMeaningregionstring必填示例us-east-1。完整区域列表参见 AWS 官方文档。s3ForcePathStyleboolfalse使用 Minio 等本地存储服务时设为true。s3Urlstring非 AWS 托管存储必填示例http://minio:9000。AWS S3 的 URL 可由region与bucket自动生成此字段主要用于 Minio 等本地存储服务。kmsKeyIdstring空示例502b409c-4da1-419f-a16e-eif453b3i49f或alias/KMS-Key-Alias-Name。指定 AWS KMS 密钥 ID 或别名可为 S3 中的备份启用加密仅适用于 AWS S3且可能需要显式授予密钥使用权限。这三个参数的实战要点s3ForcePathStyletrue是接入 Minio 类服务的成败关键。它决定 AWS SDK 使用哪种地址风格访问对象存储false默认时使用 virtual-host 风格而 MinIO 服务器默认只支持 path-style 地址。若设置不当可能出现能上传但不能下载的典型故障仓库 Minio 集成文档 对此有专门说明。s3Url用于非 AWS 托管存储自建对象存储、其他云厂商的 S3 兼容服务都需要显式指定端点。例如腾讯云 COS 场景配置为regionap-guangzhou,s3ForcePathStyletrue,s3Urlhttps://cos.ap-guangzhou.myqcloud.com见 腾讯云配置文档IBM Cloud 对象存储则需额外配合checksumAlgorithm见 IBM 配置文档。kmsKeyId只对真正的 AWS S3 生效用于服务端加密备份数据配置后需保证运行 Ark 的 IAM 角色具备使用该 KMS 密钥的权限。persistentVolumeProvider/config仅 AWSKeyTypeDefaultMeaningregionstring必填示例us-east-1完整区域列表参见 AWS 官方文档。AWS 的 PV 快照提供商只需要region——快照将基于该区域的 EBS 能力创建。GCPbackupStorageProvider/config无必需参数Bucket 信息已在backupStorageProvider/bucket指定凭据通过云厂商默认链路或环境提供。persistentVolumeProvider/config无必需参数。AzurebackupStorageProvider/config无必需参数。persistentVolumeProvider/configKeyTypeDefaultMeaningapiTimeoutmetav1.Duration2m0sAzure API 请求完成前的最长等待时间超时即中止。Azure 场景下apiTimeout用于约束对 Azure 管理 API 的调用超时避免 Azure 侧偶发慢请求拖垮备份/恢复流程同时请牢记前文提到的Azure 托管磁盘 PV 快照要求 Kubernetes 1.7.2这一前置条件。从 Config 到 BackupStorageLocation 的演进在 v0.10.0 起Config.backupStorageProvider被独立的BackupStorageLocationBSLCRD取代v0.10.0 文档明确说明BackupStorageLocation takes the place of the Config.backupStorageProvider key随后persistentVolumeProvider也演进为VolumeSnapshotLocationVSLCRD。这种拆分让存储位置成为一种可多实例化的命名资源支持多个备份存储位置并存。对应地Ark 时代的单一大 Config 被彻底拆解这一点可以从当前仓库的类型定义中清晰印证backupstoragelocation_types.go 中的BackupStorageLocationSpec定义了Provider、Config、Credential、ObjectStorage含Bucket/Prefix/CACert/CACertRef、AccessMode、BackupSyncPeriod、ValidationFrequency等字段volume_snapshot_location_type.go 中的VolumeSnapshotLocationSpec则只包含Provider、Config与Credential用于快照能力的位置定义Backup 资源通过StorageLocation字段见 backup_types.go指定要写入哪个 BSL。现代 BSL 配置写法以当前 main 版本文档backupstoragelocation.md为准一个最小可用的 BSL 示例如下apiVersion: velero.io/v1 kind: BackupStorageLocation metadata: name: default namespace: velero spec: backupSyncPeriod: 2m0s provider: aws objectStorage: bucket: myBucket credential: name: secret-name key: key-in-secret config: region: us-west-2 profile: default与旧 Config 的对应关系Ark Configv0.8.1Velero BackupStorageLocationmainbackupStorageProvider/namespec.providerbackupStorageProvider/bucketspec.objectStorage.bucketbackupStorageProvider/configspec.configbackupSyncPeriodspec.backupSyncPeriodBSL 级覆盖无spec.objectStorage.prefix、spec.credential、spec.accessMode、spec.validationFrequency、spec.objectStorage.caCertRef等现代 BSL 还新增了几类旧 Config 没有的能力prefix在桶内指定子目录存储备份便于多环境共用一个桶credential按位置引用SecretKeySelector实现不同存储位置使用不同凭据client 配置 中对应的云凭据解析链路accessModeReadWrite/ReadOnly用于灾备只读站点替代被废弃的restoreOnlyModecaCert/caCertRef为自签名证书的对象存储注入 CA 证书其中caCertRef引用同命名空间的 Secret 为推荐方式且二者不可同时设置类型定义中的Validate()方法对此有校验见 backupstoragelocation_types.govalidationFrequency控制对对象存储连通性的定期校验。多存储位置与默认位置与旧版只能有一个defaultConfig不同现代 Velero 支持同时配置多个 BSL服务端通过--default-backup-storage-location指定默认位置默认名为default未显式指定storageLocation的 Backup 会写入该默认位置。多 BSL 场景下backupSyncPeriod、validationFrequency等同步行为也可以按位置独立设置这比早期统一 Config 的全局单例模型灵活得多。从源码看同步周期与恢复顺序的实现backupSyncPeriod、gcSyncPeriod、scheduleSyncPeriod三个周期在源码中分别驱动三条独立的控制循环备份同步backup sync controller 定期从对象存储列出备份文件将缺失的备份以 Backup CR 形式补齐对应backupSyncPeriod过期清理gc controller 定期查询对象存储删除已超过保留期TTL的备份文件对应gcSyncPeriod调度触发schedule controller 按 Schedule 资源计算下一次执行时间并触发备份创建对应scheduleSyncPeriod。三个周期各自独立在resourcePriorities之外共同构成了 Ark 服务端最基础的周期任务骨架。而resourcePriorities则是一个纯恢复侧配置它决定了恢复流程中资源对象的处理顺序默认把命名空间、PV、PVC、Secret、ConfigMap 放在最前——这也与 Kubernetes 中先建命名空间、再建依赖它的资源的依赖关系相吻合未列出的资源统一在优先级列表之后恢复。总结Config是 Ark 时代唯一且必填的全局配置入口通过persistentVolumeProvider与backupStorageProvider分别声明快照与备份存储辅以三个同步周期和restoreOnlyMode控制服务端行为。理解这套参数模型的价值在于迁移友好backupStorageProvider的参数几乎 1:1 映射到现代BackupStorageLocation的provider/objectStorage.bucket/config存量配置可平滑平移排障前提AWS 的s3ForcePathStyle、s3Url以及 Azure 的apiTimeout等参数至今仍是接入各对象存储时的常见坑点理解其语义可快速定位上传/下载异常模式升级restoreOnlyMode的废弃标志着 Velero 从全局开关走向按存储位置控制访问模式的更细粒度设计这也是学习 BSL / VSL 模型最好的切入点。如需进一步阅读可深入仓库中的 v0.10.0 BackupStorageLocation API 文档、main 版 BSL 文档 与 Minio 集成指南并结合 BSL 类型定义 与 VSL 类型定义 对照学习。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
网站建设高端定制企业官网
RELATED

相关资讯

更多精彩内容,欢迎继续阅读

较早相关资讯

最新相关资讯

Optimism op-node batch_decoder:从 L1 批次交易中还原 Channel 的离线调试工具 2026/9/17 4:37:06

Optimism op-node batch_decoder:从 L1 批次交易中还原 Channel 的离线调试工具

Optimism op-node batch_decoder:从 L1 批次交易中还原 Channel 的离线调试工具 【免费下载链接】optimism Optimism is Ethereum, scaled. 项目地址: https://gitcode.com/GitHub_Trending/op/optimism batch_decoder 是 Optimism monorepo 中 op-node 自带…

阅读更多 →
微客公寓V1.0.13:微信租房小程序源码拆解与二次开发指南 2026/9/17 4:37:06

微客公寓V1.0.13:微信租房小程序源码拆解与二次开发指南

简介:面向公寓出租行业开发者的微信小程序模板源码,专为快速搭建租房信息发布、查询、预订与在线管理平台设计。这份V1.0.13开源版包含完整源码,并在架构中体现性能优化、功能增强与问题修复后的项目结构;资源包为zip格式&#xf…

阅读更多 →
基于SSM+Flask双后端架构的房源管理系统设计与实现 2026/9/17 4:37:06

基于SSM+Flask双后端架构的房源管理系统设计与实现

做房源管理系统这个东西,说实话,市面上能找到的成品大多是单后端架构——要么纯Java要么纯Python,能跑通但扩展性一言难尽。这次我做的这套“基于JavaSSMFlask的房源管理系统”,采用的是前后端分离加双后端混合架构,把…

阅读更多 →
Java GC优化实战:从日志分析到代码重构的完整闭环 2026/9/17 4:37:06

Java GC优化实战:从日志分析到代码重构的完整闭环

1. GC优化不是调几个参数就完事:它本质是一场内存资源的精准调度战“GC优化”这四个字,被太多人当成一句万能咒语——项目一卡,日志里扫到几行Full GC,立刻打开JVM参数文档,把-XX:UseG1GC、-Xmx4g、-XX:MaxGCPauseMill…

阅读更多 →
QT+C++车牌识别系统:视觉处理、业务闭环与MySQL集成 2026/9/17 4:37:06

QT+C++车牌识别系统:视觉处理、业务闭环与MySQL集成

简介:本资源是一套基于QtCMySQLOpenCV实现的高分毕业设计级车牌识别停车场管理系统,面向计算机、人工智能、自动化等专业学生及初/中级开发者,解决智能停车场景下的车辆进出管理、车牌图像采集、识别与数据库持久化等核心问题,适用…

阅读更多 →
Munder Difflin v0.3.3 → v0.3.7 发布深度解析:语音编排、Git 时间机器与自更新修复的六周实录 2026/9/17 4:34:05

Munder Difflin v0.3.3 → v0.3.7 发布深度解析:语音编排、Git 时间机器与自更新修复的六周实录

Munder Difflin v0.3.3 → v0.3.7 发布深度解析:语音编排、Git 时间机器与自更新修复的六周实录 【免费下载链接】munder-difflin A local multi-agent harness that works with your existing Claude Code, Codex subscriptions, allows you to run an office of a…

阅读更多 →

今日资讯

本周资讯

本月资讯

看完文章仍有疑问?

联系尧图顾问,获取一对一建站咨询

立即免费咨询 📞 400-888-8888
📞