ArkVelero 前身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 为核心骨架系统讲解 ArkVelero 的早期名称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.mdGCP 接入site/content/docs/v0.7.0/gcp-config.mdAzure 接入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.mdArk 定义了自己的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: false2.2 主配置参数表务必逐项理解Key类型默认值含义persistentVolumeProviderCloudProviderConfig无可选集群持久卷所使用的云厂商规格用于 PV 快照。若不指定请求 PV 快照的备份与恢复会被视为无效。注意Azure 需要 Kubernetes 集群版本 1.7.2 才支持其托管磁盘的 PV 快照persistentVolumeProvider/nameString无可选持久卷所在云厂商名。Ark 原生支持aws、gcp、azure其他厂商可通过外部插件接入persistentVolumeProvider/configmap[string]string无可选传递给云厂商的持久卷配置键值对各厂商键不同见下文backupStorageProviderCloudProviderConfig必填实际存储备份文件的云厂商规格backupStorageProvider/nameString必填备份存储云厂商名原生支持aws、gcp、azurebackupStorageProvider/bucketString必填备份上传的存储桶名backupStorageProvider/configmap[string]string无可选备份存储的厂商配置键值对backupSyncPeriodmetav1.Duration60m0sArk 查询对象存储、为已有备份文件补建 Backup 资源的频率gcSyncPeriodmetav1.Duration60m0sArk 查询对象存储、清理已过 TTL 备份文件的频率scheduleSyncPeriodmetav1.Duration1m0sArk 检查 Schedule 资源、判断是否需要发起新备份的频率resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps]资源恢复顺序的有序列表支持RESOURCE.GROUP格式不在列表中的资源在所有优先级资源之后恢复restoreOnlyModeboolfalse开启后备份、Schedule 与过期备份删除功能全部关闭仅从对象存储中的既有备份文件执行恢复2.3 各云厂商的 Config 专属参数AWS及 S3 兼容存储——backupStorageProvider/configKey类型默认值含义regionstring必填例us-east-1s3ForcePathStyleboolfalse使用 Minio 等本地存储服务时设为trues3Urlstring非 AWS 托管存储必填例http://minio:9000主要用于本地存储服务AWS S3 场景可由region与bucket自动推导kmsKeyIdstring空AWS KMS key id 或别名用于加密 S3 中的备份仅 AWS S3 生效AWS——persistentVolumeProvider/config仅需region必填。GCPbackupStorageProvider/config无需任何参数persistentVolumeProvider/config需要project必填例project-example-3jsn23。AzurebackupStorageProvider/config无需任何参数persistentVolumeProvider/config需要location必填例Canada East与apiTimeout默认2m0sAzure API 请求超时时间。2.4 在自定义命名空间中运行 Ark自 v0.7.0 起Ark 可运行在任意命名空间做法分两步详见 site/content/docs/v0.7.0/namespace.md修改示例 YAML 中的命名空间仓库示例默认使用heptio-ark。所有云厂商都需要编辑定义命名空间、ServiceAccount 与 RBAC 的公共前置文件v0.7.0 中为examples/common/00-prereqs.yaml再分别编辑各自的部署与配置文件同时把 Config 的metadata.namespace一并改掉。在客户端命令中指定命名空间ark client config set namespaceNAMESPACE_VALUE三、云厂商接入要点AWS / GCP / Azure3.1 AWSS3 桶 IAM 用户 凭证 Secret创建 S3 桶aws s3api create-bucket \ --bucket YOUR_BUCKET \ --region YOUR_REGION \ --create-bucket-configuration LocationConstraintYOUR_REGION注意us-east-1不支持LocationConstraint该区域直接省略桶配置参数即可。创建 IAM 用户并附加策略AmazonS3FullAccess与AmazonEC2FullAccess然后aws iam create-access-key生成访问密钥。在本地创建凭证文件credentials-ark[default] aws_access_key_idAWS_ACCESS_KEY_ID aws_secret_access_keyAWS_SECRET_ACCESS_KEY部署公共前置并创建名为cloud-credentials的 Secretkubectl apply -f examples/common/00-prereqs.yaml kubectl create secret generic cloud-credentials \ --namespace ARK_NAMESPACE \ --from-file cloudcredentials-ark替换示例文件中的占位符在 v0.7.0 的examples/aws/00-ark-config.yaml中替换YOUR_BUCKET与YOUR_REGION在examples/common/10-deployment.yaml中确认环境变量名为AWS_SHARED_CREDENTIALS_FILE。启动服务器kubectl apply -f examples/aws/00-ark-config.yaml kubectl apply -f examples/common/10-deployment.yaml3.2 GCPGCS 桶 Service Account 凭证 Secret创建 GCS 桶gsutil mb gs://YOUR_BUCKET/创建专用 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生成密钥文件gcloud iam service-accounts keys create credentials-ark --iam-account $SERVICE_ACCOUNT_EMAIL部署前置并创建 Secret命令与 AWS 相同--from-file cloudcredentials-ark在 v0.7.0 的examples/gcp/00-ark-config.yaml中替换YOUR_BUCKET与YOUR_PROJECT并把部署中的环境变量名改为GOOGLE_APPLICATION_CREDENTIALS。若使用 GKE需确保当前 IAM 用户是 cluster-admin创建 RBAC 对象所需。3.3 Azure存储账户 Blob 容器 Service Principal 七个环境变量Azure 场景是三个厂商中环境变量最复杂的必须设置七个环境变量Ark 才能正常工作。创建资源组、存储账户与名为ark的 Blob 容器示例将存储账户放在独立的Ark_Backups资源组并使用Standard_GRS、--https-only true、--kind BlobStorage、--access-tier Hot随后取出存储访问密钥存入$AZURE_STORAGE_KEY。创建Contributor角色的 Service Principalaz ad sp create-for-rbac --name heptio-ark --role Contributor并取得AZURE_CLIENT_ID。关键警告AZURE_RESOURCE_GROUP必须设置为创建集群时自动生成的第二个资源组——集群在第一个资源组中创建但磁盘部署在第二个资源组中。可用az group list确认。将七个环境变量全部写入 Secretkubectl 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}在 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。按文档步骤操作启动示例应用kubectl apply -f examples/nginx-app/base.yaml创建备份--include-namespaces限定只备份目标命名空间ark backup create nginx-backup --include-namespaces nginx-example模拟灾难——删除整个命名空间kubectl delete namespaces nginx-example等待命名空间被彻底删除。恢复丢失的资源ark restore create nginx-backup完成以上四步即可验证 Ark 的备份 → 灾难 → 恢复闭环。五、快照示例带 PV 应用的备份与恢复第二套示例用于验证持久卷快照能力清单为 examples/nginx-app/with-pv.yaml。它在前一版的基础上增加了一个 50Mi 的 PVCnginx-logsReadWriteOnce并挂载到 nginx 的/var/log/nginx日志目录。前置注意使用 Azure 时你的 Kubernetes 集群需要 1.7.2 版本才能支持其托管磁盘的 PV 快照。操作流程与基本示例一致但有一个关键差异点启动示例应用若是云厂商环境可先替换 PVC 中的storageClassName占位符AWS 默认 StorageClass 为gp2GCP 为standardkubectl apply -f examples/nginx-app/with-pv.yaml创建带 PV 快照的备份ark backup create nginx-backup --include-namespaces nginx-example模拟灾难并验证云端磁盘已删除kubectl delete namespaces nginx-example由于动态供给 PV 的默认 [reclaim policy] 为Delete上述命令会触发云厂商删除 PV 底层的磁盘。该删除过程是异步的可能需要一段时间。在进入下一步之前务必到云厂商控制台确认磁盘已不存在——否则恢复验证将失去意义。恢复ark restore create nginx-backup5.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.goNewCreateCommand第 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考