企业官网建设流程全解析

Heptio Ark v0.10.0 完全指南：Kubernetes 集群备份恢复与 v0.10 升级实战

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

导读

本文以 Velero 项目早期版本（当时名为 Heptio Ark）v0.10.0 的官方文档为主体，系统讲解 Ark 的架构原理、存储位置（BackupStorageLocation / VolumeSnapshotLocation）配置、Minio 快速上手流程、hooks 与 restic 集成，以及从旧版本升级到 v0.10.0 的破坏性变更与逐步操作。读完本文，你将掌握 Ark 集群备份、恢复、调度与多存储位置管理的基本能力，并能在自己的 Kubernetes 集群中复现完整的备份-灾难-恢复演练。

Ark 是什么：面向 Kubernetes 的备份恢复工具

Ark 为 Kubernetes 集群资源和持久卷（PersistentVolume）提供备份与恢复能力，其典型用途包括：

• 对集群进行备份，在发生数据丢失时恢复；
• 将集群资源复制到其他集群，实现集群迁移；
• 复制生产环境，用于开发和测试环境。

Ark 由两部分组成：集群内运行的 server（负责执行备份、恢复等操作）和本地运行的 命令行客户端（CLI）。它既可以在云厂商的集群上运行，也可以部署在本地（on-premises）环境，详细的支持范围见兼容存储提供商列表。

Ark 的工作原理：一切操作都是自定义资源

从How Ark Works 文档可以看到 Ark 的核心设计：每一次操作——无论是按需备份、计划备份还是恢复——都是一个 Kubernetes 自定义资源（Custom Resource），通过 CRD（Custom Resource Definition）定义并存储在 etcd 中。Ark 还包含若干控制器（controller）来处理这些自定义资源，从而真正执行备份、恢复以及相关操作。

你可以备份或恢复集群中的所有对象，也可以按类型、命名空间和/或标签（label）对对象进行过滤。这一机制使 Ark 非常适合灾难恢复场景，也适合在对集群执行系统操作（例如升级）之前为应用状态打快照。

按需备份（On-demand Backups）

backup操作的工作内容：

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

备份期间还可以指定 hooks（钩子）在备份过程中执行命令。例如，你可能需要在打快照前告诉数据库把内存中的缓冲刷到磁盘。hooks 的详细说明见后文。

需要说明的是，集群备份并非严格原子操作：如果备份进行时有 Kubernetes 对象正在被创建或修改，这些对象可能不会被包含进备份中。捕获到不一致信息的概率很低，但确实存在。

计划备份（Scheduled Backups）

schedule操作允许你按固定间隔定期备份。第一次备份会在 schedule 创建时立即执行，之后按指定的间隔周期执行，间隔由 Cron 表达式指定。

计划备份生成的备份名称格式为<SCHEDULE NAME>-<TIMESTAMP>，其中<TIMESTAMP>的格式为YYYYMMDDhhmmss。

恢复（Restores）

restore操作可以从之前创建的备份中恢复全部对象与持久卷，也可以只恢复被过滤后的对象和持久卷子集。Ark 支持多重命名空间重映射——例如，在一次恢复中，命名空间 "abc" 下的对象可以被重建到 "def" 下，同时 "123" 下的对象被重建到 "456" 下。

恢复的默认名称是<BACKUP NAME>-<TIMESTAMP>，时间戳格式同为YYYYMMDDhhmmss；你也可以指定自定义名称。恢复出的对象会带有一个标签，键为ark.heptio.com/restore-name，值为<RESTORE NAME>。

此外，Ark server 还可以运行在restore-only（仅恢复）模式下，该模式会禁用备份、计划与垃圾回收功能，专门用于灾难恢复场景。

备份工作流

当我们执行ark backup create test-backup时，背后发生如下过程：

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

默认情况下，ark backup create会为所有持久卷制作磁盘快照。你可以通过附加标志调整快照行为，运行ark backup create --help查看可用标志；使用--snapshot-volumes=false可以禁用快照。

