企业官网建设流程全解析

Ark（Velero 前身）v0.7.0 云厂商部署与备份恢复实战：基于 cloud-common 文档与 nginx 示例的完整指南

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

本指南以仓库内历史文档 site/content/docs/v0.7.0/cloud-common.md 为核心骨架，系统讲解 Ark（Velero 的早期名称，v0.7.0 时代 CLI 名为ark，后更名为velero）在 AWS、GCP、Azure 三种云厂商环境下的服务器配置思路、在任意命名空间运行的要求，以及如何使用仓库自带的 nginx 示例应用完成"无 PV"与"带 PV 快照"两套备份/恢复演练。读完本文，你将掌握 Ark 服务器云厂商接入的整体流程、Config 自定义资源的核心参数语义，以及一条可复制、可验证的端到端备份恢复操作链路，并了解这些操作在 pkg/cmd/cli 源码层面的实现依据。

一、cloud-common 文档定位：云厂商部署的公共入口

在 Ark v0.7.0 的文档体系中，cloud-common.md是所有云厂商部署指南的公共入口。它的核心观点可以概括为：

要让 Ark 服务器在某个云厂商上运行，你需要为 Ark 服务器指定厂商相关的配置（provider-specific settings）。

这些配置通过 Ark 自定义的Config资源对象下发，而每个云厂商的具体接入步骤，则由仓库中一组示例 YAML 文件和对应的分篇文档承载：

• AWS 接入：site/content/docs/v0.7.0/aws-config.md
• GCP 接入：site/content/docs/v0.7.0/gcp-config.md
• Azure 接入：site/content/docs/v0.7.0/azure-config.md

此外，v0.7.0 起 Ark 支持在任意命名空间中运行（不再局限于默认的heptio-ark命名空间），这需要额外的定制，详见 site/content/docs/v0.7.0/namespace.md。这一点在后续部署每个云厂商时都会反复遇到。

二、部署前的公共前置：Config 自定义资源与命名空间定制

2.1 Config 是 Ark 服务器的"配置开关"

根据 site/content/docs/v0.7.0/config-definition.md，Ark 定义了自己的Config对象（一个 Custom Resource）来承载备份与云厂商设置。Ark 服务器首次部署后会一直等待你创建一个名为default、位于heptio-ark命名空间的 Config 才开始工作。

一个完整的 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

2.2 主配置参数表（务必逐项理解）

2.3 各云厂商的 Config 专属参数

AWS（及 S3 兼容存储）——backupStorageProvider/config：

AWS——persistentVolumeProvider/config：仅需region（必填）。

GCP：backupStorageProvider/config无需任何参数；persistentVolumeProvider/config需要project（必填，例：project-example-3jsn23）。

Azure：backupStorageProvider/config无需任何参数；persistentVolumeProvider/config需要location（必填，例：Canada East）与apiTimeout（默认2m0s，Azure API 请求超时时间）。

2.4 在自定义命名空间中运行 Ark

自 v0.7.0 起，Ark 可运行在任意命名空间，做法分两步（详见 site/content/docs/v0.7.0/namespace.md）：

1. 修改示例 YAML 中的命名空间：仓库示例默认使用heptio-ark。所有云厂商都需要编辑定义命名空间、ServiceAccount 与 RBAC 的公共前置文件（v0.7.0 中为examples/common/00-prereqs.yaml），再分别编辑各自的部署与配置文件；同时把 Config 的metadata.namespace一并改掉。

2. 在客户端命令中指定命名空间：

   ark client config set namespace=<NAMESPACE_VALUE>

三、云厂商接入要点（AWS / GCP / Azure）

3.1 AWS：S3 桶 + IAM 用户 + 凭证 Secret

1. 创建 S3 桶：

   aws s3api create-bucket \ --bucket <YOUR_BUCKET> \ --region <YOUR_REGION> \ --create-bucket-configuration LocationConstraint=<YOUR_REGION>

   注意：us-east-1不支持LocationConstraint，该区域直接省略桶配置参数即可。

2. 创建 IAM 用户并附加策略（AmazonS3FullAccess与AmazonEC2FullAccess），然后aws iam create-access-key生成访问密钥。

3. 在本地创建凭证文件credentials-ark：

   [default] aws_access_key_id=<AWS_ACCESS_KEY_ID> aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

4. 部署公共前置，并创建名为cloud-credentials的 Secret：

   kubectl apply -f examples/common/00-prereqs.yaml kubectl create secret generic cloud-credentials \ --namespace <ARK_NAMESPACE> \ --from-file cloud=credentials-ark

5. 替换示例文件中的占位符：在 v0.7.0 的examples/aws/00-ark-config.yaml中替换<YOUR_BUCKET>与<YOUR_REGION>；在examples/common/10-deployment.yaml中确认环境变量名为AWS_SHARED_CREDENTIALS_FILE。

