企业官网建设流程全解析

Velero（前身 Ark）实战：基于 Schedule 的灾备恢复与跨集群迁移方案

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero

本文基于仓库中 v0.7.1 时代的 Ark 官方文档 use-cases.md 编写。该文档是 Velero（当时名为 Heptio Ark）早期版本的官方使用场景指南，系统讲解了 Kubernetes 集群的**灾备恢复（Disaster Recovery）与跨集群迁移（Cluster Migration）**两大核心场景，给出了从备份到恢复的完整命令行操作流程。读完本文，你将掌握：如何用ark schedule建立周期性备份、如何通过restoreOnlyMode让集群进入只读恢复模式、如何在同一云厂商的两个集群之间完成数据与应用的整体搬迁，以及这些命令背后的 Config 配置项与参数含义。

在 Velero 项目的发展历史上，Ark 是其最初的代号。本文所引用的site/content/docs/v0.7.1/目录保留了当时完整的官方文档快照，其中use-cases.md聚焦于最常见的两个运维场景：当集群发生意外事故时如何恢复到历史状态（灾备恢复），以及如何把资源从旧集群整体搬运到新集群（集群迁移）。无论哪个场景，底层都依赖于 Ark 的 Backup（备份）、Schedule（定时备份）与 Restore（恢复）三类核心对象，以及一个指向云端对象存储的 Ark Config 配置。

场景总览：两个核心使用模式

原文档开篇即明确了 Ark 面向的两种典型场景：

1. 灾备恢复（Disaster Recovery）——通过Schedules（定时备份）与 Restore-Only Mode（仅恢复模式）组合使用，在集群发生意外（如服务中断、误删除）时，用最近一次备份将集群恢复到事故前的状态。
2. 集群迁移（Cluster Migration）——通过Backups（备份）与 Restores（恢复）组合使用，在两个集群共享同一对象存储的前提下，将整个集群的资源从 Cluster 1 迁移到 Cluster 2。

这两种模式是理解 Ark/Velero 价值的最小入口：前者强调“在同一个集群上回到过去”，后者强调“在另一个集群上复制现在”。而两者的实现都围绕云对象存储（S3/GCS/Azure Blob）展开——备份文件上传到存储桶，恢复时再从存储桶拉取。

场景一：灾备恢复（Disaster Recovery）

第 1 步：部署后立即建立每日备份

在集群上首次运行 Ark server 后，第一步是用schedule操作建立周期性的备份。原文档给出的命令为：

ark schedule create <SCHEDULE NAME> --schedule "0 7 * * *"

其中<SCHEDULE NAME>可替换为你期望的调度名称，--schedule参数接受标准的 cron 表达式，"0 7 * * *"表示每天 7:00 触发一次。执行该命令后，Ark 会创建一个名为<SCHEDULE NAME>-<TIMESTAMP>的 Backup 对象——也就是说，每一次定时触发的备份都以“调度名-时间戳”的形式命名，方便按时间定位最近一次的备份。

关于该命令的完整参数，可查阅仓库中的命令参考文档 ark_schedule_create.md。它支持以下关键选项：

值得注意的是，--schedule与--ttl两个选项组合起来，就构成了 Ark 备份数据的生命周期管理：cron 决定“何时备份”，TTL 决定“备份保留多久后被清理”。ttl的默认值为 30 天（720 小时），你完全可以根据业务需求调整为更短或更长的保留周期。

第 2 步：事故发生，需要重建资源

原文档明确指出，灾难发生后需要“recreate your resources”。此时集群可能已经部分或全部不可用，恢复的前提是对象存储中的备份文件仍然完好——这也提醒我们：备份数据存放于云端对象存储，其安全性直接决定了灾备恢复的成败。

第 3 步：开启 Restore-Only Mode（仅恢复模式）

这是灾备场景下最关键的配置动作。恢复过程需要修改 Ark server 的 Config，将restoreOnlyMode设置为true：

restoreOnlyMode: true

原文档解释了这一配置的作用：它可以防止在恢复过程中创建或删除 Backup 对象。换句话说，进入仅恢复模式后，Ark 会关闭备份、调度、过期备份清理等全部“写”能力，只允许从对象存储中已有的备份文件执行恢复操作。这确保了灾难恢复期间系统状态的一致性——不会因为新的备份任务或 GC 清理而干扰或污染恢复过程。