从当前仓库的源码结构看，这一控制器模型至今仍被保留并演进：backup_controller.go 负责处理 Backup 对象的校验与执行，backup_sync_controller.go 则负责下文提到的对象存储同步逻辑。

设置备份过期（TTL）

创建备份时，可通过--ttl <DURATION>标志指定 TTL（生存时间）。当 Ark 发现已有备份资源过期时，会删除：

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

对象存储同步

Ark 将对象存储视为数据源（source of truth），会持续检查确保正确的备份资源始终存在。如果存储桶中存在格式正确的备份文件，但 Kubernetes API 中没有对应的备份资源，Ark 会把信息从对象存储同步到 Kubernetes。这使得在集群迁移场景下恢复功能得以正常工作——因为新集群中原本不存在备份对象。反之，如果某个备份对象存在于 Kubernetes 中但对象存储中已没有对应文件，该备份对象会从 Kubernetes 中被删除（因为备份 tarball 已不存在）。

兼容的存储提供商

根据兼容存储提供商文档，Ark 为不同的备份和快照操作支持多种存储提供商。自 v0.6.0 起，Ark 引入了插件系统，任何人都可以在不修改 Ark 代码库的前提下为新的备份/卷存储平台增加兼容支持。

备份存储提供商（Backup Storage Providers）

S3 兼容的备份存储提供商

Ark 使用 Amazon Go SDK 连接 S3 API。部分第三方存储提供商同样支持 S3 API，以下提供商经用户报告可与 Ark 配合使用（注意：这些提供商并未由 Ark 团队定期测试）：

• IBM Cloud
• Minio
• Ceph RADOS v12.2.7
• DigitalOcean

卷快照提供商（Volume Snapshot Providers）

若要为新的备份或卷存储系统编写插件，可参考官方示例仓库，并在插件发布后通过 PR 将你的插件加入上述列表。

v0.10.0 破坏性变更：Config CRD 的消亡与新位置体系

v0.10.0 引入了一系列破坏性变更，升级前务必阅读升级到 v0.10 的文档。

变更一：从 Config CRD 切换为两个新 CRD

在 v0.10.0 之前，Ark 使用ConfigCRD 来保存备份存储与持久卷提供商信息以及杂项设置。v0.10.0 彻底移除了该 CRD，取而代之的是：

• BackupStorageLocationCRD：记录备份存放在哪里（API 文档）；
• VolumeSnapshotLocationCRD：记录持久卷快照存放在哪里（API 文档）；
• ark server命令的命令行标志（由 Ark deployment 运行）：承载杂项 Ark 设置。

升级到 v0.10 时，需要把原先ConfigCRD 中的配置信息迁移到上述新载体中。存储位置总览对这个变化的动机有整体说明。

变更二：对象存储中的数据目录重组

Ark 对对象存储中的数据存放布局做了重新调整，以追求简单与可扩展性。升级时必须重新整理 pre-v0.10 的数据，官方提供了脚本辅助完成。

新的 ark server 标志

在 Ark deployment YAML 中，需要在容器的args下为ark server命令指定如下标志：

这些标志的值必须对应集群中真实存在的BackupStorageLocation与VolumeSnapshotLocation自定义资源名称。若未为--default-backup-storage-location指定值，Ark server 会查找名为default的BackupStorageLocation使用。

此外还有若干非默认的 Ark server 设置：

逐步升级步骤

1. 下载并解压最新 release；
2. 缩容现有 Ark deployment：

   kubectl scale -n heptio-ark deploy/ark --replicas 0

3. 在 Ark 目录（解压 release tarball 的目录）中重新应用00-prereqs.yaml以创建新 CRD：

   kubectl apply -f config/common/00-prereqs.yaml

