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 Arkv0.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通过 CRDCustom Resource Definition定义并存储在 etcd 中。Ark 还包含若干控制器controller来处理这些自定义资源从而真正执行备份、恢复以及相关操作。你可以备份或恢复集群中的所有对象也可以按类型、命名空间和/或标签label对对象进行过滤。这一机制使 Ark 非常适合灾难恢复场景也适合在对集群执行系统操作例如升级之前为应用状态打快照。按需备份On-demand Backupsbackup操作的工作内容将复制出的 Kubernetes 对象打包成 tarball上传到云对象存储若指定了快照则调用云厂商 API 对持久卷制作磁盘快照。备份期间还可以指定 hooks钩子在备份过程中执行命令。例如你可能需要在打快照前告诉数据库把内存中的缓冲刷到磁盘。hooks 的详细说明见后文。需要说明的是集群备份并非严格原子操作如果备份进行时有 Kubernetes 对象正在被创建或修改这些对象可能不会被包含进备份中。捕获到不一致信息的概率很低但确实存在。计划备份Scheduled Backupsschedule操作允许你按固定间隔定期备份。第一次备份会在 schedule 创建时立即执行之后按指定的间隔周期执行间隔由 Cron 表达式指定。计划备份生成的备份名称格式为SCHEDULE NAME-TIMESTAMP其中TIMESTAMP的格式为YYYYMMDDhhmmss。恢复Restoresrestore操作可以从之前创建的备份中恢复全部对象与持久卷也可以只恢复被过滤后的对象和持久卷子集。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时背后发生如下过程Ark 客户端调用 Kubernetes API server创建一个Backup对象BackupController注意到新的Backup对象并执行校验BackupController开始备份流程通过查询 API server 收集需要备份的资源BackupController调用对象存储服务例如 AWS S3上传备份文件。默认情况下ark backup create会为所有持久卷制作磁盘快照。你可以通过附加标志调整快照行为运行ark backup create --help查看可用标志使用--snapshot-volumesfalse可以禁用快照。从当前仓库的源码结构看这一控制器模型至今仍被保留并演进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 ProvidersProvider所有者联系AWS S3Ark 团队Slack / GitHub IssueAzure Blob StorageArk 团队Slack / GitHub IssueGoogle Cloud StorageArk 团队Slack / GitHub IssueS3 兼容的备份存储提供商Ark 使用 Amazon Go SDK 连接 S3 API。部分第三方存储提供商同样支持 S3 API以下提供商经用户报告可与 Ark 配合使用注意这些提供商并未由 Ark 团队定期测试IBM CloudMinioCeph RADOS v12.2.7DigitalOcean卷快照提供商Volume Snapshot ProvidersProvider所有者AWS EBSArk 团队Azure Managed DisksArk 团队Google Compute Engine DisksArk 团队ResticArk 团队PortworxPortworxDigitalOceanStackPointCloud若要为新的备份或卷存储系统编写插件可参考官方示例仓库并在插件发布后通过 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命令指定如下标志标志默认值说明示例--default-backup-storage-locationdefault备份默认使用的 backup storage location 名称aws-us-east-1-bucket--default-volume-snapshot-locations无每个 PV 提供商默认用于 PV 快照的 volume snapshot location 名称列表aws:us-east-1,portworx:local这些标志的值必须对应集群中真实存在的BackupStorageLocation与VolumeSnapshotLocation自定义资源名称。若未为--default-backup-storage-location指定值Ark server 会查找名为default的BackupStorageLocation使用。此外还有若干非默认的 Ark server 设置标志默认值说明--backup-sync-period1m多久检查一次确保对象存储中的所有 Ark 备份都以 Backup API 对象的形式存在于集群中--restic-timeout1hpod 卷的备份/恢复允许运行多久后才超时pre-v0.10 中对应Config资源里的podVolumeOperationTimeout--restore-onlyfalse以仅允许恢复的模式运行备份、计划与垃圾回收均被禁用逐步升级步骤下载并解压最新 release缩容现有 Ark deploymentkubectl scale -n heptio-ark deploy/ark --replicas 0在 Ark 目录解压 release tarball 的目录中重新应用00-prereqs.yaml以创建新 CRDkubectl apply -f config/common/00-prereqs.yaml参照config/目录中针对你平台的示例结合现有Config资源中的信息创建一个或多个BackupStorageLocation资源如果使用 Ark 进行 PV 快照再创建VolumeSnapshotLocation资源同样参考config/目录执行文档中详述的一次性对象存储迁移在 Ark deployment YAML 中为ark server指定新标志见上表如果使用插件将 deployment YAML 中initContainers部分引用的插件镜像标签更新到最新应用更新后的 deployment YAML确认 pod 成功启动如果使用了 restic 集成确保 daemon set pod 已用最新 Ark 镜像重建若 daemon set YAML 使用:latest标签可删除 pod 使其以新镜像重建确认所有设置迁移无误后删除旧的 Config CRDkubectl 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 用两个新自定义资源替代了ConfigBackupStorageLocation直接取代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主配置参数Key类型默认值含义providerStringArk 原生支持aws、gcp、azure其他 provider 可通过外部插件获得必填实际存放备份的云提供商名称objectStorageObjectStorageLocation—给定 provider 的对象存储规格objectStorage/bucketString必填备份上传到的存储 bucketobjectStorage/prefixString可选bucket 内存放备份的目录objectStorage/configmap[string]string无可选传给云提供商用于备份存储的配置键值对AWS或其他 S3 兼容存储的objectStorage/config参数Key类型默认值含义regionstring空示例us-east-1。未提供时从 AWS S3 API 查询s3ForcePathStyleboolfalse使用 Minio 等本地存储服务时设为trues3Urlstring非 AWS 托管存储必填示例http://minio:9000。主要用于 Minio 等本地存储服务publicUrlstring空示例https://minio.mycluster.com。指定后在生成下载 URL如日志时用它替代s3Url主要用于本地存储服务kmsKeyIdstring空指定 AWS KMS key id 或别名以启用 S3 中备份的加密仅适用于 AWS S3可能需要显式授予密钥使用权限Azure 的objectStorage/config参数Key类型默认值含义resourceGroupstring必填包含此备份存储位置 storage account 的资源组名称storageAccountstring必填此备份存储位置的 storage account 名称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 只需regionAzure 支持apiTimeoutmetav1.Duration默认2m0sAzure API 请求超时时间与resourceGroup可选卷快照存放的资源组默认与集群资源组相同GCP 无需参数。多位置实操示例场景一单个备份中为多种持久卷打快照如集群同时有 EBS 与 Portworx 卷服务端配置ark snapshot-location create ebs-us-east-1 \ --provider aws \ --config regionus-east-1 ark snapshot-location create portworx-cloud \ --provider portworx \ --config typecloud创建备份时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之于portworxArk 不要求显式指定直接ark backup create full-cluster-backup即可。场景二部分备份存美东 bucket、部分存美西 bucket服务端配置ark backup-location create default \ --provider aws \ --bucket ark-backups \ --config regionus-east-1 ark backup-location create s3-alt-region \ --provider aws \ --bucket ark-backups-alt \ --config regionus-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 typelocal ark snapshot-location create portworx-cloud \ --provider portworx \ --config typecloud创建备份时显式选择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 配置了VolumeSnapshotLocationArk 只会快照 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二进制放入 PATHtar -xzf RELEASE-TARBALL-NAME.tar.gz -C /dir/to/extract/to启动 server 与 Miniokubectl 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 componentark --namespaceheptio-ark kubectl get deployments --namespacenginx-example可选将 Minio 暴露到集群外执行获取日志或ark describe等命令时Ark server 会生成预签名 URL 以下载请求的内容。要从集群外即你的 Ark 客户端访问这些 URL需要让 Minio 可被外部访问。有两种方式把 Minio Service 类型从ClusterIP改为NodePort或为集群配置 Ingress 并保持ClusterIP。在 Ark 0.10 中还可以在 backup storage 配置中为新字段publicUrl指定预签名 URL 的值。使用 NodePort 方式在 examples/minio/00-minio-deployment.yaml 中把 Service 的spec.type从ClusterIP改为NodePort获取 Minio URLMinikube 环境运行minikube service minio --namespaceheptio-ark --url其他环境取任意节点的外部 IP 或 DNS 名再拼接 NodePort 端口用kubectl -n heptio-ark get svc/minio -o jsonpath{.spec.ports[0].nodePort}获取在 Minio 的 backupstoragelocation YAML 中取消publicUrl行的注释填入该 Minio URL必须包含http://或https://前缀。使用 Ingress 方式保持 Service 类型为ClusterIP在 backupstoragelocation YAML 的publicUrl字段中填入 Ingress 的 URL 与端口。创建备份备份所有匹配appnginx标签选择器的对象ark backup create nginx-backup --selector appnginx如果希望备份除标签backupignore之外的所有对象ark backup create nginx-backup --selector backup notin (ignore)可选创建基于 cron 表达式的定期备份ark schedule create nginx-daily --schedule0 1 * * * --selector appnginx也支持非标准简写 cron 表达式例如ark schedule create nginx-daily --scheduledaily --selector appnginx。模拟灾难删除示例命名空间kubectl delete namespace nginx-example随后确认 nginx deployment、service 与命名空间均已不存在可能需要等待几分钟让命名空间完全清理kubectl get deployments --namespacenginx-example kubectl get services --namespacenginx-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成功后为CompletedWARNINGS与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备份 HooksArk 支持在备份期间在 pod 的容器内执行命令。v0.7.0 之前只支持在所有自定义 action 处理之前执行的 pre hooksv0.7.0 起新增 post hooks——在所有自定义 action 及其指定的附加项完成备份后执行。hooks 有两种指定方式pod 上的注解annotation与 Backup spec。Pod 注解方式Pre hooks注解名说明pre.hook.backup.ark.heptio.com/container执行命令的容器默认 pod 中第一个容器可选pre.hook.backup.ark.heptio.com/command要执行的命令多参数时用 JSON 数组如[/usr/bin/uname, -a]pre.hook.backup.ark.heptio.com/on-error命令返回非零退出码时的处理方式默认 Fail可选值 Fail 与 Continuepre.hook.backup.ark.heptio.com/timeout等待命令执行的时长超时即认为 hook 出错默认 30sPost hooksv0.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 appnginx \ pre.hook.backup.ark.heptio.com/command[/sbin/fsfreeze, --freeze, /var/log/nginx] \ pre.hook.backup.ark.heptio.com/containerfsfreeze \ post.hook.backup.ark.heptio.com/command[/sbin/fsfreeze, --unfreeze, /var/log/nginx] \ post.hook.backup.ark.heptio.com/containerfsfreeze创建备份并用日志验证 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后按平台创建 daemonsetAWSkubectl apply -f config/aws/20-restic-daemonset.yamlAzurekubectl apply -f config/azure/20-restic-daemonset.yamlGCPkubectl apply -f config/gcp/20-restic-daemonset.yamlMiniokubectl 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-volumesYOUR_VOLUME_NAME_1,YOUR_VOLUME_NAME_2,...例如对同时挂载 PVC 卷与 emptyDir 卷的 podkubectl -n foo annotate pod/sample backup.ark.heptio.com/backup-volumespvc-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-nameYOUR_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 到 Velerov0.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考