关于这一配置项的完整定义，可参见 config-definition.md 中的参数表：

restoreOnlyMode（bool，默认false）：当 Restore Only 模式开启时，backups、schedules 以及过期备份删除功能全部关闭，仅从对象存储中已有的备份文件进行恢复。

这里需要补充原文档提及但未展开的运维细节：Ark 的 Config 是一个名为default的自定义资源，位于heptio-ark命名空间。当defaultConfig 被修改时，Ark server 会优雅关闭（gracefully shut down）；kubelet 重启 Ark server 的 Pod 后，server 便会使用更新后的配置值。因此修改restoreOnlyMode后，配置生效与 Pod 重启是相关联的。

第 4 步：用最近的备份执行恢复

完成上述配置后，用最近一次 Ark Backup 创建恢复：

ark restore create <SCHEDULE NAME>-<TIMESTAMP>

<SCHEDULE NAME>-<TIMESTAMP>正是第 1 步中由 schedule 自动生成的那个备份名。ark restore create接受一个 BACKUP 参数，完整选项可参见 ark_restore_create.md，包括：

灾备恢复流程小结

将上述步骤串联起来，一次完整的灾备恢复就是：

1. ark schedule create <NAME> --schedule "0 7 * * *"建立每日备份基线；
2. 事故发生后，将 Config 中的restoreOnlyMode改为true并等待 server 重启生效；
3. ark restore create <SCHEDULE NAME>-<TIMESTAMP>从最近的备份恢复；
4. 集群恢复完成后，视需要将restoreOnlyMode改回false，让 Ark 重新具备备份与清理能力。

场景二：集群迁移（Cluster Migration）

迁移前提：共享同一对象存储

与灾备恢复不同，集群迁移的目标是把资源从 Cluster 1 搬到 Cluster 2。原文档给出的前提条件有两个：

1. 两个集群的 Ark Config 都指向同一个云对象存储（同一 bucket）；
2. 两个集群由同一云厂商托管。

同时原文档给出了一个重要的能力边界警告：

注意：Ark 不支持跨云厂商迁移 PersistentVolume（持久卷）。

也就是说，PV 快照与恢复依赖于云厂商的存储 API，AWS 的快照无法在 GCP 上恢复，反之亦然。跨云迁移时，PV 数据将无法通过 Ark 的原生快照机制搬移（这一点在原文档发布后很长一段时间内都成立，直到后续版本才逐步演进）。因此在规划迁移前，务必确认源集群与目标集群处于同一云厂商，或已为 PV 数据准备了其他迁移通道。

第 1 步：（Cluster 1）备份整个集群

如果此前没有用schedule做过周期性检查点备份，就需要手动为整个集群创建一次备份：

ark backup create <BACKUP-NAME>

<BACKUP-NAME>可替换为任意你期望的名字。这里同样可以应用--ttl选项控制备份保留时长。ark backup create的完整参数可参见 ark_backup_create.md，其选项与ark schedule create基本一致（均支持 include/exclude 资源与命名空间、标签选择器、卷快照开关、TTL 等）。

原文档特别提醒了默认 TTL：备份的默认 TTL 是 30 天（720 小时），可通过--ttl按需调整。这一默认值与 Backup API 类型中的ttl字段相对应（见 backup.md 中的示例ttl: 24h0m0s），也体现在 CLI 参数默认值--ttl duration ... (default 720h0m0s)中。如果你的迁移过程可能跨越较长时间，建议在创建备份时显式设置足够长的 TTL，避免备份在迁移完成前被垃圾回收。

第 2 步：（Cluster 2）对齐 Config 中的云存储配置

在 Cluster 2 上，需要确保 Ark Config 中的persistentVolumeProvider和backupStorageProvider字段与 Cluster 1完全一致，从而让新的 Ark server 实例指向同一个 bucket。

关于这两个字段，config-definition.md 给出了精确定义：