4. 参照config/目录中针对你平台的示例，结合现有Config资源中的信息，创建一个或多个BackupStorageLocation资源；
5. 如果使用 Ark 进行 PV 快照，再创建VolumeSnapshotLocation资源（同样参考config/目录）；
6. 执行文档中详述的一次性对象存储迁移；
7. 在 Ark deployment YAML 中为ark server指定新标志（见上表）；
8. 如果使用插件，将 deployment YAML 中initContainers部分引用的插件镜像标签更新到最新；
9. 应用更新后的 deployment YAML，确认 pod 成功启动；
10. 如果使用了 restic 集成，确保 daemon set pod 已用最新 Ark 镜像重建（若 daemon set YAML 使用:latest标签，可删除 pod 使其以新镜像重建）；
11. 确认所有设置迁移无误后，删除旧的 Config CRD：

    kubectl delete -n heptio-ark config --all kubectl delete crd configs.ark.heptio.com

存储位置机制：BackupStorageLocation 与 VolumeSnapshotLocation

为什么需要新的位置体系

v0.10.0 之前，备份存储位置由Config自定义资源的backupStorageProvider段定义（provider + bucket + provider 特定设置），卷快照位置由persistentVolumeProvider段定义。这种设计无法支持以下场景：

• 在单个 Ark 备份中为多种持久卷类型打快照（例如集群中同时有 EBS 卷和 Portworx 卷）；
• 一部分备份存放在美东区域的 bucket，另一部分存放在美西区域的 bucket；
• 对支持多位置的卷提供商（例如 Portworx），一部分快照存在集群本地、一部分存在云端。

同时，作为路线图上的重要功能——备份复制（backup replication），也需要 Ark 支持多个可能的存储位置。

新机制概览

v0.10.0 用两个新自定义资源替代了Config：BackupStorageLocation（直接取代backupStorageProvider段）与VolumeSnapshotLocation（直接取代persistentVolumeProvider段）。现在用户可以预先定义多个可能的存储位置，并在创建备份时选择备份及其关联快照存放的位置。

• BackupStorageLocation由 bucket、bucket 内存放所有 Ark 数据的前缀（prefix）以及一组 provider 特定字段（如 AWS region、Azure storage account 等）构成；
• VolumeSnapshotLocation完全由 provider 特定字段构成（如 AWS region、Azure resource group、Portworx snapshot type 等）。

由于可以创建多个VolumeSnapshotLocation，用户能为多个卷提供商分别配置位置；当集群中存在多种卷（如 AWS EBS 与 Portworx）时，所有这些卷都能在单个 Ark 备份中被快照。

BackupStorageLocation 参数参考

一个典型的BackupStorageLocationYAML 如下：

apiVersion: ark.heptio.com/v1 kind: BackupStorageLocation metadata: name: default namespace: heptio-ark spec: provider: aws objectStorage: bucket: myBucket config: region: us-west-2

主配置参数：

AWS（或其他 S3 兼容存储）的objectStorage/config参数：

Azure 的objectStorage/config参数：

GCP 无需任何参数。

VolumeSnapshotLocation 参数参考

apiVersion: ark.heptio.com/v1 kind: VolumeSnapshotLocation metadata: name: aws-default namespace: heptio-ark spec: provider: aws config: region: us-west-2

主配置参数：provider（必填）与config（见对应 provider 文档）。AWS 只需region；Azure 支持apiTimeout（metav1.Duration，默认2m0s，Azure API 请求超时时间）与resourceGroup（可选，卷快照存放的资源组，默认与集群资源组相同）；GCP 无需参数。

多位置实操示例

场景一：单个备份中为多种持久卷打快照（如集群同时有 EBS 与 Portworx 卷）

服务端配置：

ark snapshot-location create ebs-us-east-1 \ --provider aws \ --config region=us-east-1 ark snapshot-location create portworx-cloud \ --provider portworx \ --config type=cloud

创建备份时：

ark backup create full-cluster-backup \ --volume-snapshot-locations ebs-us-east-1,portworx-cloud

如果每个 provider 只配置了一个 volume snapshot location（如ebs-us-east-1之于aws、portworx-cloud之于portworx），Ark 不要求显式指定，直接ark backup create full-cluster-backup即可。

