企业官网建设流程全解析

Velero 前身 Heptio Ark 架构解析：Kubernetes 备份、恢复与定时调度全流程指南

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

本文基于当前仓库site/content/docs/v0.8.0/about.md（Heptio Ark v0.8.0 官方文档）撰写，并补充了同版本 API 类型定义、Config 配置参考、CLI 参考及仓库源码佐证。Heptio Ark 是 Velero 的前身与演进基础，理解 Ark 的备份/恢复/调度三大操作模型，是掌握 Velero 备份体系（备份控制器、对象存储同步、TTL 回收等）的最佳入口。

一、Ark 是什么：为 Kubernetes 提供可定制粒度的灾备能力

Heptio Ark 为 Kubernetes 集群中的所有对象（Pod、Deployment、Job、Custom Resource Definition 等）以及持久卷（Persistent Volume）提供可自定义粒度的恢复能力。这种恢复可以是集群级的全量恢复，也可以精细到按**对象类型（object type）、命名空间（namespace）或标签（labels）**进行过滤后的定向恢复。

因此 Ark 是**灾难恢复（Disaster Recovery）**场景的理想选择，同时也可以用于在执行集群系统级操作（例如集群升级）之前，先对应用状态进行快照留存——即"变更前留底"。

二、核心特性：三大操作全部以自定义资源（CRD）驱动

Ark 提供三类操作：

• 按需备份（On-demand backups）
• 定时备份（Scheduled backups）
• 恢复（Restores）

每一类操作都是一个自定义资源（Custom Resource），通过 Kubernetes 的 CRD 机制定义，并存储在etcd中。除此之外，还有一个额外的自定义资源Config，用于指定必需的云厂商信息和定制化选项（如云提供商设置）。

这些资源由对应的**自定义控制器（custom controllers）处理：当请求被提交到 Kubernetes API server 时，每个控制器会监听（watch）**其对应的自定义资源，执行校验，并处理与云厂商 API 交互的逻辑——例如管理对象存储和持久卷快照。

从当前仓库源码可以印证这一设计：Ark 演进为 Velero 后，Backup、Schedule、Restore的类型定义分别位于 pkg/apis/velero/v1/backup_types.go、pkg/apis/velero/v1/schedule_types.go 和 pkg/apis/velero/v1/restore_types.go，对应的控制器实现则在 pkg/controller/ 目录下（如 backup_controller.go）。

2.1 按需备份（Backup）

backup操作完成两件事：

1. 将复制的 Kubernetes 对象打包成 tarball，上传到云对象存储；
2. 若指定了快照，调用云厂商 API 对持久卷做磁盘快照。

你还可以在备份期间**可选地指定钩子（hooks）**在容器内执行命令。例如，在拍快照之前，可能需要先让数据库把内存缓冲区刷盘（flush 到磁盘）。详见 Hooks 文档。

需要注意：集群备份并非严格原子操作。如果在备份过程中有 Kubernetes 对象正在被创建或编辑，它们可能不会被包含进备份文件。捕获到不一致信息的概率很低，但理论上存在这种可能。

2.2 定时备份（Schedule）

schedule操作允许你按固定时间间隔备份数据。第一次备份在 schedule 创建时立即执行，后续备份则按指定的时间间隔发生，间隔由Cron 表达式指定。

Schedule 本质上是 Backup 的包装器（wrapper）：当被触发时，它在后台创建对应的 Backup 对象。

定时备份产生的备份资源命名规则为：

<SCHEDULE NAME>-<TIMESTAMP>

其中<TIMESTAMP>的格式为YYYYMMDDhhmmss。

2.3 恢复（Restore）

restore操作允许你从之前创建的 Backup 中恢复所有对象和持久卷。Ark 支持多命名空间重映射（namespace remapping）——例如，在单次恢复中，命名空间abc下的对象可以被重建到def下，同时123下的对象可以恢复到456下。

恢复出来的 Kubernetes 对象可以通过如下标签识别：

ark-restore=<BACKUP NAME>-<TIMESTAMP>

同样，<TIMESTAMP>格式为YYYYMMDDhhmmss。

此外，你还可以让 Ark 服务运行在restore-only（仅恢复）模式下，该模式会在灾备期间禁用 backup、schedule 和垃圾回收功能，避免误操作破坏恢复现场。

三、备份工作流：从一条 CLI 命令到对象存储

