ArkVelero 前身Azure 部署实战存储账户、服务主体与备份配置全解析【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero本文基于 Velero 仓库中 v0.8.0 版本的官方文档《Run Ark on Azure》系统讲解如何在 Microsoft Azure 上部署 ArkVelero 的早期名称以备份和迁移 Kubernetes 应用及其持久化卷。文章将完整覆盖存储账户与 Blob 容器的创建、服务主体的申请、七个关键环境变量的配置、凭据 Secret 与 Config 自定义资源的编写并结合当前仓库的源码实现与新版velero install命令帮助读者掌握一套从零到可用的 Azure 备份环境搭建方案。说明Ark 是 Velero 项目在 0.8.x 及更早版本时代的名称v0.9 之后正式更名为 Velero。本仓库的 site/content/docs/v0.8.0/ 目录仍完整保留着 Ark 时代的官方文档azure-config.md 即为本文的核心依据。Ark 与 Azure 的集成方式在 Ark 0.8.0 的设计中Azure 承担两个角色persistentVolumeProvider负责对 Kubernetes 集群中的持久化卷Managed Disks执行快照从而实现基于云快照的 PV 备份与恢复backupStorageProvider负责把备份数据上传到 Azure 存储账户的 Blob 容器中。因此整套配置可以归纳为四个步骤也是本文的组织脉络创建 Azure 存储账户与 Blob 容器为 Ark 创建 Azure 服务主体Service Principal配置 Ark 服务端Config 自定义资源将凭据封装为 Kubernetes Secret 供服务端使用。前置条件开始前需要满足以下两个层面的准备本地环境Azure CLI 2.0Ark 的全部云资源准备操作都通过az命令行完成。如果本地尚未安装 Azure CLI 2.0请先参考官方安装指南完成安装原文档外部链接然后登录az login登录成功后后续命令会使用当前账号的默认订阅若存在多个订阅可在各步骤中通过--subscription参数显式指定。Kubernetes 集群支持托管磁盘Managed Disks集群侧的硬性要求是agent pool 的 VM 必须允许使用 Managed Disks因为 Ark 的 PV 快照能力依赖 Azure 托管磁盘。如果对 I/O 性能敏感建议使用 SSD 后端、性能更好的 Premium Managed Disks。此外根据同一版本目录下的 config-definition.md 说明Azure 集群需要 Kubernetes 1.7.2 及以上版本才支持对托管磁盘执行 PV 快照。创建 Azure 存储账户与 Blob 容器Ark 需要一个存储账户Storage Account和其中的 Blob 容器来存放备份数据。存储账户既可以与 Kubernetes 集群位于同一资源组也可以独立放置官方示例选择将其放在单独的Ark_Backups资源组中便于后续单独管理备份资源。存储账户名必须是全局唯一的会被用于 DNS 解析示例巧妙地利用 Linux 内核的随机 UUID 来生成名字避免手工取名的麻烦。同时该存储账户具备以下特性静态加密encryption at rest使用微软托管密钥仅允许 HTTPS 访问Standard_GRS 冗余策略异地冗余存储与Hot 热访问层。完整命令如下# 创建用于存放备份存储账户的资源组可按需修改 Location AZURE_BACKUP_RESOURCE_GROUPArk_Backups az group create -n $AZURE_BACKUP_RESOURCE_GROUP --location WestUS # 创建存储账户名称用随机 UUID 生成以保证全局唯一 AZURE_STORAGE_ACCOUNT_IDarkcat /proc/sys/kernel/random/uuid | cut -d - -f5 az storage account create \ --name $AZURE_STORAGE_ACCOUNT_ID \ --resource-group $AZURE_BACKUP_RESOURCE_GROUP \ --sku Standard_GRS \ --encryption-services blob \ --https-only true \ --kind BlobStorage \ --access-tier Hot # 创建名为 ark 的 Blob 容器可改用其他名称 # 但需相应调整后面 Ark Config 中 backupStorageProvider 下的 bucket 字段 az storage container create -n ark --public-access off --account-name $AZURE_STORAGE_ACCOUNT_ID # 获取刚创建的存储账户的访问密钥Access Key AZURE_STORAGE_KEYaz storage account keys list \ --account-name $AZURE_STORAGE_ACCOUNT_ID \ --resource-group $AZURE_BACKUP_RESOURCE_GROUP \ --query [0].value \ -o tsv这里有几个值得留意的设计点--kind BlobStorage表示该账户专用于 Blob 存储--access-tier Hot适合频繁读写的备份场景若以冷归档为主可考虑Cool--public-access off确保容器不允许匿名访问备份数据不对外暴露存储访问密钥AZURE_STORAGE_KEY将被用于后续写入凭据 Secret是七环境变量之一。创建 Ark 专用的服务主体要让 Ark 与 Azure 交互读写 Blob、创建/删除磁盘快照必须为其创建一个专用的服务主体并在环境中设置七个环境变量。原文档明确强调这七个变量缺一不可。1. 获取订阅 ID 与租户 IDAZURE_SUBSCRIPTION_IDaz account list --query [?isDefault].id -o tsv AZURE_TENANT_IDaz account list --query [?isDefault].tenantId -o tsv两条命令分别从当前默认订阅中提取订阅 ID 和租户 ID。2. 设置集群资源组# 注意必须是第二个资源组的名称详见下方警告 AZURE_RESOURCE_GROUPNAME_OF_RESOURCE_GROUP_2警告原文档特别强调AZURE_RESOURCE_GROUP必须设置为创建集群时自动生成的第二个资源组的名称。在 Azure 上Kubernetes 集群本身位于你创建集群时指定的资源组而磁盘则被放置在第二个资源组中。设置错误将导致 Ark 无法定位磁盘、快照功能失效。如果不确定资源组名称可以执行以下命令列出候选然后取响应中的ResourceGroup值进行设置az group list --query [].{ ResourceGroup: name, Location:location }3. 创建带 Contributor 角色的服务主体# 方式一自行指定高熵密码 AZURE_CLIENT_SECRETsuper_secret_and_high_entropy_password_replace_me_with_your_own az ad sp create-for-rbac --name heptio-ark --role Contributor --password $AZURE_CLIENT_SECRET # 方式二让 CLI 自动生成密码务必保存输出的 password AZURE_CLIENT_SECRETaz ad sp create-for-rbac --name heptio-ark --role Contributor --query password -o tsv # 创建完成后获取客户端 ID AZURE_CLIENT_IDaz ad sp list --display-name heptio-ark --query [0].appId -o tsvContributor角色意味着该服务主体拥有订阅级别的访问权限原文档提醒必须妥善保护该凭据。至此七个环境变量已全部就绪环境变量用途AZURE_SUBSCRIPTION_ID订阅 ID标识云资源所属订阅AZURE_TENANT_ID租户 ID用于 AAD 认证AZURE_RESOURCE_GROUP放置集群磁盘的第二个资源组AZURE_CLIENT_ID服务主体应用 IDAZURE_CLIENT_SECRET服务主体密码AZURE_STORAGE_ACCOUNT_ID存储账户名称AZURE_STORAGE_KEY存储账户访问密钥凭据与配置创建基础脚手架在 Ark 根目录下首先应用examples/common/00-prereqs.yaml以创建 Ark 所需的命名空间、CRDCustomResourceDefinition、ServiceAccount 与 RBAC 规则。若要在自定义命名空间中运行需先修改该 YAML 中的命名空间字段详见自定义命名空间文档。kubectl apply -f examples/common/00-prereqs.yaml该文件属于 Ark 0.8.0 时代仓库布局examples/目录当前版本仓库已将该目录调整为 examples/包含 MinIO 与 nginx-app 示例部署脚手架改为由velero install命令或新版安装清单动态生成。将七环境变量写入 Secret接着创建一个名为cloud-credentials的 Secret把前面设置的七个环境变量全部以--from-literal方式注入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}这里的ARK_NAMESPACE要与前面脚手架中的命名空间保持一致。在 自定义命名空间文档 中可以看到该 Secret 必须创建在 Ark 运行的命名空间内。源码印证这七个环境变量名与当前仓库中的实现完全一致。pkg/util/azure/util.go 定义了这些凭据键常量包括CredentialKeySubscriptionID AZURE_SUBSCRIPTION_ID、CredentialKeyResourceGroup AZURE_RESOURCE_GROUP、CredentialKeyTenantID AZURE_TENANT_ID、CredentialKeyClientID AZURE_CLIENT_ID、CredentialKeyClientSecret AZURE_CLIENT_SECRET、CredentialKeyStorageAccountAccessKey AZURE_STORAGE_KEY等。同一文件中的LoadCredentials()展示了现代版本如何从凭据文件默认取环境变量AZURE_CREDENTIALS_FILE也可由 BSL 配置中的credentialsFile指定读取这些键值对——这说明如今 Velero 更多采用凭据文件 键值对的方式而 Ark 0.8.0 时代的--from-literal方式是其直接前身。值得补充的是现代实现还支持更多扩展凭据键AZURE_CLOUD_NAMEAzure 云环境支持AzureCloud/AzureChinaCloud/AzureUSGovernment、AZURE_CLIENT_CERTIFICATE等详见 util.go 的常量定义与getCloudConfiguration()的云环境解析逻辑。修改 Config 模板凭据就绪后需要修改模板文件examples/azure/10-ark-config.yaml替换其中的YOUR_BUCKET与YOUR_TIMEOUT占位符YOUR_BUCKET即前面创建的 Blob 容器名示例中为arkYOUR_TIMEOUTAzure API 调用超时时间完整参数说明见 config-definition.md 的 Azure 一节。原文档给出的一份完成态示例配置如下apiVersion: ark.heptio.com/v1 kind: Config metadata: namespace: heptio-ark name: default persistentVolumeProvider: name: azure config: apiTimeout: 15m backupStorageProvider: name: azure bucket: ark backupSyncPeriod: 30m gcSyncPeriod: 30m scheduleSyncPeriod: 1m restoreOnlyMode: false对照 config-definition.md 的参数参考表可以这样理解各字段字段说明默认值persistentVolumeProvider.name持久化卷云厂商原生支持aws/gcp/azure无可选persistentVolumeProvider.config.apiTimeoutAzure API 请求超时时间例中设为15m2m0sbackupStorageProvider.name备份存储厂商此处为azure必填backupStorageProvider.bucket存放备份的存储桶/容器名必填backupSyncPeriod多久扫描一次对象存储为已有备份文件补建 Backup 资源60mgcSyncPeriod多久清理一次已超过 TTL 的备份文件60mscheduleSyncPeriod多久检查一次 Schedule 资源以触发定时备份1mrestoreOnlyMode开启后禁用备份/调度/过期删除仅从对象存储恢复falsepersistentVolumeProvider.config下 Azure 独有的参数即为apiTimeout而backupStorageProvider.config在 Ark 0.8.0 的 Azure 场景下无需任何参数。关于 Config 对象的一个机制细节config-definition.md 还揭示了 Config 的生效机制Ark 服务端首次部署后会等待一个名为default的 Config 出现在heptio-ark命名空间中才继续工作一旦该 Config 被修改服务端会优雅退出待 kubelet 重启 Pod 后再读取新值。这意味着修改配置后无需手动重启但要有短暂的滚动重启预期。启动 Ark 服务端完成 Secret 与 Config 的准备后在 Ark 根目录执行kubectl apply -f examples/azure/该命令会应用examples/azure/目录下的所有清单Config 模板、Deployment 等将 Ark 服务端部署到集群。部署完成后即可通过ark backup create、ark restore create等命令执行备份与恢复。作为参考cloud-common.md 提供了无 PV 与带 PV 快照两套 nginx 示例演练流程创建备份 → 删除命名空间模拟灾难 → 从备份恢复可用于验证 Azure 配置是否生效。现代 Velero 的 Azure 安装方式当前仓库Ark 0.8.0 之后Velero 引入了velero install一键式命令把存储账户/容器 服务主体 Secret Config的流程收敛为一条 CLI。当前仓库的 velero-install.md 给出了 Azure 的推荐用法velero install --provider azure \ --plugins velero/velero-plugin-for-microsoft-azure:v1.0.0 \ --bucket $BLOB_CONTAINER \ --secret-file ./credentials-velero \ --backup-location-config resourceGroup$AZURE_BACKUP_RESOURCE_GROUP,storageAccount$AZURE_STORAGE_ACCOUNT_ID[,subscriptionId$AZURE_BACKUP_SUBSCRIPTION_ID] \ --snapshot-location-config apiTimeoutYOUR_TIMEOUT[,resourceGroup$AZURE_BACKUP_RESOURCE_GROUP,subscriptionId$AZURE_BACKUP_SUBSCRIPTION_ID]可以明显看到从 Ark 到 Velero 的演进痕迹--bucket对应原 Config 中的bucket字段--snapshot-location-config apiTimeout...对应原persistentVolumeProvider.config.apiTimeout默认2m--backup-location-config的resourceGroup/storageAccount/subscriptionId分别对应原配置中依赖的环境变量职责--secret-file取代kubectl create secret凭据以每行一个KEYVALUE的 dotenv 文件提供其中的键名仍是上述七个环境变量名。这正是 pkg/util/azure/util.go 中LoadCredentials()所解析的文件格式。从源码层面看当前仓库的 pkg/util/azure/storage.go 定义了 BSLBackupStorageLocation侧的 Azure 配置键与安装命令的参数一一对应BSLConfigResourceGroup resourceGroup BSLConfigStorageAccount storageAccount BSLConfigStorageAccountAccessKeyName storageAccountKeyEnvVar BSLConfigSubscriptionID subscriptionId BSLConfigStorageAccountURI storageAccountURI BSLConfigUseAAD useAAD BSLConfigActiveDirectoryAuthorityURI activeDirectoryAuthorityURI其中useAAD允许改用 Azure AD 认证替代存储账户访问密钥storageAccountKeyEnvVar用于指定访问密钥对应的凭据键名。对应的单元测试 storage_test.go 覆盖了三种认证路径访问密钥认证、AAD 认证以及缺少订阅 ID/资源组时的错误处理可作为理解这些配置键行为的参考。velero install的参数定义则集中在 pkg/cmd/cli/install/install.go 的Options结构体中ProviderName、BucketName、BackupStorageConfig、VolumeSnapshotConfig、SecretFile等字段。常见问题与配置要点回顾综合 Ark 0.8.0 文档与源码实现部署中最容易出错、也最值得确认的要点如下资源组别搞错AZURE_RESOURCE_GROUP必须指向存放磁盘的第二个资源组这是 Azure 上 PV 快照能否成功的命门存储账户全局唯一账户名参与 DNS 解析务必全局唯一示例用 UUID 生成七个环境变量缺一不可从订阅 ID 到存储密钥共七个变量必须全部注入 Secret或凭据文件现代实现中的LoadCredentials()会逐一读取Config 必须命名为defaultArk 服务端启动后等待名为default的 Config其apiTimeout默认仅 2 分钟对超大规模 PV 或高延迟环境建议调大官方示例用 15 分钟集群版本门槛Azure 托管磁盘快照需要 Kubernetes 1.7.2且 agent 节点必须使用 Managed Disks。掌握上述流程后无论是回看 Ark 0.8.0 时代的手工配置还是直接使用当前仓库推荐的velero install --provider azure都能快速在 Azure 上搭建一套可靠的 Kubernetes 备份与迁移环境。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考