场景二：部分备份存美东 bucket、部分存美西 bucket

服务端配置：

ark backup-location create default \ --provider aws \ --bucket ark-backups \ --config region=us-east-1 ark backup-location create s3-alt-region \ --provider aws \ --bucket ark-backups-alt \ --config region=us-west-1

创建备份时不指定位置（走default），或显式指定：

ark backup create full-cluster-alternate-location-backup \ --storage-location s3-alt-region

场景三：Portworx 快照一部分存本地、一部分存云端

ark snapshot-location create portworx-local \ --provider portworx \ --config type=local ark snapshot-location create portworx-cloud \ --provider portworx \ --config type=cloud

创建备份时显式选择：

ark backup create local-snapshot-backup \ --volume-snapshot-locations portworx-local ark backup create cloud-snapshot-backup \ --volume-snapshot-locations portworx-cloud

单位置场景依然简单：如果只需要一个位置（例如在 AWSus-west-1运行），配置default的 backup location 与一个 EBS snapshot location 后，创建备份时无需指定任何额外参数。

限制与注意事项

• 卷快照仍受限于提供商允许创建快照的位置。例如 AWS 与 Azure 不允许在卷所在区域之外创建卷快照；若用不同区域的 volume snapshot location 创建备份，备份会失败。
• 每个 Ark 备份有且仅有一个BackupStorageLocation、每个卷提供商有且仅有一个VolumeSnapshotLocation。目前还无法把单个备份同时发送到多个备份存储位置，也无法把单个卷快照同时发送到多个位置。若需要在多个位置间冗余备份，可以设置多个仅存储位置不同的计划备份。
• 不支持跨提供商快照。如果集群有不止一种类型的卷（如 EBS 与 Portworx），但只为 EBS 配置了VolumeSnapshotLocation，Ark 只会快照 EBS 卷。
• restic 数据现在存放于主 Ark bucket 的一个前缀/子目录下，并写入创建备份时用户所选BackupStorageLocation对应的 bucket。

快速上手：用 Minio 跑通备份与恢复

get-started 文档给出了一套在集群内启动 Ark server 与客户端、备份并恢复示例应用的完整流程。为简化起见，示例使用 Minio——一个运行在集群本地的 S3 兼容存储服务。注意：该示例仅用于探索 Ark 基础功能，生产环境的 Minio 配置不在本文范围内。

前置条件

• 可访问 Kubernetes 集群，版本 1.7 及以上（运行ark backup delete需要 1.7.5 及以上）；
• 集群内有 DNS 服务；
• 已安装kubectl。

下载与解压

下载对应平台的最新 release tarball 后解压，并将ark二进制放入 PATH：

tar -xzf <RELEASE-TARBALL-NAME>.tar.gz -C /dir/to/extract/to

启动 server 与 Minio

kubectl apply -f config/common/00-prereqs.yaml kubectl apply -f config/minio/

部署示例 nginx 应用：

kubectl apply -f config/nginx-app/base.yaml

确认 Ark 与 nginx 的 deployment 均创建成功：

kubectl get deployments -l component=ark --namespace=heptio-ark kubectl get deployments --namespace=nginx-example

（可选）将 Minio 暴露到集群外

执行获取日志或ark describe等命令时，Ark server 会生成预签名 URL 以下载请求的内容。要从集群外（即你的 Ark 客户端）访问这些 URL，需要让 Minio 可被外部访问。有两种方式：把 Minio Service 类型从ClusterIP改为NodePort；或为集群配置 Ingress 并保持ClusterIP。在 Ark 0.10 中，还可以在 backup storage 配置中为新字段publicUrl指定预签名 URL 的值。

使用 NodePort 方式：