6. 启动服务器：

   kubectl apply -f examples/aws/00-ark-config.yaml kubectl apply -f examples/common/10-deployment.yaml

3.2 GCP：GCS 桶 + Service Account + 凭证 Secret

1. 创建 GCS 桶：gsutil mb gs://<YOUR_BUCKET>/

2. 创建专用 Service Accountheptio-ark，并绑定两个角色：

   gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \ --role roles/compute.storageAdmin gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$SERVICE_ACCOUNT_EMAIL \ --role roles/storage.admin

3. 生成密钥文件：gcloud iam service-accounts keys create credentials-ark --iam-account $SERVICE_ACCOUNT_EMAIL

4. 部署前置并创建 Secret（命令与 AWS 相同，--from-file cloud=credentials-ark）；在 v0.7.0 的examples/gcp/00-ark-config.yaml中替换<YOUR_BUCKET>与<YOUR_PROJECT>，并把部署中的环境变量名改为GOOGLE_APPLICATION_CREDENTIALS。

5. 若使用 GKE，需确保当前 IAM 用户是 cluster-admin（创建 RBAC 对象所需）。

3.3 Azure：存储账户 + Blob 容器 + Service Principal + 七个环境变量

Azure 场景是三个厂商中环境变量最复杂的：必须设置七个环境变量Ark 才能正常工作。

1. 创建资源组、存储账户与名为ark的 Blob 容器（示例将存储账户放在独立的Ark_Backups资源组，并使用Standard_GRS、--https-only true、--kind BlobStorage、--access-tier Hot），随后取出存储访问密钥存入$AZURE_STORAGE_KEY。

2. 创建Contributor角色的 Service Principal（az ad sp create-for-rbac --name "heptio-ark" --role "Contributor"），并取得AZURE_CLIENT_ID。

3. 关键警告：AZURE_RESOURCE_GROUP必须设置为创建集群时自动生成的第二个资源组——集群在第一个资源组中创建，但磁盘部署在第二个资源组中。可用az group list确认。

4. 将七个环境变量全部写入 Secret：

   kubectl create secret generic cloud-credentials \ --namespace <ARK_NAMESPACE> \ --from-literal AZURE_SUBSCRIPTION_ID=${AZURE_SUBSCRIPTION_ID} \ --from-literal AZURE_TENANT_ID=${AZURE_TENANT_ID} \ --from-literal AZURE_RESOURCE_GROUP=${AZURE_RESOURCE_GROUP} \ --from-literal AZURE_CLIENT_ID=${AZURE_CLIENT_ID} \ --from-literal AZURE_CLIENT_SECRET=${AZURE_CLIENT_SECRET} \ --from-literal AZURE_STORAGE_ACCOUNT_ID=${AZURE_STORAGE_ACCOUNT_ID} \ --from-literal AZURE_STORAGE_KEY=${AZURE_STORAGE_KEY}

5. 在 v0.7.0 的examples/azure/10-ark-config.yaml中替换<YOUR_BUCKET>、<YOUR_LOCATION>、<YOUR_TIMEOUT>。文档给出的完整配置示例如下：

   apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default persistentVolumeProvider: name: azure config: location: "West US" apiTimeout: 15m backupStorageProvider: name: azure bucket: ark backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false

四、基本示例：无 PV 应用的备份与恢复

部署好 Ark 服务器后，先用无持久卷的应用验证最基础的备份/恢复链路。仓库中对应的清单为 examples/nginx-app/base.yaml，它在nginx-example命名空间下定义了：

• 一个nginx-exampleNamespace；
• 一个 2 副本的 nginx Deployment（镜像nginx:1.17.6，暴露容器端口 80）；
• 一个LoadBalancer类型的my-nginxService。

按文档步骤操作：

1. 启动示例应用：

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

2. 创建备份（--include-namespaces限定只备份目标命名空间）：

   ark backup create nginx-backup --include-namespaces nginx-example

3. 模拟灾难——删除整个命名空间：

   kubectl delete namespaces nginx-example

   等待命名空间被彻底删除。

4. 恢复丢失的资源：

   ark restore create nginx-backup

完成以上四步，即可验证 Ark 的"备份 → 灾难 → 恢复"闭环。

五、快照示例：带 PV 应用的备份与恢复

第二套示例用于验证持久卷快照能力，清单为 examples/nginx-app/with-pv.yaml。它在前一版的基础上增加了一个 50Mi 的 PVCnginx-logs（ReadWriteOnce），并挂载到 nginx 的/var/log/nginx日志目录。

