Velero 集群级 Config 配置定义详解持久卷快照、备份存储与同步参数实战指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Heptio ArkVelero 前身的 v0.9.0 配置定义文档为主体系统讲解 Velero 集群级Config自定义资源的完整配置方法从defaultConfig 的创建时机、persistentVolumeProvider与backupStorageProvider两大核心段落的配置到backupSyncPeriod、gcSyncPeriod、scheduleSyncPeriod、resourcePriorities、restoreOnlyMode等关键参数再到 AWS、GCP、Azure 三家云厂商的专属配置项。读完本文你将能够独立编写一份可落地的 Velero 服务端配置文件并理解每个参数在源码层面的实际作用。Velero 在部署完成后并不会立刻开始工作它首先要等待管理员提供一个名为default的Config自定义资源Custom ResourceCR。这份文件同时承载了「持久卷快照提供方」和「备份存储提供方」两方面的云厂商信息是整个备份/恢复链路的第一道配置入口。本文基于仓库中的 config-definition.md 展开并结合现代 Velero 的 API 类型定义与控制器源码进行印证。Config 对象Ark 自定义资源配置概述Heptio Ark后更名为 Velero通过一个自定义资源对象——Config——来集中描述 Ark 的备份能力与云提供商设置。该对象的特殊性在于它是一个命名固定的对象必须命名为default它位于固定的命名空间heptio-ark它由Ark 服务端在首次启动后等待只有当defaultConfig 被创建Ark server 才真正进入可用状态。注意这一机制基于一个隐含假设——Ark server 以 Kubernetes Deployment 形式运行。如果defaultConfig 被修改Ark server 会优雅关闭gracefully shut down当 kubelet 重启 Ark server Pod 后服务端才会使用更新后的配置值。因此修改 Config 后无需手动删除 Pod等待自动重启即可生效。从源码演进的角度看Config对象的设计理念在现代 Velero 中已被拆分为两类更细粒度的资源备份存储相关字段对应BackupStorageLocation缩写bsl持久卷快照相关字段对应VolumeSnapshotLocation。以仓库中的 backupstoragelocation_types.go 为例BackupStorageLocationSpec定义了Provider存储提供方、Config厂商专属配置键值对、Bucket对象存储桶位于ObjectStorageLocation内、BackupSyncPeriod从对象存储同步备份对象的时间间隔设为 0 可禁用等字段。理解了这一演进关系再回头读 v0.9.0 的Config文档就非常直观文档中的backupStorageProvider段落就是后来独立成BackupStorageLocation的前身。完整的 Config 配置示例以下 YAML 是 v0.9.0 文档给出的标准Config样例它同时配置了 AWS 作为持久卷快照提供方和备份存储提供方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逐段解读这份配置字段本例取值作用persistentVolumeProvidername: awsregion: us-west-2声明集群使用的持久卷云厂商为 AWS快照创建在us-west-2区域backupStorageProvidername: awsbucket: arkregion: us-west-2声明备份数据上传到 AWS S3 的ark桶区域为us-west-2backupSyncPeriod60m每 60 分钟从对象存储同步一次备份清单gcSyncPeriod60m每 60 分钟执行一次过期备份文件清理scheduleSyncPeriod1m每 1 分钟检查一次 Schedule 资源判断是否需要发起备份restoreOnlyModefalse关闭「仅恢复」模式正常启用备份、调度与 GC 功能主配置参数参考文档将主配置参数整理为下表这是编写任何一份Config都必须对照的核心参数表KeyTypeDefaultMeaningpersistentVolumeProviderCloudProviderConfigNone (Optional)集群持久卷需要做快照所使用的云厂商规格。如果未指定则请求 PV 快照的备份、请求 PV 恢复的恢复操作都会被判定为无效。注意对于 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详见下文各厂商专属配置。None (Optional)传递给云厂商的备份存储专属配置键值对。backupSyncPeriodmetav1.Duration60m0sArk 查询对象存储的频率用于确保「已存在的备份文件」都能对应生成相应的 Backup 资源。gcSyncPeriodmetav1.Duration60m0sArk 查询对象存储、删除已超过 TTL 的备份文件的频率。scheduleSyncPeriodmetav1.Duration1m0sArk 检查 Schedule 资源、判断是否需要发起一次备份的频率。resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps, serviceaccounts, limitranges]描述 Kubernetes 资源对象恢复顺序的有序列表同样支持RESOURCE.GROUP格式。如果某资源不在该列表中它会在所有优先级资源之后恢复。restoreOnlyModeboolfalse开启后备份、调度以及过期备份删除功能全部关闭只能基于对象存储中已有的备份文件执行恢复。同步周期类参数从文档到源码backupSyncPeriod、gcSyncPeriod、scheduleSyncPeriod三个参数决定了服务端三个后台循环的节奏在源码中均有对应实现backupSyncPeriod文档默认60m。现代 Velero 中该值既可以在 Configv0.9.0 时代中声明也可以在BackupStorageLocation.Spec.BackupSyncPeriod中按存储位置单独指定设为0可禁用。服务端还提供全局默认值在 config.go 中defaultBackupSyncPeriod time.Minute当前版本默认 1 分钟。实际的同步循环在 backup_sync_controller.go 中执行syncPeriod优先取存储位置的Spec.BackupSyncPeriod未设置时回退到全局默认值。同步控制器的作用与文档描述一致——确保对象存储中已有的备份文件都能以 Backup API 对象的形式出现在集群内。gcSyncPeriod文档默认60m。它控制 GC垃圾回收控制器扫描对象存储的频率用于删除超过 TTL 的备份文件。在restoreOnlyMode开启时该功能会被关闭。scheduleSyncPeriod文档默认1m。现代实现中schedule_controller.go 定义了scheduleSyncPeriod time.Minute并通过kube.NewPeriodicalEnqueueSource周期性地将 Schedule 列表重新入队从而以固定间隔检查「某个调度计划现在是否该触发备份」。从源码结构看v0.9.0 文档把这三个周期参数放在集群级Config上而后来的版本逐步将它们下沉或拆分如BackupSyncPeriod下沉到BackupStorageLocation、ScheduleSyncPeriod由调度控制器内建但「周期性同步、周期性 GC、周期性查表」的三大循环机制延续至今。restoreOnlyMode只读灾备场景的利器restoreOnlyMode: true的典型使用场景是灾备恢复期在恢复过程中管理员不希望任何新的备份、调度或过期删除动作干扰现场。该模式下备份功能关闭调度功能关闭过期备份删除GC关闭恢复操作仍然可用且数据来源是对象存储中已存在的备份文件。仓库 v0.9.0 文档中的 use-cases.md 明确记录了该用法在迁移/恢复场景第 3 步将 Ark server 的 Config 中restoreOnlyMode设为true防止恢复过程中产生或删除 Backup 对象。现代 Velero 中该能力被--restore-only服务端启动参数继承见 config.go同时官方也推荐使用只读的备份存储位置accessMode: ReadOnly作为更细粒度的替代方案。resourcePriorities恢复顺序控制resourcePriorities是 v0.9.0 文档中的关键恢复参数它用有序列表描述资源恢复顺序默认顺序为namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps, serviceaccounts, limitranges设计意图很明确先恢复命名空间一切资源的容器再恢复持久卷数据底座然后是持久卷声明接着是密钥、配置映射、服务账号、限额范围等支撑性资源最后才轮到依赖它们的工作负载。资源条目支持RESOURCE.GROUP格式如deployments.apps不在列表中的资源会排在所有优先级资源之后统一恢复。这一顺序控制思想在现代 Velero 中演化为--restore-resource-priorities启动参数config.go并支持使用-元素将资源分为高优先级段与低优先级段未列出的资源则按字母序在两者之间恢复。AWS及其他 S3 兼容存储专属配置AWS 段落同时适用于 AWS S3 与各类 S3 兼容的对象存储如 Minio是自建存储环境最常用的一段配置。backupStorageProvider/configAWSKeyTypeDefaultMeaningregionstringEmpty示例us-east-1。完整列表参见 AWS 官方区域文档。未提供时将从 AWS S3 API 自动查询。s3ForcePathStyleboolfalse使用本地存储服务如 Minio时必须设为true。s3Urlstring非 AWS 托管的存储为必填字段示例http://minio:9000。也可显式指定 AWS S3 URL但 Ark 本身可以从region和bucket推导出来该字段主要服务于 Minio 这类本地存储服务。kmsKeyIdstringEmpty示例502b409c-4da1-419f-a16e-eif453b3i49f或alias/KMS-Key-Alias-Name。指定 AWS KMS 密钥 ID 或别名可为 S3 中的备份启用加密。仅适用于 AWS S3且可能需要显式授予密钥使用权限。Minio 场景实操仓库提供了完整的 Minio 部署示例 00-minio-deployment.yaml配合上述参数一份面向 Minio 的备份存储配置大致为backupStorageProvider: name: aws bucket: ark config: region: minio s3ForcePathStyle: true s3Url: http://minio:9000要点是s3ForcePathStyle: true让客户端采用路径风格path-style寻址Minio 这类本地服务不支持虚拟主机风格s3Url指向 Minio 服务地址region填一个占位区域即可例如minio。persistentVolumeProvider/configAWS OnlyKeyTypeDefaultMeaningregionstringRequired Field必填示例us-east-1。完整列表参见 AWS 官方区域文档。与备份存储不同持久卷快照的 region 是必填项因为创建 EC2 EBS 快照必须明确区域。AWS 上的持久卷快照底层依赖 EC2 APIec2:CreateSnapshot、ec2:DeleteSnapshot、ec2:DescribeVolumes等权限这与仓库 v0.9.0 文档 aws-config.md 中要求的 IAM 策略完全对应。GCP 专属配置GCP 段落极其简洁无论是backupStorageProvider/config还是persistentVolumeProvider/config都不需要任何必填参数。配置段必填参数说明backupStorageProvider/config无使用 GCS 时无需额外配置。persistentVolumeProvider/config无使用 GCE 持久磁盘快照时无需额外配置。GCP 场景下只需要在backupStorageProvider中指定name: gcp与bucketGCS 桶名。凭证与服务账号的准备工作见仓库文档 gcp-config.md其中要求服务账号具备compute.disks.createSnapshot、compute.snapshots.create/delete、gsutil iam ch ...:objectAdmin等权限即 GCP 侧的权限模型完全由服务账号承担而非写入Config。Azure 专属配置Azure 段落同样大部分无需参数唯一的例外是持久卷提供方的超时配置persistentVolumeProvider/configAzureKeyTypeDefaultMeaningapiTimeoutmetav1.Duration2m0sAzure API 请求在超时之前允许的最大等待时间。前置条件提醒使用 Azure 托管磁盘快照要求 Kubernetes 集群版本1.7.2见主参数表注释。仓库 v0.9.0 文档 azure-config.md 给出了一个完整可用的 AzureConfig示例apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default persistentVolumeProvider: name: azure config: apiTimeout: 15m backupStorageProvider: name: azure bucket: ark backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false其中apiTimeout: 15m是对默认2m的放大——当 Azure 侧 API 响应偏慢时适当增大该值可避免快照操作过早失败。需要注意的是Azure 的凭证并非写在Config中而是通过包含AZURE_SUBSCRIPTION_ID、AZURE_TENANT_ID、AZURE_RESOURCE_GROUP、AZURE_CLIENT_ID、AZURE_CLIENT_SECRET、AZURE_STORAGE_ACCOUNT_ID、AZURE_STORAGE_KEY七个环境变量的 Secret 注入见 azure-config.md其中AZURE_RESOURCE_GROUP必须指向集群磁盘所在的第二个资源组。从 Config 到实际部署完整落地流程结合仓库的部署文档一份Config从编写到生效的完整流程为准备对象存储桶在目标云厂商创建备份存储桶AWS S3 桶、GCS 桶或 Azure blob container。准备凭证创建云厂商凭证文件或服务主体并通过 Secret 注入集群。以 AWS 为例aws-config.mdkubectl create secret generic cloud-credentials \ --namespace ARK_NAMESPACE \ --from-file cloudcredentials-ark编写 Config按照本文的参数表在metadata.namespace: heptio-ark、metadata.name: default下配置两个 provider 段落与周期参数。先装前置资源再下发 Config先应用命名空间、RBAC 等前置资源如 v0.9.0 文档中的kubectl apply -f examples/common/00-prereqs.yaml再应用 Config 文件。启动 Ark server下发 Deployment如kubectl apply -f examples/aws/10-deployment.yaml。服务端启动后会等待defaultConfig 出现并读取。验证方式通过kubectl get config -n heptio-ark确认default对象存在若后续需要调整配置直接kubectl edit修改 ConfigArk server 会自动优雅重启并加载新值。常见问题与排查要点Config 修改后不生效检查 Ark server Pod 是否已由 kubelet 自动重启。按 v0.9.0 文档机制server 检测到 Config 变化会优雅关闭重启后读取新值若 Pod 长期未重启可排查 kubelet 与 Deployment 状态。PV 快照被判定为无效确认persistentVolumeProvider已配置未配置时请求 PV 快照的备份会被视为无效见主参数表。Azure 场景请额外确认集群版本 ≥ 1.7.2。本地存储Minio无法上传检查backupStorageProvider/config是否设置了s3ForcePathStyle: true与正确的s3Urlregion未提供时 Ark 会查询 S3 API本地存储通常需要显式给出占位 region。备份存储 region 校验失败AWSbackupStorageProvider的region为空时依赖 S3 API 自动查询aws-config.md网络受限或使用自定义 endpoint 时建议显式指定。恢复时资源顺序异常核对resourcePriorities列表是否包含namespaces、persistentvolumes、persistentvolumeclaims等关键资源未列入的资源会被延后恢复。总结Config对象是 Ark/Velero 服务端的第一道配置闸门persistentVolumeProvider决定快照能力backupStorageProvider决定备份存放位置三个周期参数决定服务端的后台节奏resourcePriorities决定恢复顺序restoreOnlyMode则提供灾备场景的只读保护。在 v0.9.0 的配置体系中AWS 是配置项最丰富的厂商支持 region、S3 兼容端点、KMS 加密GCP 几乎零配置Azure 仅有apiTimeout一个必知参数。理解这份配置的语义不仅能正确部署 v0.9.0 时代的 Ark也能顺畅迁移到现代 Velero 的BackupStorageLocationVolumeSnapshotLocation配置模型因为后者的字段语义正是从前者拆分演进而来。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Velero 集群级 Config 配置定义详解：持久卷快照、备份存储与同步参数实战指南
Velero 集群级 Config 配置定义详解持久卷快照、备份存储与同步参数实战指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文以 Heptio ArkVelero 前身的 v0.9.0 配置定义文档为主体系统讲解 Velero 集群级Config自定义资源的完整配置方法从defaultConfig 的创建时机、persistentVolumeProvider与backupStorageProvider两大核心段落的配置到backupSyncPeriod、gcSyncPeriod、scheduleSyncPeriod、resourcePriorities、restoreOnlyMode等关键参数再到 AWS、GCP、Azure 三家云厂商的专属配置项。读完本文你将能够独立编写一份可落地的 Velero 服务端配置文件并理解每个参数在源码层面的实际作用。Velero 在部署完成后并不会立刻开始工作它首先要等待管理员提供一个名为default的Config自定义资源Custom ResourceCR。这份文件同时承载了「持久卷快照提供方」和「备份存储提供方」两方面的云厂商信息是整个备份/恢复链路的第一道配置入口。本文基于仓库中的 config-definition.md 展开并结合现代 Velero 的 API 类型定义与控制器源码进行印证。Config 对象Ark 自定义资源配置概述Heptio Ark后更名为 Velero通过一个自定义资源对象——Config——来集中描述 Ark 的备份能力与云提供商设置。该对象的特殊性在于它是一个命名固定的对象必须命名为default它位于固定的命名空间heptio-ark它由Ark 服务端在首次启动后等待只有当defaultConfig 被创建Ark server 才真正进入可用状态。注意这一机制基于一个隐含假设——Ark server 以 Kubernetes Deployment 形式运行。如果defaultConfig 被修改Ark server 会优雅关闭gracefully shut down当 kubelet 重启 Ark server Pod 后服务端才会使用更新后的配置值。因此修改 Config 后无需手动删除 Pod等待自动重启即可生效。从源码演进的角度看Config对象的设计理念在现代 Velero 中已被拆分为两类更细粒度的资源备份存储相关字段对应BackupStorageLocation缩写bsl持久卷快照相关字段对应VolumeSnapshotLocation。以仓库中的 backupstoragelocation_types.go 为例BackupStorageLocationSpec定义了Provider存储提供方、Config厂商专属配置键值对、Bucket对象存储桶位于ObjectStorageLocation内、BackupSyncPeriod从对象存储同步备份对象的时间间隔设为 0 可禁用等字段。理解了这一演进关系再回头读 v0.9.0 的Config文档就非常直观文档中的backupStorageProvider段落就是后来独立成BackupStorageLocation的前身。完整的 Config 配置示例以下 YAML 是 v0.9.0 文档给出的标准Config样例它同时配置了 AWS 作为持久卷快照提供方和备份存储提供方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逐段解读这份配置字段本例取值作用persistentVolumeProvidername: awsregion: us-west-2声明集群使用的持久卷云厂商为 AWS快照创建在us-west-2区域backupStorageProvidername: awsbucket: arkregion: us-west-2声明备份数据上传到 AWS S3 的ark桶区域为us-west-2backupSyncPeriod60m每 60 分钟从对象存储同步一次备份清单gcSyncPeriod60m每 60 分钟执行一次过期备份文件清理scheduleSyncPeriod1m每 1 分钟检查一次 Schedule 资源判断是否需要发起备份restoreOnlyModefalse关闭「仅恢复」模式正常启用备份、调度与 GC 功能主配置参数参考文档将主配置参数整理为下表这是编写任何一份Config都必须对照的核心参数表KeyTypeDefaultMeaningpersistentVolumeProviderCloudProviderConfigNone (Optional)集群持久卷需要做快照所使用的云厂商规格。如果未指定则请求 PV 快照的备份、请求 PV 恢复的恢复操作都会被判定为无效。注意对于 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详见下文各厂商专属配置。None (Optional)传递给云厂商的备份存储专属配置键值对。backupSyncPeriodmetav1.Duration60m0sArk 查询对象存储的频率用于确保「已存在的备份文件」都能对应生成相应的 Backup 资源。gcSyncPeriodmetav1.Duration60m0sArk 查询对象存储、删除已超过 TTL 的备份文件的频率。scheduleSyncPeriodmetav1.Duration1m0sArk 检查 Schedule 资源、判断是否需要发起一次备份的频率。resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps, serviceaccounts, limitranges]描述 Kubernetes 资源对象恢复顺序的有序列表同样支持RESOURCE.GROUP格式。如果某资源不在该列表中它会在所有优先级资源之后恢复。restoreOnlyModeboolfalse开启后备份、调度以及过期备份删除功能全部关闭只能基于对象存储中已有的备份文件执行恢复。同步周期类参数从文档到源码backupSyncPeriod、gcSyncPeriod、scheduleSyncPeriod三个参数决定了服务端三个后台循环的节奏在源码中均有对应实现backupSyncPeriod文档默认60m。现代 Velero 中该值既可以在 Configv0.9.0 时代中声明也可以在BackupStorageLocation.Spec.BackupSyncPeriod中按存储位置单独指定设为0可禁用。服务端还提供全局默认值在 config.go 中defaultBackupSyncPeriod time.Minute当前版本默认 1 分钟。实际的同步循环在 backup_sync_controller.go 中执行syncPeriod优先取存储位置的Spec.BackupSyncPeriod未设置时回退到全局默认值。同步控制器的作用与文档描述一致——确保对象存储中已有的备份文件都能以 Backup API 对象的形式出现在集群内。gcSyncPeriod文档默认60m。它控制 GC垃圾回收控制器扫描对象存储的频率用于删除超过 TTL 的备份文件。在restoreOnlyMode开启时该功能会被关闭。scheduleSyncPeriod文档默认1m。现代实现中schedule_controller.go 定义了scheduleSyncPeriod time.Minute并通过kube.NewPeriodicalEnqueueSource周期性地将 Schedule 列表重新入队从而以固定间隔检查「某个调度计划现在是否该触发备份」。从源码结构看v0.9.0 文档把这三个周期参数放在集群级Config上而后来的版本逐步将它们下沉或拆分如BackupSyncPeriod下沉到BackupStorageLocation、ScheduleSyncPeriod由调度控制器内建但「周期性同步、周期性 GC、周期性查表」的三大循环机制延续至今。restoreOnlyMode只读灾备场景的利器restoreOnlyMode: true的典型使用场景是灾备恢复期在恢复过程中管理员不希望任何新的备份、调度或过期删除动作干扰现场。该模式下备份功能关闭调度功能关闭过期备份删除GC关闭恢复操作仍然可用且数据来源是对象存储中已存在的备份文件。仓库 v0.9.0 文档中的 use-cases.md 明确记录了该用法在迁移/恢复场景第 3 步将 Ark server 的 Config 中restoreOnlyMode设为true防止恢复过程中产生或删除 Backup 对象。现代 Velero 中该能力被--restore-only服务端启动参数继承见 config.go同时官方也推荐使用只读的备份存储位置accessMode: ReadOnly作为更细粒度的替代方案。resourcePriorities恢复顺序控制resourcePriorities是 v0.9.0 文档中的关键恢复参数它用有序列表描述资源恢复顺序默认顺序为namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps, serviceaccounts, limitranges设计意图很明确先恢复命名空间一切资源的容器再恢复持久卷数据底座然后是持久卷声明接着是密钥、配置映射、服务账号、限额范围等支撑性资源最后才轮到依赖它们的工作负载。资源条目支持RESOURCE.GROUP格式如deployments.apps不在列表中的资源会排在所有优先级资源之后统一恢复。这一顺序控制思想在现代 Velero 中演化为--restore-resource-priorities启动参数config.go并支持使用-元素将资源分为高优先级段与低优先级段未列出的资源则按字母序在两者之间恢复。AWS及其他 S3 兼容存储专属配置AWS 段落同时适用于 AWS S3 与各类 S3 兼容的对象存储如 Minio是自建存储环境最常用的一段配置。backupStorageProvider/configAWSKeyTypeDefaultMeaningregionstringEmpty示例us-east-1。完整列表参见 AWS 官方区域文档。未提供时将从 AWS S3 API 自动查询。s3ForcePathStyleboolfalse使用本地存储服务如 Minio时必须设为true。s3Urlstring非 AWS 托管的存储为必填字段示例http://minio:9000。也可显式指定 AWS S3 URL但 Ark 本身可以从region和bucket推导出来该字段主要服务于 Minio 这类本地存储服务。kmsKeyIdstringEmpty示例502b409c-4da1-419f-a16e-eif453b3i49f或alias/KMS-Key-Alias-Name。指定 AWS KMS 密钥 ID 或别名可为 S3 中的备份启用加密。仅适用于 AWS S3且可能需要显式授予密钥使用权限。Minio 场景实操仓库提供了完整的 Minio 部署示例 00-minio-deployment.yaml配合上述参数一份面向 Minio 的备份存储配置大致为backupStorageProvider: name: aws bucket: ark config: region: minio s3ForcePathStyle: true s3Url: http://minio:9000要点是s3ForcePathStyle: true让客户端采用路径风格path-style寻址Minio 这类本地服务不支持虚拟主机风格s3Url指向 Minio 服务地址region填一个占位区域即可例如minio。persistentVolumeProvider/configAWS OnlyKeyTypeDefaultMeaningregionstringRequired Field必填示例us-east-1。完整列表参见 AWS 官方区域文档。与备份存储不同持久卷快照的 region 是必填项因为创建 EC2 EBS 快照必须明确区域。AWS 上的持久卷快照底层依赖 EC2 APIec2:CreateSnapshot、ec2:DeleteSnapshot、ec2:DescribeVolumes等权限这与仓库 v0.9.0 文档 aws-config.md 中要求的 IAM 策略完全对应。GCP 专属配置GCP 段落极其简洁无论是backupStorageProvider/config还是persistentVolumeProvider/config都不需要任何必填参数。配置段必填参数说明backupStorageProvider/config无使用 GCS 时无需额外配置。persistentVolumeProvider/config无使用 GCE 持久磁盘快照时无需额外配置。GCP 场景下只需要在backupStorageProvider中指定name: gcp与bucketGCS 桶名。凭证与服务账号的准备工作见仓库文档 gcp-config.md其中要求服务账号具备compute.disks.createSnapshot、compute.snapshots.create/delete、gsutil iam ch ...:objectAdmin等权限即 GCP 侧的权限模型完全由服务账号承担而非写入Config。Azure 专属配置Azure 段落同样大部分无需参数唯一的例外是持久卷提供方的超时配置persistentVolumeProvider/configAzureKeyTypeDefaultMeaningapiTimeoutmetav1.Duration2m0sAzure API 请求在超时之前允许的最大等待时间。前置条件提醒使用 Azure 托管磁盘快照要求 Kubernetes 集群版本1.7.2见主参数表注释。仓库 v0.9.0 文档 azure-config.md 给出了一个完整可用的 AzureConfig示例apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default persistentVolumeProvider: name: azure config: apiTimeout: 15m backupStorageProvider: name: azure bucket: ark backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false其中apiTimeout: 15m是对默认2m的放大——当 Azure 侧 API 响应偏慢时适当增大该值可避免快照操作过早失败。需要注意的是Azure 的凭证并非写在Config中而是通过包含AZURE_SUBSCRIPTION_ID、AZURE_TENANT_ID、AZURE_RESOURCE_GROUP、AZURE_CLIENT_ID、AZURE_CLIENT_SECRET、AZURE_STORAGE_ACCOUNT_ID、AZURE_STORAGE_KEY七个环境变量的 Secret 注入见 azure-config.md其中AZURE_RESOURCE_GROUP必须指向集群磁盘所在的第二个资源组。从 Config 到实际部署完整落地流程结合仓库的部署文档一份Config从编写到生效的完整流程为准备对象存储桶在目标云厂商创建备份存储桶AWS S3 桶、GCS 桶或 Azure blob container。准备凭证创建云厂商凭证文件或服务主体并通过 Secret 注入集群。以 AWS 为例aws-config.mdkubectl create secret generic cloud-credentials \ --namespace ARK_NAMESPACE \ --from-file cloudcredentials-ark编写 Config按照本文的参数表在metadata.namespace: heptio-ark、metadata.name: default下配置两个 provider 段落与周期参数。先装前置资源再下发 Config先应用命名空间、RBAC 等前置资源如 v0.9.0 文档中的kubectl apply -f examples/common/00-prereqs.yaml再应用 Config 文件。启动 Ark server下发 Deployment如kubectl apply -f examples/aws/10-deployment.yaml。服务端启动后会等待defaultConfig 出现并读取。验证方式通过kubectl get config -n heptio-ark确认default对象存在若后续需要调整配置直接kubectl edit修改 ConfigArk server 会自动优雅重启并加载新值。常见问题与排查要点Config 修改后不生效检查 Ark server Pod 是否已由 kubelet 自动重启。按 v0.9.0 文档机制server 检测到 Config 变化会优雅关闭重启后读取新值若 Pod 长期未重启可排查 kubelet 与 Deployment 状态。PV 快照被判定为无效确认persistentVolumeProvider已配置未配置时请求 PV 快照的备份会被视为无效见主参数表。Azure 场景请额外确认集群版本 ≥ 1.7.2。本地存储Minio无法上传检查backupStorageProvider/config是否设置了s3ForcePathStyle: true与正确的s3Urlregion未提供时 Ark 会查询 S3 API本地存储通常需要显式给出占位 region。备份存储 region 校验失败AWSbackupStorageProvider的region为空时依赖 S3 API 自动查询aws-config.md网络受限或使用自定义 endpoint 时建议显式指定。恢复时资源顺序异常核对resourcePriorities列表是否包含namespaces、persistentvolumes、persistentvolumeclaims等关键资源未列入的资源会被延后恢复。总结Config对象是 Ark/Velero 服务端的第一道配置闸门persistentVolumeProvider决定快照能力backupStorageProvider决定备份存放位置三个周期参数决定服务端的后台节奏resourcePriorities决定恢复顺序restoreOnlyMode则提供灾备场景的只读保护。在 v0.9.0 的配置体系中AWS 是配置项最丰富的厂商支持 region、S3 兼容端点、KMS 加密GCP 几乎零配置Azure 仅有apiTimeout一个必知参数。理解这份配置的语义不仅能正确部署 v0.9.0 时代的 Ark也能顺畅迁移到现代 Velero 的BackupStorageLocationVolumeSnapshotLocation配置模型因为后者的字段语义正是从前者拆分演进而来。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