1. 在 examples/minio/00-minio-deployment.yaml 中把 Service 的spec.type从ClusterIP改为NodePort；
2. 获取 Minio URL：Minikube 环境运行minikube service minio --namespace=heptio-ark --url；其他环境取任意节点的外部 IP 或 DNS 名，再拼接 NodePort 端口（用kubectl -n heptio-ark get svc/minio -o jsonpath='{.spec.ports[0].nodePort}'获取）；
3. 在 Minio 的 backupstoragelocation YAML 中取消publicUrl行的注释，填入该 Minio URL（必须包含http://或https://前缀）。

使用 Ingress 方式：保持 Service 类型为ClusterIP，在 backupstoragelocation YAML 的publicUrl字段中填入 Ingress 的 URL 与端口。

创建备份

备份所有匹配app=nginx标签选择器的对象：

ark backup create nginx-backup --selector app=nginx

如果希望备份除标签backup=ignore之外的所有对象：

ark backup create nginx-backup --selector 'backup notin (ignore)'

（可选）创建基于 cron 表达式的定期备份：

ark schedule create nginx-daily --schedule="0 1 * * *" --selector app=nginx

也支持非标准简写 cron 表达式，例如ark schedule create nginx-daily --schedule="@daily" --selector app=nginx。

模拟灾难

删除示例命名空间：

kubectl delete namespace nginx-example

随后确认 nginx deployment、service 与命名空间均已不存在（可能需要等待几分钟让命名空间完全清理）：

kubectl get deployments --namespace=nginx-example kubectl get services --namespace=nginx-example kubectl get namespace/nginx-example

恢复

ark restore create --from-backup nginx-backup ark restore get

恢复完成后输出类似：

NAME BACKUP STATUS WARNINGS ERRORS CREATED SELECTOR nginx-backup-20170727200524 nginx-backup Completed 0 0 2017-07-27 20:05:24 +0000 UTC <none>

恢复可能需要片刻，期间STATUS列为InProgress；成功后为Completed，WARNINGS与ERRORS为 0。若有错误或警告，可用ark restore describe <RESTORE_NAME>查看详情。

清理

删除备份（包括对象存储中的数据和持久卷快照）：

ark backup delete BACKUP_NAME

该命令会请求 Ark server 删除与该备份关联的全部备份数据；每个想永久删除的备份都需要执行一次。卸载 Ark 但保留备份数据时，可安全删除示例创建的资源：

kubectl delete -f config/common/ kubectl delete -f config/minio/ kubectl delete -f config/nginx-app/base.yaml

进阶能力：hooks 与 restic

备份 Hooks

Ark 支持在备份期间在 pod 的容器内执行命令。v0.7.0 之前只支持在所有自定义 action 处理之前执行的 "pre" hooks；v0.7.0 起新增 "post" hooks——在所有自定义 action 及其指定的附加项完成备份后执行。hooks 有两种指定方式：pod 上的注解（annotation）与 Backup spec。

Pod 注解方式（Pre hooks）：

Post hooks（v0.7.0+）：对应post.hook.backup.ark.heptio.com/container、post.hook.backup.ark.heptio.com/command、post.hook.backup.ark.heptio.com/on-error、post.hook.backup.ark.heptio.com/timeout，语义同上。

fsfreeze 示例：冻结文件系统可以确保打快照前所有挂起的磁盘 I/O 已完成。基于 examples/nginx-app/with-pv.yaml，原地给 pod 添加 pre/post hook 注解：

kubectl annotate pod -n nginx-example -l app=nginx \ pre.hook.backup.ark.heptio.com/command='["/sbin/fsfreeze", "--freeze", "/var/log/nginx"]' \ pre.hook.backup.ark.heptio.com/container=fsfreeze \ post.hook.backup.ark.heptio.com/command='["/sbin/fsfreeze", "--unfreeze", "/var/log/nginx"]' \ post.hook.backup.ark.heptio.com/container=fsfreeze

创建备份并用日志验证 hooks 正常执行：

ark backup create nginx-hook-test ark backup get nginx-hook-test ark backup logs nginx-hook-test | grep hookCommand