文档给出了执行ark backup create test-backup后的完整链路：

1. Ark 客户端调用 Kubernetes API server，创建一个Backup对象；
2. BackupController发现新的Backup对象并执行校验（validation）；
3. BackupController 开始备份流程：通过查询 API server收集（collect）待备份的资源数据；
4. BackupController 调用对象存储服务（例如 AWS S3）上传备份文件。

该流程的架构示意图如下（图源 site/content/docs/v0.8.0/img/backup-process.png）：

默认情况下，ark backup create会对所有持久卷制作磁盘快照。可以通过额外标志（flags）调整快照行为，例如用--snapshot-volumes=false禁用快照。完整的ark backup create参数如下（出处：ark_backup_create.md）：

ark backup create NAME [flags] --exclude-namespaces stringArray 从备份中排除的命名空间 --exclude-resources stringArray 从备份中排除的资源，格式为 resource.group，如 storageclasses.storage.k8s.io --include-cluster-resources optionalBool[=true] 是否包含集群级资源 --include-namespaces stringArray 要包含的命名空间（用 '*' 表示所有命名空间）(默认 *) --include-resources stringArray 要包含的资源（默认 '*'） --labels mapStringString 应用到备份上的标签 -l, --selector labelSelector 只备份匹配该标签选择器的资源 --snapshot-volumes optionalBool[=true] 是否作为备份的一部分对 PersistentVolume 拍快照 --ttl duration 备份多久之后可以被垃圾回收 (默认 720h0m0s)

四、Backup 对象的完整定义（API 类型）

Backup属于 API 组版本ark.heptio.com/v1。下面是根据 Backup API Type 文档整理的带字段注释的完整示例——这也是ark backup create在背后生成的 CR 对象形态：

apiVersion: ark.heptio.com/v1 kind: Backup metadata: name: a namespace: heptio-ark # 0.7.0 之后可为任意字符串，但必须是 Ark server 所在命名空间 spec: # 要包含的命名空间，未指定则包含全部；可选 includedNamespaces: - '*' # 要排除的命名空间；可选 excludedNamespaces: - some-namespace # 要包含的资源，支持缩写（如 'po' 代表 'pods'）；未指定则包含全部；可选 includedResources: - '*' # 要排除的资源；可选 excludedResources: - storageclasses.storage.k8s.io # 是否包含集群级资源。取值 true / false / null。 # 未设置时：仅当包含全部命名空间且无排除时，才包含全部集群级资源； # 只要 included/excludedNamespaces 指定了具体命名空间，则只备份与 # 被包含的命名空间级资源相关联的集群级资源（如随 PVC 一起备份其 PV）。 includeClusterResources: null # 个体对象必须匹配该标签选择器才会被包含进备份；可选 labelSelector: matchLabels: app: ark component: server # 是否对卷拍快照（仅对 Azure、GCE、AWS 的 PersistentVolume 生效）。 # 取值 true / false / null；未设置时，只要配置了 PV provider 就会执行快照。 snapshotVolumes: null # 该备份多久后进入可被垃圾回收的状态 ttl: 24h0m0s # 备份过程中不同阶段执行的动作；目前唯一支持的 hook 是通过 pod exec API # 在 Pod 容器内执行命令；可选 hooks: resources: - name: my-hook includedNamespaces: - '*' excludedNamespaces: - some-namespace includedResources: - pods # 目前仅支持 pods excludedResources: [] labelSelector: matchLabels: app: ark component: server # 在自定义动作（custom actions）执行之前运行的 hook；目前仅支持 exec； # 已废弃，改用 pre hooks: # 内容与下面的 pre 相同 pre: - exec: container: my-container # 未指定则使用 Pod 的第一个容器；可选 command: # 要执行的命令，数组形式；必填 - /bin/uname - -a onError: Fail # 出错时的处理方式：Fail / Continue，默认 Fail；可选 timeout: 10s # 命令最长等待时间，默认 30 秒；可选 # 在所有自定义动作及附加项处理完成后执行的 hook；目前仅支持 exec post: # 内容与上面的 pre 相同 status: expiration: null # 可被垃圾回收的时间点 phase: "" # 取值：New / FailedValidation / InProgress / Completed / Failed validationErrors: null # 校验错误列表 version: 1 # 当前仅支持版本 1 volumeBackups: # 恢复时需要的 PV 信息 some-pv-name: snapshotID: snap-1234 # 云厂商侧为本次备份创建的快照 ID type: io1 # 云厂商 API 中的卷类型 availabilityZone: my-zone # 卷所在可用区 iops: 10000 # 卷的预置 IOPS；可选

