Velero v1.10 升级实战指南Kopia 统一仓库架构落地期间的 CRD、Deployment 与 node-agent 完整迁移【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/veleroVelero v1.10 是项目演进中的一个关键版本它除了常规的版本迭代还深度集成了 Kopia——将 Kopia 的 uploader 模块抽象为通用文件系统的备份通道uploader将其 repository 模块封装为统一备份仓库Unified Repository与原有的 restic 文件系统备份路径并存。本篇基于官方升级文档 site/content/docs/v1.10/upgrade-to-1.10.md 完整展开升级流程从 CLI 安装、CRD 先行更新、Deployment 镜像与启动参数改造到 restic DaemonSet 向 node-agent 的重命名迁移并结合仓库源码说明每一处变更背后的实现依据帮助读者在不破坏既有备份数据的前提下平滑升级到 v1.10。一、为什么 v1.10 的升级比常规小版本升级更复杂官方升级文档在开头就给出了明确的告诫Caution:从 Velero v1.10 起除了继续支持 restic 做文件系统级备份与恢复之外Kopia 也被集成进了 Velero。因此从低于 v1.10.0 的版本升级到 v1.10 时流程会有所不同。结合 changelogs/CHANGELOG-1.10.md 中的版本说明v1.10 的核心变化可以概括为三点它们分别对应升级文档中的三个关键步骤CRD 先行变更Kopia 集成与统一仓库架构引入了新的 CRD如 BackupRepository 等和 schema 变更因此必须先用velero install --crds-only更新全部核心 CRD再滚动更新容器镜像。这也解释了为什么文档强调--crds-only这步不可省略。仓库中 config/crd/v1 与 config/crd/v2alpha1 目录分别存放了稳定版本与 v2alpha1 新特性如 VolumeSnapshot v2 相关的 CRD 定义其中 v1.10 只安装 v1 系列 CRD——这是文档中v1.10 仅支持 Kubernetes v1.16这一约束的来源Kubernetes 1.16 起 CRD 才稳定支持apiextensions.k8s.io/v1。文件系统备份路径泛化v1.10 把restic 备份重构为pod volume 文件系统备份fs backup并在其下提供 Kopia 与 Restic 两条路径。升级期间Restic 路径仍然可用且为默认Kopia 路径需要显式指定uploader-type参数才能启用同时两条路径对既有备份数据都兼容Velero 会在恢复时动态切换到正确的路径处理。这一背景决定了升级脚本中必须把与 restic 绑定的启动参数重命名为与 uploader 无关的通用参数。restic DaemonSet 更名 node-agent原本每台节点上运行 restic 的 DaemonSet 被重命名为node-agent因为它的职责从跑 restic扩展为承载多种 uploaderrestic/kopia的节点代理。理解这三点之后下面所有 sed 替换与资源重命名操作就有了统一的解释逻辑先把 API 层CRD换成 v1.10 的 schema再让数据平面镜像与启动参数对齐新的 uploader 抽象最后清理不再使用的 restic 专属资源。二、升级前置条件官方文档列出的前置条件为当前集群中已安装Velero v1.9.x若低于 v1.6需先按 v1.5 → v1.6 → v1.7 → v1.8 → v1.9 逐级升级升级前务必核对官方 README 中的Velero 兼容矩阵确认你的 Kubernetes 版本被新版 Velero 支持v1.10 要求 Kubernetes v1.16。此外基于该版本的特性背景升级前建议额外确认两件事记录当前 Deployment 是否开启了--default-volumes-to-resticv1.10 中重命名为--default-volumes-to-fs-backup、仓库维护频率等参数升级脚本会按固定字符串做替换如果此前手工改过这些参数需要先核对实际值若使用 restic 节点代理确认集群中存在名为restic的 DaemonSetkubectl get ds -n velero因为第 4 步的 DaemonSet 迁移脚本只在存在该资源时才有意义。三、升级步骤完整可执行流程步骤 1安装 v1.10 命令行客户端CLI按照官方安装文档 site/content/docs/v1.10/basic-install.md 中Install the CLI一节安装 v1.10 的 CLI然后验证velero version --client-only预期输出Client: Version: v1.10.0 Git commit: git SHA只升级 CLI 不会改动集群内任何对象这是一次零风险操作但它为后续的velero install --crds-only提供了能生成 v1.10 CRD 版本的客户端。步骤 2仅更新 CRD核心 API schemavelero install --crds-only --dry-run -o yaml | kubectl apply -f -这条命令的语义在源码中可以直接验证pkg/cmd/cli/install/install.go 中--crds-only的定义是 Only generate CustomResourceDefinition resources. Useful for updating CRDs for an existing Velero install.只生成 CRD 资源专门用于更新既有安装的 CRD。当CRDsOnly为 true 时安装逻辑走install.AllCRDs()分支只输出 CRD 清单而不输出 Deployment、ServiceAccount、RBAC 等对象配合--dry-run -o yaml把结果打到标准输出再管道给kubectl apply就完成了只换 API 不换实现的平滑迁移。这一步之所以必须先于镜像更新执行是因为 v1.10 的 CRD schema 变化新增 Kopia/统一仓库相关字段与资源是新旧两版服务端共同依赖的 API 基础先让新 schema 就位Pod 滚动重启后无论新旧版本容器都能正常解析 CRD。注意v1.10 安装只支持 v1 版 CRD因此对 Kubernetes 版本的硬性要求是 v1.16。步骤 3更新 Deployment 的镜像与启动参数# uploader_type 取值可以是 restic 或 kopia kubectl get deploy -n velero -ojson \ | sed s#\image\\: \velero\/velero\:v[0-9]*.[0-9]*.[0-9]\#\image\\: \velero\/velero\:v1.10.0\#g \ | sed s#\server\,#\server\,\--uploader-type$uploader_type\,#g \ | sed s#default-volumes-to-restic#default-volumes-to-fs-backup#g \ | sed s#default-restic-prune-frequency#default-repo-maintain-frequency#g \ | sed s#restic-timeout#fs-backup-timeout#g \ | kubectl apply -f -逐条拆解这段管道sed 替换作用源码依据镜像版本号 →velero/velero:v1.10.0将 Velero Deployment 容器镜像升级到 v1.10.0pkg/install/deployment.go 中 Deployment 构建函数以WithImage设置镜像在server参数后插入--uploader-type$uploader_type显式指定文件系统备份走 Kopia 还是 Restic 路径pkg/cmd/server/config/config.go 定义了--uploader-type参数Type of uploader to handle the transfer of data of pod volumesdefault-volumes-to-restic→default-volumes-to-fs-backup参数泛化默认对全部卷启用文件系统备份源码中注册为--default-volumes-to-fs-backupBackup all volumes with pod volume file system backup by default.default-restic-prune-frequency→default-repo-maintain-frequency参数泛化仓库维护频率不再绑定 restic源码中注册为--default-repo-maintain-frequencyHow often maintain is run for backup repositories by default.restic-timeout→fs-backup-timeout参数泛化pod 卷备份/恢复超时源码中注册为--fs-backup-timeoutHow long pod volume file system backups/restores should be allowed to run before timing out.参数改名不是简单的文案更新。从 pkg/install/deployment.go 可以看到v1.10 的 Deployment 构建逻辑按--uploader-type%s、--default-volumes-to-fs-backuptrue、--default-repo-maintain-frequency%v、--fs-backup-timeout%v组装 server 容器参数——即restic字样已从数据通路的命名中剥离。这也是为什么升级脚本必须做这三处字符串替换如果旧 Deployment 里仍带着--default-volumes-to-restic之类的旧参数名v1.10 服务端启动时会因为无法识别该参数而失败备份能力直接不可用。$uploader_type需要在执行前 export 或替换为具体值升级期间保持 restic 路径uploader_typerestic是最保守的路线因为 v1.10 中 Restic 路径仍是默认路径若希望新备份走 Kopia 路径可设置为kopia。无论选哪条路径恢复旧备份时 Velero 都会自动切换到对应路径处理两条路径的数据互不冲突。步骤 4可选restic DaemonSet 迁移为 node-agent只有当原安装启用了 restic 节点代理集群中存在velero/resticDaemonSet时才需要执行# optional, if using the restic daemon set echo $(kubectl get ds -n velero restic -ojson) \ | sed s#\image\\: \velero\/velero\:v[0-9]*.[0-9]*.[0-9]\#\image\\: \velero\/velero\:v1.10.0\#g \ | sed s#\name\\: \restic\#\name\\: \node-agent\#g \ | sed s#\[ \restic\,#\[ \node-agent\,#g \ | kubectl apply -f - kubectl delete ds -n velero restic --force --grace-period 0三段替换分别对应 DaemonSet 的三个关键位置均可在 pkg/install/daemonset.go 中一一对应镜像与 Deployment 同样升到 v1.10.0DaemonSet 的DaemonSet()函数使用同一WithImage选项资源名与标签源码中dsName : node-agentSelector 为namenode-agentPod 标签包含role: node-agent因此name: restic全局替换为name: node-agent覆盖了 metadata.name、selector 与 label 三处容器启动参数源码中 DaemonSet 容器Args为[node-agent, server]Linux 节点因此[ restic,替换为[ node-agent,完成子命令切换。随后kubectl delete ds -n velero restic --force --grace-period 0删除旧 DaemonSet避免新旧两个 DaemonSet 同时调度导致同一节点上出现两个节点代理 Pod。这里采用先建新、后删旧的顺序是为了让每个节点上的代理进程切换尽量平滑旧 restic Pod 在节点上完成备份任务后由同名调度策略接管到新 node-agent Pod。步骤 5验证升级结果velero version预期输出客户端与服务端版本一致Client: Version: v1.10.0 Git commit: git SHA Server: Version: v1.10.0如果 Server 版本停留在旧版本通常意味着 Deployment 滚动更新未生效应检查kubectl get pods -n velero与kubectl describe deploy -n velero中镜像与参数是否正确。建议再各触发一次小范围备份与恢复做端到端验证尤其是文件系统级备份——这是 v1.10 中路径变化最大的部分。四、升级后遗留资源的清理可选官方文档 Notes 部分指出从 v1.9.x 升级后集群中仍会残留一些 v1.10.x 中不再使用的资源可以按自身需要选择性删除resticrepository CRD 及其相关的 CRResticRepository 对象v1.10 的统一仓库架构中文件系统备份仓库由新的 BackupRepository 体系管理ResticRepository 不再是主通路velero 安装命名空间下的velero-restic-credentialsSecretrestic 专用凭据 Secret 被统一仓库的凭据管理取代。清理前建议先确认没有第三方工具仍依赖这些对象删除动作本身与 Velero 升级流程解耦属于可选的整洁性操作而非升级完成的必要条件。五、从源码看 uploader 切换的底层机制理解 v1.10 的 uploader 机制有助于解释升级文档中两条路径并存、动态切换的设计。以下事实来自当前仓库源码uploader 类型常量与校验pkg/uploader/types.go 定义了 uploader 类型常量KopiaType kopia以及面向块设备数据移动的BlockType velero-block并提供ValidateUploaderType做入参校验。值得注意的是从当前代码结构看校验逻辑中已不再包含 restic 选项——这反映了 v1.10 之后版本对 uploader 抽象的持续演进restic 路径在后续版本中逐步被收敛阅读 v1.10 升级文档时应以文档描述的restic 可用且为默认为准。server 侧参数解析pkg/cmd/server/config/config.go 中UploaderType字段绑定--uploader-type参数与--default-volumes-to-fs-backup、--default-repo-maintain-frequency、--fs-backup-timeout一起构成文件系统备份的完整参数面——这正是步骤 3 sed 替换全部命中的目标。uploader 工厂分发pkg/uploader/provider/provider.go 中的工厂按 uploader 类型 switch 分发到 Kopia 或 Block 的 uploader provider 实现Pod 卷备份/恢复流程在 pkg/podvolume 中通过 backupper/restorer 工厂backupper_factory.go/restorer_factory.go按路径选择具体实现实现了文档所说的恢复时动态切换到正确路径。架构设计依据整体设计详见 design/Implemented/unified-repo-and-kopia-integration/unified-repo-and-kopia-integration.md其中阐述了为什么要用统一仓库层解耦数据移动器与备份仓库以及 Kopia 如何同时承担两者角色。六、小结Velero v1.10 升级的本质是一次先 API 后数据平面的分阶段迁移velero version --client-only确认 CLI 就位velero install --crds-only --dry-run -o yaml | kubectl apply -f -只更新 CRD要求 K8s v1.16用 sed 管道更新 Deployment 的镜像注入--uploader-type并把default-volumes-to-restic/default-restic-prune-frequency/restic-timeout三组 restic 专属参数名泛化为 fs-backup/repo 通用名启用过节点代理的集群将 restic DaemonSet 就地改造为 node-agent 并删除旧对象velero version确认客户端与服务端均为 v1.10.0再按需清理 resticrepository CRD/CR 与velero-restic-credentialsSecret。按照该流程既有 restic 备份数据在升级后依然可用新备份则可按需选择 Kopia 或 Restic 路径——这也为后续版本进一步演进 uploader 抽象保留了平滑迁移空间。【免费下载链接】veleroBackup and migrate Kubernetes applications and their persistent volumes项目地址: https://gitcode.com/GitHub_Trending/ve/velero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