在 Backup spec 中定义 hooks 的方式参见 Backup API 类型文档，其核心结构为spec.hooks.resources[]下按pre/post组织exec类型 hook，支持container、command、onError、timeout等字段，并可用includedNamespaces、excludedNamespaces、includedResources、labelSelector限定适用范围。

Restic 集成：任意卷类型的备份恢复

自 v0.9.0 起，Ark 集成开源备份工具 restic，用于备份和恢复 Kubernetes 卷。此前 Ark 只支持通过云厂商块存储（AWS EBS、Azure Managed Disks、Google Persistent Disks）对持久卷打快照；restic 集成为用户提供了开箱即用地备份/恢复几乎任何类型 Kubernetes 卷（EFS、AzureFile、NFS、emptyDir、local 等没有原生快照概念的卷类型）的解决方案。这是 Ark 的新增能力，而非对现有功能的替代；hostPath 卷不支持，但新的 local 卷类型支持。

前置条件：已安装 Ark 0.10.0 及以上；Kubernetes 需启用 MountPropagation 特性（v1.10.0 起默认启用）。

安装：应用00-prereqs.yaml后，按平台创建 daemonset：

• AWS：kubectl apply -f config/aws/20-restic-daemonset.yaml
• Azure：kubectl apply -f config/azure/20-restic-daemonset.yaml
• GCP：kubectl apply -f config/gcp/20-restic-daemonset.yaml
• Minio：kubectl apply -f config/minio/30-restic-daemonset.yaml

备份：对每个包含待备份卷的 pod 添加注解，指定卷名列表（卷名为 pod spec 中的卷名）：

kubectl -n YOUR_POD_NAMESPACE annotate pod/YOUR_POD_NAME backup.ark.heptio.com/backup-volumes=YOUR_VOLUME_NAME_1,YOUR_VOLUME_NAME_2,...

例如对同时挂载 PVC 卷与 emptyDir 卷的 pod：

kubectl -n foo annotate pod/sample backup.ark.heptio.com/backup-volumes=pvc-volume,emptydir-volume

该注解也可放在 pod template spec 中（适用于由控制器管理的 pod）。随后执行ark backup create NAME OPTIONS...创建备份；备份完成后用ark backup describe YOUR_BACKUP_NAME或kubectl -n heptio-ark get podvolumebackups -l ark.heptio.com/backup-name=YOUR_BACKUP_NAME -o yaml查看卷备份详情。

恢复：执行ark restore create --from-backup BACKUP_NAME OPTIONS...，完成后用ark restore describe YOUR_RESTORE_NAME查看卷恢复详情。

排障、贡献与更新日志

• 排障：若遇到问题，可参考 troubleshooting 文档（调试安装问题见 debugging-install.md，恢复问题见 debugging-restores.md），或提交 issue、在 Kubernetes Slack 的 ark-dr 频道交流。
• 贡献：Ark 欢迎社区贡献。贡献前请先熟悉行为准则与 CONTRIBUTING.md（其中要求开发者证书 origin），项目使用 ZenHub 进行项目与路线图规划。欢迎提交 pull request，可浏览 issues 挑选任务。
• 更新日志：特性变更记录在 CHANGELOG.md 以及 changelogs/ 目录下的历史版本变更日志中。

结语：从 Ark v0.10.0 到 Velero

v0.10.0 是该项目历史上的一个关键节点：它废弃了单一的ConfigCRD，确立了BackupStorageLocation与VolumeSnapshotLocation双位置体系，为后来的多存储位置、备份复制等能力打下基础。项目此后由 Heptio Ark 更名为 Velero，这一设计理念至今延续——当前仓库中的 CRD 定义（config/crd/v1）与控制器实现（pkg/controller）仍能清晰地看到 v0.10.0 文档所描述的架构脉络。无论你是要研究 Velero 的历史演进，还是准备在真实集群中搭建备份恢复体系，理解 v0.10.0 的这套机制都是一条很有价值的路径。

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