Rook 集群升级机制深度解析：从升级控制器设计到自动化滚动升级实践

Rook 集群升级机制深度解析从升级控制器设计到自动化滚动升级实践【免费下载链接】rookStorage Orchestration for Kubernetes项目地址: https://gitcode.com/gh_mirrors/roo/rookRook 作为 Kubernetes 上的存储编排框架将升级能力视为存储运维自动化的核心环节。本文以 Rook 仓库中的集群升级设计文档为主线完整梳理其零停机滚动升级、健康校验门禁、失败回滚、迁移与同步四大设计目标并结合仓库中升级相关的源码实现与当前实操指南说明这一设计如何落地为今天 operator 中改镜像即触发、逐组件校验推进的自动化升级流程。读完本文你将掌握 Rook 升级的完整设计脉络、每类 Ceph 组件的升级顺序与健康判据以及如何在真实集群中执行、监控和验证一次升级。一、设计背景与目标为什么升级要自动且可靠任何长期运行的存储集群都无法避免软件迭代。当 Rook 发布新版本后已部署集群需要平滑升级到新版本而保持部署软件最新是保障集群健康的重要运维手段。设计文档在开头即点明主旨升级过程应当既自动又可靠让存储管理员从繁琐的手工操作中解放出来。为此设计文档提出了四个长期目标该文档写作时以 v0.6 为时间参考但这些目标是长期愿景自动Automatic当新版本发布且管理员决定开始升级后运行中的集群应能在无进一步人工干预的情况下完成全部组件的版本更新。零停机No downtime升级窗口内集群功能零中断。升级必须以滚动rolling方式执行避免所有组件同时更新整个过程中集群应始终保持健康状态。迁移Migrations破坏性变更、schema 变更与数据格式变更应通过自动化的迁移流程处理。回滚Rollback若升级失败Rook 应回滚到上一版本并恢复集群健康。从今天的仓库实现看这一设计蓝图大部分已落地当前rook-ceph集群的升级完全由 operator 自动驱动仅在涉及权限、CRD 或不兼容问题时需要管理员手动介入见 rook-upgrade.md。二、升级的承担者运行在 operator 进程内的升级控制器设计文档对谁来做升级给出了明确的架构决策执行与编排升级的职责由一个**升级控制器upgrade controller**承担它作为 Rook operator 的一部分运行在 operator 的同一个 Pod、同一个进程中类似于 Rook volume provisioner 的运行方式。升级控制器负责两件事按既定顺序逐组件执行更新更新镜像 → 终止旧 Pod → 等待新 Pod 就绪在升级过程中持续监控集群与组件健康采取纠正措施恢复健康必要时执行整体回滚。从源码结构看这一设计体现在pkg/operator/ceph/cluster的多个模块中集群级版本检测与升级判定位于 pkg/operator/ceph/cluster/version.goCeph 镜像版本探测与当前版本 vs 期望版本对比逻辑位于 pkg/operator/ceph/controller/version.go而 OSD 的批量滚动更新队列实现在 pkg/operator/ceph/cluster/osd/update.go。升级逻辑确实与 operator 主流程同进程运行通过 reconcile 循环驱动。升级的前置条件升级控制器开始升级前必须满足两个条件集群健康集群必须处于健康状态依据下文升级健康验证定义的检查项。集群不健康时升级控制器不得开始升级。元数据持久化Pod 的元数据必须持久化。如果配置文件等元数据只存在于 Pod 的临时 emptyDir 中即未设置dataDirHostPath升级控制器将拒绝执行升级。该健康门禁在当前实现中依然严格保留pkg/operator/ceph/cluster/version.go的validateCephVersion中当检测到镜像版本与运行版本不一致时会调用daemonclient.IsCephHealthy若集群不健康且未设置SkipUpgradeChecks则直接报错ceph status in namespace %s is not healthy, refusing to upgrade. Either fix the health issue or force an update by setting skipUpgradeChecks to true in the cluster CR这也与官方文档 ceph-upgrade.md 的警告一致当请求更新时operator 会检查 Ceph 状态若处于HEALTH_ERR状态将拒绝继续升级。三、通用升级顺序从系统命名空间到集群组件设计文档将升级划分为两个层面先升级 Rook 系统命名空间operator 与 agents再升级各个 Rook 集群。3.1 升级 Rook 系统命名空间Rook 系统命名空间承载环境中所有 Rook 集群的唯一控制平面必须先于任何单个集群升级。Operator第一个被升级的组件operator Pod 是升级控制器的宿主若存在新的升级逻辑或需要执行迁移新版本的升级控制器才知道如何操作因此它必须最先更新。这一步由管理员手工执行以确保管理员已准备好开始升级kubectl set image deployment/rook-operator rook-operatorrook/rook:v0.6.1该命令更新 operator Pod 模板的 image 字段随后管理 operator Pod 的 Deployment 会终止旧 Pod 并启动运行新版本的新 Pod。对照当前实操指南 rook-upgrade.md这一步骤演变为kubectl -n $ROOK_OPERATOR_NAMESPACE set image deploy/rook-ceph-operator rook-ceph-operatorrook/ceph:v1.20.0AgentsRook agents 同样运行在系统命名空间中。当 operator Pod 以比 agents 更新的版本启动后它会通过 Kubernetes API 更新 agent Pod 模板的 image 字段然后以滚动方式逐个终止 agent Pod由管理它们的 DaemonSet 用新版本 Pod 替换。当 operator 与所有 agent Pod 都以新版本健康运行时管理员就可以开始各 Rook 集群的升级。3.2 升级 Rook 集群Cluster CRD设计文档给出了集群层面的完整升级序列operator 启动时遍历集群升级后的 operator 在启动时遍历每个 Cluster CRD 实例并核对期望状态。若系统命名空间升级尚未完成operator 会推迟该集群的升级——operator 绝不允许集群版本高于自身版本。开始 reconcile升级控制器执行 reconciliation使集群实际版本与期望版本即 operator Pod 的容器版本达成一致。每步开始/结束时Cluster CRD 的 status 字段会更新以指示升级进度当前步骤这有助于升级被打断后续传同时每个步骤必须是幂等的重复执行不会产生意外副作用。Mons监控器monitor Pod 以滚动方式升级。对每个monitor更新 Pod 模板的 image 字段终止 Pod由管理它的 ReplicaSet 以新版本 Pod 替换控制器验证新 Pod 处于新版本、Running状态且 monitor 重新进入in quorum、Ceph 状态为OK在进入下一个 monitor 前整体验证集群健康。Ceph Managers通过更新 Pod 模板 image 字段升级 mgr PodDeployment 会终止旧 Pod 并启动新版本 Pod。控制器验证新 Pod 为新版本、Running且 mgr 实例在 Ceph 状态输出中显示为Active。OSDsmonitor 之后以滚动方式升级 OSD Pod。对每个OSD更新 Pod 模板 image 字段到新版本OSD 的生命周期管理既可以由一个 DaemonSet 整体管理也可以由每个 OSD 一个 ReplicaSet 分别管理无论哪种方式每个 OSD Pod 都会被终止并由其管理控制器以新版本重新拉起控制器验证每个 OSD 运行新版本并恢复UP与IN状态且所有 PG 恢复activeclean后才继续。可选组件RGW / MDS若用户安装了对象存储RGW或共享文件系统MDS等可选组件它们同样会被升级。两者均由 Deployment 管理升级控制器更新 Pod 模板 image 后由 Deployment 完成新旧替换并在进入下一实例前验证集群健康与对象/文件功能。从源码印证当前实现中 OSD 的更新由pkg/operator/ceph/cluster/osd/update.go中的updateExistingOSDs完成。它会先用updateQueue收集所有需要更新的 OSD ID然后通过cephclient.OSDOkToStop检查某个 OSD 是否可以安全停止只有通过检查的 OSD 才会被批量更新UpdateMultipleDeploymentsAndWait并在每个批次后等待 Deployment 就绪——这正是设计文档逐步验证再前进思想的工程化落地。四、升级健康验证以金丝雀方式逐组件推进设计文档指出升级用户指南中的手工健康检查步骤会被升级控制器以自动化方式复用确保在继续升级前集群是健康的。这种升级一个组件 → 验证健康与稳定 → 再升级下一个组件的方式本质上是一种金丝雀部署canary deployment。升级控制器应执行的标准健康检查摘要所有 Pod 处于Running状态重启次数尽量少不得出现 Pod 崩溃循环回退crash loop backoff总体状态集群整体状态为OK无警告或错误状态消息Monitors所有 monitor 处于in quorum且各自状态为OKOSDs所有 OSD 为UP且INMGRs所有 Ceph manager 处于Active状态Placement groups所有 PG 处于activeclean状态。这些检查与今天的健康验证指南 health-verification.md 一一对应。实操中可用ceph status验证TOOLS_POD$(kubectl -n $ROOK_CLUSTER_NAMESPACE get pod -l approok-ceph-tools -o jsonpath{.items[*].metadata.name}) kubectl -n $ROOK_CLUSTER_NAMESPACE exec -it $TOOLS_POD -- ceph status健康输出应包含health: HEALTH_OK、mon: 3 daemons, quorum b,c,a、mgr: a(active)、osd: 6 osds: 6 up, 6 in、pgs: 900 activeclean。若 MDS 存在则全部active若 RGW 存在则所有守护进程active。关于不健康集群升级当前 Rook 提供了两个强制开关——skipUpgradeChecks: true与continueUpgradeAfterChecksEvenIfNotHealthy: true详见 ceph-cluster-crd.md。前者跳过健康检查直接升级后者在检查不通过时仍继续推进二者都带有潜在风险提示。Pod 就绪/存活探针为补充升级控制器的健康判定能力同时利用 Kubernetes 内建的升级能力Rook Pod 应尽可能实现 liveness 与 readiness 探针。对实现了探针的 Pod升级控制器可将其作为是否健康、可否继续的又一数据点。五、回滚升级失败的兜底策略若升级过程中升级控制器观察到集群进入无法自行恢复的不健康状态就需要将组件回滚到上一稳定版本。滚动/金丝雀式升级使这一点成为可能只需将 Pod 模板的 image 字段改回上一版本再逐个终止 Pod让管理控制器用旧版本 Pod 替换即可。设计文档同时坦诚指出回滚到旧版本后集群健康与稳定大概率能够恢复但并非所有升级期间出现的集群不稳定都能靠简单回滚解决需要更多真实集群升级经验来同时改进升级可靠性与回滚有效性。当前实现在升级失败重试方面同样谨慎——例如 OSD 更新失败后不会立即重试而是等待下一次 reconcilepkg/operator/ceph/cluster/osd/update.go中注释说明若是 k8s/etcd 瞬时问题下次 reconcile 应能成功若是其他问题则会持续报错。六、升级工具让升级进度可见设计文档提出应实现帮助用户监控与验证升级进度的状态命令例如rook versions返回集群中所有 Rook 组件的版本让用户一眼看出哪些组件已完成升级类似ceph versions命令。rook status --upgrade从升级控制器获取当前升级已完成步骤与状态的摘要。在今天的实践中版本可视化通过 Kubernetes 标签机制实现rook-version标签标记在 Ceph 资源上使用下面的命令即可观察各 Deployment 的期望副本数/已更新副本数/就绪副本数及 Rook 版本watch --exec kubectl -n $ROOK_CLUSTER_NAMESPACE get deployments -l rook_cluster$ROOK_CLUSTER_NAMESPACE -o jsonpath{range .items[*]}{.metadata.name}{ \treq/upd/avl: }{.spec.replicas}{/}{.status.updatedReplicas}{/}{.status.readyReplicas}{ \trook-version}{.metadata.labels.rook-version}{\n}{end}判断升级是否全部完成的最简单方式是检查整个集群是否只剩一个rook-versionkubectl -n $ROOK_CLUSTER_NAMESPACE get deployment -l rook_cluster$ROOK_CLUSTER_NAMESPACE -o jsonpath{range .items[*]}{rook-version}{.metadata.labels.rook-version}{\n}{end} | sort | uniq同理Ceph 数据层的升级进度通过ceph-version标签观察见 ceph-upgrade.md。从源码看operator 也会在升级完成后通过daemonclient.GetAllCephDaemonVersions统计运行中的 Ceph 版本数量只有全部统一时才记录成功升级到版本 X见 pkg/operator/ceph/cluster/version.go 的printOverallCephVersion。七、迁移与破坏性变更慎之又慎当出现破坏性变更或数据格式变更时升级控制器有能力在升级过程中自动执行必要的迁移步骤。但设计文档强调迁移虽可行却绝不受欢迎因为迁移需要编写和测试额外升级逻辑还会带来新的失败路径。Rook 项目应提升对引入破坏性变更的纪律性对任何需要迁移的新代码保持极度谨慎。当前版本的做法与之呼应官方升级文档会为每个大版本单独列出 breaking changes如 v1.20 起 CSI 驱动改由 ceph-csi-operator 管理、最小 Kubernetes 版本升至 v1.32并配套给出从 ConfigMap 设置到 csi-operator 资源的迁移指引参见 rook-upgrade.md 的 Breaking changes in v1.20 一节。八、利用 Kubernetes 内建滚动更新能力Kubernetes 为滚动更新提供了内建支持如kubectl rolling-update。Rook 可以借助该能力处理拥有多个无状态 Pod 的 ReplicationController例如 RGW。但对 monitor 这类需要谨慎观察确保健康维持、quorum 重建的关键组件内建支持并不合适。即使升级控制器对某些无状态组件使用内建滚动更新在推进到下一组组件前它仍应通过全部集群健康检查——这一约束在当前 OSD 更新实现中体现得尤为明显updateExistingOSDs在更新前会先检查 PG 健康IsClusterClean不干净则推迟更新。九、同步与锁定升级期间禁止其他变更升级过程必须被精确编排以保证可靠与成功因此需要一定的锁定/同步机制确保升级进行期间集群不能被其他变更干扰。例如升级控制器正在滚动发布新版本时不应允许通过修改 Cluster CRD 做其他变更如从集群中移除节点。实现方式可以是 operator 在升级期间停止对所有 CRD 的 watch或直接从 CRD 事件处理中立即返回。Ceph 侧也有配合机制可在集群中设置noout标志表示 OSD 因升级被暂时下线时不应被标记为 out从而避免触发不必要的数据恢复操作该建议源自 Ceph Luminous 升级指南。这正好呼应设计文档让升级以受控方式进行的意图。十、可扩展性从逐个升级到分批推进小集群一次升级一个 Pod 足够。大型集群100 节点逐个升级会导致升级窗口过长。升级控制器应能批量升级多个 Pod 以按时完成升级但不能跨组件类型批处理如同时升级 mons 与 OSDs这些验证整体健康的边界必须保留monitor 也不建议批量因为整个集群通常只有少数 monitor 服务不推荐同时宕掉多个 monitor。批量的正确姿势是逐步增大批大小比如按金丝雀方式先升级单个 OSD 并验证健康再同时更新两个、四个……直到合理上限避免过多 Pod 同时下线影响集群健康。从源码印证当前 OSD 更新逻辑中defaultOSDMaxUpdatesInParallel默认为20见 pkg/operator/ceph/cluster/osd/update.go且每批次通过OSDOkToStop判定可以安全下线的 OSD 数量若集群无法进行 ok-to-stop 检查如少于 3 个 OSD 的 CI 环境则退化为一次只处理一个 OSD。这正是设计文档canary 批量 健康验证思想的可配置实现。十一、升级失败排查如何取回已消失 Pod 的调试信息升级本质上是终止旧 Pod、启动新 Pod因此需要策略调查那些可能已不存在的 Pod。设计文档给出了几种从已停止运行 Pod 获取调试产物的技术kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}获取 Pod 上一实例的日志例如已崩溃但尚未终止的 Podkubectl get pods --show-alltrue列出所有 Pod包括为替换为更新版本而被终止的旧版本 PodRook operator 日志升级控制器输出的宿主应详尽记录升级期间执行的动作序列修改过的控制器DaemonSet / ReplicaSet / Deployment与被终止的 Pod 名称遇到的所有健康检查状态与输出。十二、结语设计如何演化为今天的自动化升级设计文档的结尾指出手工流程已证明 Rook 可升级完全自动化的升级能力将按迭代方式实现并从预生产环境的实战中积累经验优先实现happy path按序列自动更新所有组件健康检查失败且集群无法恢复时立即停止回滚、迁移与破坏性变更处理则在后续里程碑中补齐。对照仓库现状这一演进路线已基本走完手工部分operator 与集群命名空间的前置操作更新 common 资源、CRDs、operator 镜像仍需管理员执行路径与命令详见 rook-upgrade.md自动化部分Ceph 数据层的升级mons、mgrs、OSDs、MDS、RGW完全由 operator 驱动——修改 CephCluster CR 的spec.cephVersion.image即触发逐个守护进程检查、滚动替换、健康验证详见 ceph-upgrade.mdROOK_CLUSTER_NAMESPACErook-ceph NEW_CEPH_IMAGEquay.io/ceph/ceph:v20.2.4-20260818 kubectl -n $ROOK_CLUSTER_NAMESPACE patch CephCluster $ROOK_CLUSTER_NAMESPACE --typemerge -p {\spec\: {\cephVersion\: {\image\: \$NEW_CEPH_IMAGE\}}}版本判定diffImageSpecAndClusterRunningVersionpkg/operator/ceph/cluster/version.go对比期望镜像版本与集群运行版本一致则无事可做期望高于运行则触发升级期望低于运行则明确告警downgrading is not supported不支持降级——这一实现细节正是对设计文档回滚边界的严谨补充。设计文档中面向社区的三个开放问题除回滚外还有哪些恢复健康的步骤、回滚失败怎么办、Pod 能实现哪些有意义的探针至今仍是升级可靠性研究的持续话题。对于存储管理员而言牢记本文的核心结论即可升级前务必确保集群健康、元数据持久化升级中相信 operator 的滚动编排与健康门禁升级后通过rook-version/ceph-version标签与ceph status双重确认版本统一与健康恢复。【免费下载链接】rookStorage Orchestration for Kubernetes项目地址: https://gitcode.com/gh_mirrors/roo/rook创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考