VeleroHeptio Arkv0.8.0 快速上手基于 Minio 的 Kubernetes 备份与恢复完整实战指南【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero导读本文以 Velero 前身 Heptio Ark 的 v0.8.0 版本文档site/content/docs/v0.8.0/_index.md为骨架完整复现一套「零成本本地演练」在 Kubernetes 集群内用 Minio 充当 S3 兼容对象存储从零部署 Ark Server 与客户端对一个带标签选择器的示例 nginx 应用执行备份、模拟灾难删除、再通过恢复命令将其原样还原。读完本文你将掌握 Ark/Velero 的备份、恢复、删除与清理全流程并理解其 Config 自定义资源的核心参数以及灾难恢复、跨集群迁移两个典型使用场景。Ark 是什么Kubernetes 备份与恢复工具概览Heptio Ark即 Velero 的前身是一套运行在 Kubernetes 生态中的备份与迁移工具其能力在 v0.8.0 文档中被归纳为三点备份与灾难恢复对集群资源Deployment、Service、Namespace 等及持久卷Persistent Volume进行备份在发生损失时恢复回到之前的可用状态跨云迁移将集群资源从一个集群复制到另一个集群注意v0.8.0 明确指出云厂商间的持久卷迁移暂不支持即Cloud volume migrations are not yet supported环境复制把生产环境复制一份用于开发与测试环境。从架构上看Ark 由两部分组成服务端Server以 Deployment 形式运行在集群中负责执行备份、恢复、快照等实际任务命令行客户端CLI运行在本地机器上通过ark命令与服务端交互。这意味着对象存储是备份数据的落脚点而集群内运行的服务端负责编排本地 CLI 只负责下发指令与查询状态。本文的演练就是围绕这一架构展开的。环境与前置条件按 v0.8.0 文档开始演练前需要满足一个可访问的 Kubernetes 集群版本 1.7 及以上其中执行ark backup delete需要1.7.5 及以上集群内已配置DNS 服务Ark 部署与 Minio 内部访问依赖 DNS 解析本机已安装kubectl并已配置好访问集群的 kubeconfig。获取 Ark 代码Ark 的源码通过 Git 克隆获取文档建议检出最新 tagged 版本因为主干分支main处于活跃开发中可能不稳定git clone gitgithub.com:heptio/ark.git说明在当前仓库中Ark 已演进为 Velero命令名从ark变为velero示例资源也从heptio-ark命名空间迁移到了velero命名空间详见 examples/minio/00-minio-deployment.yaml。本文保留 v0.8.0 文档的原始命令以示历史原貌并在相关小节给出仓库现状对照。部署 Ark Server 与本地对象存储 Minio为了简化演练、不依赖任何云厂商账号文档选用Minio——一个运行在集群内的 S3 兼容对象存储服务——作为备份数据的存储后端。在 Ark 仓库根目录执行kubectl apply -f examples/common/00-prereqs.yaml kubectl apply -f examples/minio/注若遇到 Config 创建相关的报错等待约一分钟后重试即可。 注examples/common/00-prereqs.yaml是 v0.8.0 时代的前置资源文件在当前仓库中已并入examples/minio/目录该目录下的清单自包含 Namespace 与所需 RBAC 资源因此当前仓库可直接执行kubectl apply -f examples/minio/完成同样的事。仓库中的 Minio 清单解析当前仓库的 examples/minio/00-minio-deployment.yaml 完整展示了这套本地存储后端的组成共三部分NamespaceveleroArk/Velero 服务端与 Minio 所在的命名空间Deploymentminio运行minio/minio:latest镜像以server /storage --config-dir/config启动数据挂载在emptyDir卷上环境变量MINIO_ACCESS_KEYminio、MINIO_SECRET_KEYminio123是后续云存储凭据的来源容器端口为 9000ServiceminioClusterIP:9000供集群内访问清单注释明确提示生产环境建议 ClusterIP只有 Minikube 等测试环境才改用 NodePortJobminio-setup用minio/mc客户端在启动后自动执行两件事——mc alias set velero http://minio:9000 minio minio123建立别名以及mc mb -p velero/velero创建名为velero的 bucket这正是后续备份数据上传的目标存储桶。部署示例应用 nginx备份不能没有对象文档使用一个带标签的示例应用作为演练目标kubectl apply -f examples/nginx-app/base.yaml该清单examples/nginx-app/base.yaml在nginx-example命名空间下创建了带app: nginx标签的Namespacenginx-example标签app: nginxDeploymentnginx-deployment2 个副本镜像nginx:1.17.6Servicemy-nginxLoadBalancer 类型端口 80。app: nginx这个标签正是后续--selector appnginx备份过滤的依据。验证部署结果kubectl get deployments -l componentark --namespaceheptio-ark kubectl get deployments --namespacenginx-example第一条命令确认 Ark 服务端已就绪在 v0.8.0 时期 Ark 组件带componentark标签第二条确认示例应用已运行。若按当前仓库清单演练可将第一条替换为kubectl get deployments -n velero当前仓库中 Minio 组件的标签为component: minio见 examples/minio/00-minio-deployment.yaml。安装命令行客户端服务端就绪后在本地安装ark客户端。文档推荐两种方式下载预编译的 release 二进制推荐对应 v0.8.0 的发布产物从源码自行构建对应文档中的 build-from-scratch 说明 所在章节。将客户端安装到$PATH中的某个目录即可直接使用ark命令。创建第一个备份标签选择器实战备份命令的核心形态是ark backup create NAME [flags]。本演练只备份带有appnginx标签的对象ark backup create nginx-backup --selector appnginxark backup create常用参数v0.8.0 的 CLI 参考文档site/content/docs/v0.8.0/cli-reference/ark_backup_create.md列出了完整参数常用者如下参数默认值说明-l, --selectornone只备份匹配该标签选择器的资源本演练即用它--include-namespaces*全部纳入备份的命名空间列表如--include-namespaces nginx-example--exclude-namespaces空从备份中排除的命名空间--include-resources/--exclude-resources*/ 空按resource.group格式如storageclasses.storage.k8s.io过滤资源类型--include-cluster-resourcestrue是否纳入集群级非命名空间级资源--snapshot-volumestrue是否对 PersistentVolume 做快照--labels空给备份对象附加的标签keyvalue形式--ttl720h30 天备份可被垃圾回收前的保留时长-o, --outputtable输出格式可为table/json/yamlcreate场景下仅展示对象而不发送到服务端-n, --namespaceheptio-arkArk 服务端所在命名空间其中--selector、--include-namespaces与--ttl是日常最常用的三个前者做精准备份、中间者限定备份范围、后者控制备份生命周期。模拟一场灾难备份完成后文档引导我们模拟集群事故——直接删除整个命名空间kubectl delete namespace nginx-example随后用三条命令确认资源确实已消失应无任何输出kubectl get deployments --namespacenginx-example kubectl get services --namespacenginx-example kubectl get namespace/nginx-example注意命名空间的清理可能需要几分钟属正常现象请耐心等待完全删除后再进入下一步。执行恢复把删掉的东西找回来在「灾难」现场只需一条命令即可从nginx-backup备份中恢复ark restore create --from-backup nginx-backupark restore create常用参数v0.8.0 的 CLI 参考文档site/content/docs/v0.8.0/cli-reference/ark_restore_create.md显示该命令支持自定义恢复名称与多种过滤/映射参数参数默认值说明--from-backup必填指定从哪个备份恢复[RESTORE_NAME]自动生成恢复名称可省略默认形如backup-timestamp--namespace-mappings空命名空间映射格式src1:dst1,src2:dst2,...用于把资源恢复到不同命名空间--include-namespaces/--exclude-namespaces*/ 空与备份命令同理限定恢复范围--include-resources/--exclude-resources*/ 空按资源类型过滤--include-cluster-resourcestrue是否恢复集群级资源--restore-volumestrue是否从快照恢复卷-l, --selectornone只恢复匹配标签选择器的资源查看恢复进度与结果ark restore get恢复期间状态列显示InProgress完成后变为Completed。文档给出了一个典型的输出样例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为Completed且WARNINGS与ERRORS均为0。此时nginx-example命名空间内的所有对象应已恢复到删除前的状态。注意恢复本身可能耗时数分钟期间状态列为InProgress属正常现象。深入排查ark restore describe若恢复报告了警告或错误可用ark restore describe RESTORE_NAME查看明细。v0.8.0 的调试文档site/content/docs/v0.8.0/debugging-restores.md详细解释了输出结构——无论结果好坏Ark 都会把状态置为Completed差异体现在 WARNINGS/ERRORS 两列的数字上典型输出如下Name: backup-test-20170726180512 Namespace: heptio-ark ... Backup: backup-test Namespaces: Included: * Excluded: none Resources: Included: serviceaccounts Excluded: nodes, events, events.events.k8s.io Cluster-scoped: auto Namespace mappings: none Label selector: none Restore PVs: auto Phase: Completed Validation errors: none Warnings: Ark: none Cluster: none Namespaces: kube-system: serviceaccounts attachdetach-controller already exists ... Errors: Ark: none Cluster: none Namespaces: none错误与警告按同样结构组织分三层ArkArk 服务端自身的系统性问题如无法读取目录Cluster集群级cluster-scoped资源恢复时遇到的问题Namespaces以命名空间为键的映射列出各命名空间内资源恢复的问题。错误Errors代表恢复不完整或部分失败警告Warnings则是非阻塞问题——比如上例中大量serviceaccounts xxx already exists表示资源已存在、恢复逻辑跳过但整体依然正常。清理删除备份与卸载删除备份数据ark backup delete BACKUP_NAME会请求 Ark 服务端删除与指定备份关联的全部数据——包括对象存储中的备份文件和持久卷快照ark backup delete BACKUP_NAME相关 CLI 文档site/content/docs/v0.8.0/cli-reference/ark_backup_delete.md显示该命令需要--confirm标志确认删除。注意事项每个需要删除的备份都必须单独执行一次v0.8.0 文档说明未来版本将支持按名称或标签选择器批量删除删除彻底完成后ark backup get BACKUP_NAME将不再看到该备份。保留数据地卸载 Ark如果只想卸载 Ark 而保留对象存储与快照中的备份数据可以安全地删除演练创建的所有资源kubectl delete -f examples/common/ kubectl delete -f examples/minio/ kubectl delete -f examples/nginx-app/base.yaml进阶Config 自定义资源与核心参数Ark 通过自定义资源Config一个名为default、位于heptio-ark命名空间的对象来指定云存储与备份行为。服务端首次启动后会一直等待defaultConfig 创建完成若运行中修改 Config服务端会优雅退出待 kubelet 重启 Pod 后应用新配置。完整的参数参考见 site/content/docs/v0.8.0/config-definition.md其核心字段如下字段类型默认值含义persistentVolumeProviderCloudProviderConfig无可选持久卷所在云厂商用于快照。若不配置请求 PV 快照的备份/恢复会被判定为无效persistentVolumeProvider/nameString无原生支持aws/gcp/azure其他厂商可通过外部插件支持backupStorageProviderCloudProviderConfig必填实际存放备份的云存储厂商backupStorageProvider/nameString必填备份存储厂商名backupStorageProvider/bucketString必填备份上传的目标存储桶backupSyncPeriodDuration60mArk 轮询对象存储、为既有备份文件创建对应 Backup 资源的频率gcSyncPeriodDuration60m轮询对象存储、清理已过 TTL 的备份文件的频率scheduleSyncPeriodDuration1m检查 Schedule 资源、判断是否需触发备份的频率resourcePriorities[]string[namespaces, persistentvolumes, persistentvolumeclaims, secrets, configmaps]恢复资源的先后顺序不在列表中的资源在所有优先资源之后恢复restoreOnlyModeboolfalse开启后关闭备份、调度与过期备份删除功能只允许从既有备份文件恢复一个典型的 AWS Minio 场景 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其中若使用 Minio 等本地 S3 兼容存储需要在backupStorageProvider/config中设置s3ForcePathStyle: true与s3Url: http://minio:9000详见 cloud-common.md 对应的 AWS 配置小节。两大实战场景灾难恢复与集群迁移v0.8.0 的 use-cases.md 给出了两个官方推荐的落地场景。场景一灾难恢复Schedule 恢复专用模式服务端部署完成后创建每日备份计划每天 7:00 触发ark schedule create SCHEDULE NAME --schedule 0 7 * * *每次触发会生成名为SCHEDULE NAME-TIMESTAMP的 Backup 对象灾难发生需要重建资源修改 Ark Config将restoreOnlyMode设为true防止恢复过程中有人误创建或误删备份用最近的备份执行恢复ark restore create --from-backup SCHEDULE NAME-TIMESTAMP场景二集群迁移同一云厂商前提是两个集群的 Config 指向同一个云对象存储桶且由同一云厂商托管再次强调v0.8.0 不支持跨云厂商的持久卷迁移集群 1若此前未做定期备份先全量备份默认 TTL 为 30 天/720 小时可用--ttl调整ark backup create BACKUP-NAME集群 2确保新集群的persistentVolumeProvider与backupStorageProvider字段与集群 1 一致即指向同一个存储桶集群 2等待 Ark 从对象存储同步出 Backup 对象这正是backupSyncPeriod轮询机制的作用集群 2确认BACKUP-NAME可见后执行恢复ark restore create --from-backup BACKUP-NAME排障与社区遇到问题时文档给出的路径是先查阅 troubleshooting.md 排障文档若未解决可在仓库提交 Issue。此外v0.8.0 文档还提到开发者可通过邮件列表参与讨论提交 Pull Request 前需先了解 CONTRIBUTING 规范仓库根目录 CONTRIBUTING.md 与行为准则。从 Ark 到 Velero仓库现状对照需要特别说明的是本仓库已是 Ark 更名后的 Velero 项目CLI 命令由ark演变为velero命名空间由heptio-ark演变为velero可对比 cmd/velero/velero.go 与 examples/minio/00-minio-deployment.yamlv0.8.0 时代的examples/common/00-prereqs.yaml已并入examples/minio/目录带 PV 的演练清单已演化为 examples/nginx-app/with-pv.yaml其中还加入了备份/恢复钩子注解pre.hook.backup.velero.io/command与post.hook.backup.velero.io/command示例中用fsfreeze冻结/解冻文件系统以保证卷数据一致性并可通过 PVCnginx-logs50Mi测试 PV 快照能力。无论 CLI 与命名空间如何变化本文基于 v0.8.0 文档还原的「部署服务端 → 创建备份 → 模拟灾难 → 恢复验证 → 清理卸载」这一核心链路至今仍是理解 Velero 工作原理与上手实践的最快路径——本文所有命令均可按仓库当前清单在当前集群中复现。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考