前置注意：使用 Azure 时，你的 Kubernetes 集群需要 1.7.2+ 版本才能支持其托管磁盘的 PV 快照。

操作流程与基本示例一致，但有一个关键差异点：

1. 启动示例应用（若是云厂商环境，可先替换 PVC 中的storageClassName占位符，AWS 默认 StorageClass 为gp2，GCP 为standard）：

   kubectl apply -f examples/nginx-app/with-pv.yaml

2. 创建带 PV 快照的备份：

   ark backup create nginx-backup --include-namespaces nginx-example

3. 模拟灾难并验证云端磁盘已删除：

   kubectl delete namespaces nginx-example

   由于动态供给 PV 的默认 [reclaim policy] 为Delete，上述命令会触发云厂商删除 PV 底层的磁盘。该删除过程是异步的，可能需要一段时间。在进入下一步之前，务必到云厂商控制台确认磁盘已不存在——否则"恢复"验证将失去意义。

4. 恢复：

   ark restore create nginx-backup

5.1 从当前仓库看 with-pv.yaml 的细节

值得说明的是，当前仓库中的 examples/nginx-app/with-pv.yaml 相比 v0.7.0 文档年代又补充了两处值得关注的实现细节：

• fsfreeze 钩子注解：Deployment 上带有pre.hook.backup.velero.io/container/pre.hook.backup.velero.io/command与对应的post.hook.*注解，备份前通过特权容器fsfreeze对/var/log/nginx执行冻结、备份后解冻，确保文件系统快照的一致性；
• 双容器编排：nginx 容器之外还运行着一个ubuntu:bionic的fsfreeze侧车容器，专门承担挂载卷的冻结/解冻动作。

这印证了"带 PV 的备份"在真实场景中不仅要快照数据，还要通过钩子保证快照时数据处于一致状态，可作为阅读 site/content/docs/v0.7.0/hooks.md 钩子机制的实战入口。

六、源码层面的印证：备份与恢复命令的实现依据

上述演练中的核心命令ark backup create ... --include-namespaces ...与ark restore create ...在当前仓库的 CLI 实现中均有对应：

• 备份命令定义在 pkg/cmd/cli/backup/create.go（NewCreateCommand，第 43 行起）。其命令Example部分（第 69–85 行）给出的用法示例与本指南一致，例如# Create a backup including only the nginx namespace. velero backup create nginx-backup --include-namespaces nginx（当前仓库中 CLI 已更名为velero）。
• CreateOptions结构体（第 101 行起）中通过IncludeNamespaces flag.StringArray（第 108 行）声明了--include-namespaces参数，支持逗号分隔的多命名空间，与文档中的用法一一对应。
• 恢复命令对应 pkg/cmd/cli/restore/create.go，同样接收一个备份名作为参数执行恢复。

这意味着你在 v0.7.0 文档中学到的操作语法在今天的 Velero CLI 中仍然延续，只是命令前缀由ark变为velero。

七、版本差异提示：仓库示例目录的现状

v0.7.0 文档提到的examples/common/00-prereqs.yaml、examples/aws/、examples/gcp/、examples/azure/等云厂商示例目录属于该历史版本的布局。在当前仓库中，examples 目录仅保留了：

• minio/：本地 S3 兼容存储服务，用于不绑定具体云厂商的快速体验；
• nginx-app/：本文使用的两套 nginx 示例清单。

因此，本文中涉及 v0.7.0 云厂商示例文件名的部分属于历史文档事实；如要在当前版本实操，请以当前仓库 examples 与最新版官方文档为准，并注意当前代码的 API 版本与 Config 字段已随版本演进（当前 CRD 定义可参考 config/crd/v1）。演练类示例（nginx 应用）则可以原样复用，examples/nginx-app/README.md 也明确说明了base.yaml可直接部署、with-pv.yaml需先替换<YOUR_STORAGE_CLASS_NAME>占位符。

八、小结

围绕 site/content/docs/v0.7.0/cloud-common.md，本文完整串联了 Ark v0.7.0 云厂商部署的整条链路：先从Config自定义资源理解服务器级配置（含三个云厂商的专属参数），再依次走通 AWS/GCP/Azure 的桶与凭证准备、自定义命名空间定制，最后通过base.yaml与with-pv.yaml两套 nginx 示例完成"无 PV"与"带 PV 快照"的备份—灾难—恢复闭环。同时，我们以当前仓库的 pkg/cmd/cli/backup/create.go 与 examples/nginx-app 源码为佐证，确认了文档中的命令语法与钩子机制在演进后的 Velero 代码库中依然有迹可循。对任何想理解"云上 Kubernetes 应用备份恢复如何落地"的读者，这套 v0.7.0 文档 + 示例 + 源码的三角对照，都是一条低门槛、可验证的学习路径。

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