让容器底座自己完成升级：openEuler KubeOS原子化升级入门

跑了 Kubernetes 的机房有个老大难：几十台节点机的操作系统要升级补丁，一台台 SSH 上去 rpm 升级再重启，一晚上过去了，升级到一半失败的还得回滚重来。openEuler 提供的 KubeOS 把这件事交给了集群自己：操作系统被当作集群资源来管理，升级声明下发后，节点逐台完成"双分区原子切换"，成了自动生效，败了自动回退，业务集群始终有节点在岗。

机制一句话：双分区 + 声明式升级。 KubeOS 把系统盘划分为主备两个分区，当前系统跑在 A 区；要升级时，管理面下发一个 KubeOSConfig 自定义资源，写明目标镜像与版本，节点上的 agent 把新系统写入 B 区，校验通过后重启切入 B 区——整个过程要么完成、要么不动，不存在"升了一半"的中间态。新系统起不来时，双分区机制兜底切回原区，回滚不是手工操作而是机制内置。

操作面三步（命令按官方文档口径）。 一，准备升级镜像并推送；二，编写 KubeOSConfig 描述本次升级（目标版本、涉及节点、升级参数）；三，提交给集群：

kubectl apply -f osupgrade.yaml
kubectl get kubeosconfig

随后的流程全自动：agent 逐台拉镜像、写备分区、重启切换，管理员只需盯着 CR 的状态字段与节点事件，全部完成后用 kubectl get nodes 确认各节点就绪版本。

适合谁、不适合谁。 适合的是节点数量多、升级频繁、不能停的容器底座——补丁节奏从"季度停机窗口"变成"日常流水线"；不适合的是两三台机器的小环境，为它引入 KubeOS 的管理面，运维成本反而高于手工。判断标准很简单：操作系统运维是否已经成为集群里耗时排前列的活儿。

迁移前置：KubeOS 要求以镜像化方式安装节点系统，存量手工安装的节点需重装纳管，建议在新集群立项时就把 KubeOS 纳入底座设计，而不是事后改造。

容器业务的部署、底座的选型与升级体系是一体的。贵州诚鑫致达科技为企业提供容器化环境的规划与实施，操作系统层怎么管、升级窗口怎么省，可以在方案阶段一并设计，欢迎搜索"诚鑫致达 服务器部署"联系我们。

（约 900 字）

企业存储选型参考｜贵州诚鑫致达

做海量监控接入与长期归档，群晖机型参考：HD6500 · RS3621xs+ · DS2422+。需要选型建议或上门评估，搜「诚鑫致达」即可找到我们。

服务区域｜贵州诚鑫致达

贵州群晖NAS、贵阳存储、数据备份、信创云盘或 IT 集成服务，可联系贵州诚鑫致达科技，服务范围覆盖贵州全省各市州。云南昆明企业 NAS 存储方案与备份容灾，支持远程与上门服务。