提示：关于 hook 的另一种指定方式——直接在 Pod 上加注解（annotation）。Ark 支持pre.hook.backup.ark.heptio.com/{container,command,on-error,timeout}与post.hook.backup.ark.heptio.com/*（v0.7.0+）两套注解，其中on-error默认Fail、timeout默认30s，command需以 JSON 数组形式给出（如["/usr/bin/uname", "-a"]）。完整表格与示例见 Hooks 文档。

五、Ark Config：云厂商与服务器行为配置

Ark 定义了属于自己的Config 对象（一种自定义资源），用于指定备份与云厂商设置。Ark server 首次部署后会等待你在heptio-ark命名空间中创建名为default的 Config。

注意：前提是 Ark server 以 Kubernetes Deployment 方式运行。若defaultConfig 被修改，server 会优雅关闭（gracefully shut down）；待 kubelet 重启 Ark server Pod 后，再使用更新后的配置。

5.1 示例 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

5.2 主配置参数参考

5.3 云厂商专属参数

AWS（或其他 S3 兼容存储）——backupStorageProvider/config

AWS——persistentVolumeProvider/config

GCP：backupStorageProvider/config与persistentVolumeProvider/config均无需参数。

Azure：backupStorageProvider/config无需参数；persistentVolumeProvider/config仅一项：

完整参数说明见 Ark Config definition 文档。

六、设置备份过期（TTL）

创建备份时，可以通过--ttl <DURATION>标志指定 TTL。当 Ark 发现某个 Backup 资源已过期时，会删除：

• Backup 资源本身；
• 云对象存储中的备份文件；
• 所有 PersistentVolume 快照；
• 所有与之关联的 Restore。

该机制由gcSyncPeriod（默认 60 分钟）周期驱动：Ark 会按此频率查询对象存储，删除已超过 TTL 的备份文件。在 Backup API 定义 中，过期时间点记录在status.expiration字段；ark backup create的默认 TTL 为720h（30 天）。

七、对象存储同步：把对象存储作为事实来源

Ark将对象存储视为事实来源（source of truth），持续检查确保正确的 Backup 资源始终存在。如果存储桶中存在格式正确的备份文件，但 Kubernetes API 中没有对应的 Backup 资源，Ark 会把信息从对象存储同步到 Kubernetes——即在集群中重建对应的 Backup 资源对象。

这一机制使**集群迁移（cluster migration）**场景下的恢复成为可能：当原集群的 Backup 对象在新集群中不存在时，只要备份文件还在对象存储中，新集群的 Ark 就能通过同步找回这些备份并执行恢复。同步周期由 Config 中的backupSyncPeriod（默认 60 分钟）控制，对应的实现可参考 backup_sync_controller.go。

八、实践小结：Ark v0.8.0 的完整使用闭环

结合 CLI 参考目录 与本文内容，Ark 的核心操作闭环可归纳为：

1. 部署 server 并创建 Config：ark server（参考 ark_server.md），并在heptio-ark命名空间创建名为default的 Config 以声明云厂商与周期参数；
2. 按需备份：ark backup create NAME，配合--include-namespaces、--selector、--snapshot-volumes、--ttl等标志控制粒度与行为；
3. 定时备份：ark create schedule NAME --schedule="0 */6 * * *"（Cron 五段式：分/时/日/月/周，各字段可取值0-59,*、0-23,*、1-31,*、1-12,*、0-7,*，详见 ark_create_schedule.md）；
4. 恢复：ark restore create [RESTORE_NAME] --from-backup BACKUP_NAME，支持--namespace-mappings src1:dst1,src2:dst2,...做多命名空间重映射、--restore-volumes=false跳过卷恢复（详见 ark_create_restore.md）；
5. 灾备模式：在 Config 中开启restoreOnlyMode: true，让 Ark 只从对象存储恢复，禁用备份、调度与 GC。

这套"CRD 定义操作 + 控制器监听执行 + 对象存储作为事实来源"的架构，构成了后来 Velero 备份体系的核心骨架——理解 Ark v0.8.0 的这一模型，即可顺藤摸瓜读懂 Velero 各控制器与 API 类型的演进脉络。

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