• persistentVolumeProvider（CloudProviderConfig，可选）：集群用于持久卷快照的云厂商配置。如果未指定，则请求 PV 快照/恢复的 Backup 与 Restore 会被判定为无效。Ark 原生支持aws、gcp、azure三家厂商，其他厂商可通过外部插件扩展。
• backupStorageProvider（CloudProviderConfig，必填）：用于实际存储备份文件的云厂商配置，其中bucket字段指定备份上传的存储桶。

一个典型的 AWS 场景下的完整 Config 示例（来自 config-definition.md）：

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

迁移场景下“指向同一个 bucket”的关键，就在于backupStorageProvider.bucket与backupStorageProvider.config中与存储端点相关的参数（如 AWS 的region、s3Url、s3ForcePathStyle）必须与 Cluster 1 一致。值得注意的是，Config 中还有几个与对象存储同步相关的周期参数，它们对迁移场景同样重要：

其中backupSyncPeriod正是第 3 步“Ark 资源与云端备份文件同步”这一行为的底层机制。

第 3 步：（Cluster 2）确认备份对象已同步

Cluster 2 上的 Ark server 会周期性查询对象存储，为存储中已有的备份文件创建对应的 Backup 对象——这一行为由 Config 中的backupSyncPeriod（默认 60 分钟）控制。原文档建议在这一步确认ark restore create所需的 Backup 对象（<BACKUP-NAME>）已经出现在 Cluster 2 上，再继续下一步。

第 4 步：（Cluster 2）执行恢复

确认备份对象存在后，在 Cluster 2 上执行恢复：

ark restore create <BACKUP-NAME>

恢复完成后，Cluster 1 上的全部资源（含 PV 数据，前提是同云厂商且快照可用）就会在 Cluster 2 上重建。与灾备场景不同，这里通常不需要开启restoreOnlyMode，因为迁移过程中两个集群处于不同生命周期，Cluster 2 上的 Ark 保持正常模式即可。但如果希望在迁移期间严格禁止目标集群产生任何新备份，同样可以将restoreOnlyMode设为true作为保险。

集群迁移流程小结

1. （Cluster 1）ark backup create <BACKUP-NAME>备份整个集群，必要时用--ttl调整保留期；
2. （Cluster 2）确保persistentVolumeProvider与backupStorageProvider与 Cluster 1 一致，指向同一 bucket；
3. （Cluster 2）等待backupSyncPeriod周期完成对象同步，确认<BACKUP-NAME>Backup 对象可见；
4. （Cluster 2）ark restore create <BACKUP-NAME>完成资源恢复。

从 Ark 到 Velero：本文内容的项目坐标

需要说明的是，本文引用的use-cases.md、config-definition.md 以及 cli-reference 目录均来自仓库中保留的v0.7.1 历史文档快照。当时的命令行工具名为ark，API 组为ark.heptio.com/v1，操作命名空间为heptio-ark。如今的 Velero 项目已演进为velero命令、velero.io/v1API 组与velero命名空间，但本文所讲的“定时备份 + 仅恢复模式”的灾备思路，以及“同云厂商、共享对象存储”的迁移前提，依然是 Velero 现代版本（对应仓库根目录下 README.md 所描述的能力）中一脉相承的核心理念。

如果你希望在当前仓库中继续深入：

• 查看 v0.7.1 完整的命令参考：cli-reference/ark.md；
• 查看 Config 全量参数与 AWS/GCP/Azure 各厂商的专有配置：config-definition.md、aws-config.md、gcp-config.md、azure-config.md；
• 查看 Backup API 类型中ttl等字段的 YAML 示例：api-types/backup.md。

结语

灾备恢复与集群迁移，是 Kubernetes 备份工具最经典、也最具实战价值的两个场景。通过本文可以看到，Ark/Velero 用极简的对象模型（Backup、Schedule、Restore + Config）就覆盖了这两个场景：一个ark schedule create加上 cron 表达式即建立灾备基线，一个restoreOnlyMode即锁定恢复期间的集群状态，一次共享 bucket 的配置对齐即可打通跨集群迁移的数据通道。无论你使用的是当年的 Ark 还是今天的 Velero，理解这两个场景背后的对象、配置与命令流，都能帮助你在真实的集群运维中快速落地一套可靠的备份与迁移体系。

【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero