认识容器 OS 升级

概述

在云场景中,容器和 kubernetes 的应用越来越广泛。然而,当前对容器和 OS 进行独立管理的方式,往往面临功能冗余、两套调度系统协同困难的问题。另外,OS 的版本管理比较困难,相同版本的 OS 在使用过程中会各自安装、更新、删除软件包,一段时间后 OS 版本变得不一致,导致版本分裂,并且 OS 可能和业务紧耦合,造成大版本升级等比较困难。为了应对上述问题,openEuler 推出了基于openEuler的容器 OS 升级工具。

容器 OS 针对业务以容器的形式运行的场景,专门设计的一种轻量级操作系统。基于openEuler的容器 OS 升级工具将容器 OS 作为组件接入 kubernetes,使容器 OS 和业务处于同等地位,通过 kubernetes 集群统一管理容器和容器 OS,实现一套系统管理容器和OS。

openEuler 容器 OS 升级工具通过 kubernetes operator 扩展机制控制容器 OS 的升级流程,对容器 OS 进行整体升级,从而实现 OS 管理器和业务协同,该升级方式会在容器 OS 升级前,将业务迁移到其他非升级节点,减少 OS 升级、配置过程中对业务的影响。该升级方式是对容器 OS 进行原子升级,使 OS 一直向预想的状态同步,保证集群里的 OS 版本一致,避免版本分裂问题。

架构介绍

容器 OS 升级架构

图1 容器 OS 升级架构

如图所示,容器 OS 主要包含三个组件 os-operator,os-proxy 和 os-agent 。os-operator 和 os-proxy 运行在容器中,部署在 kubernetes 集群内;os-agent 不属于集群,直接作为进程运行在 Worker Node 中。

  • os-operator:全局的容器 OS 管理器,持续查看所有节点的容器 OS 版本信息,并根据用户配置的信息控制同时进行升级的节点个数,并标记准备升级的节点。

  • os-proxy:单节点的 OS 管理器,持续查看当前节点的容器 OS 版本信息。如果当前节点被 os-operator 标记为准备升级的节点后,锁定节点并驱逐 pod,转发升级信息到 os-agent 。

  • os-agent:接收来自 proxy 的信息,从 OSImage Server 下载用于更新的容器 OS 镜像,然后进行升级并重启节点。

容器 OS 文件系统

图 2 容器 OS 文件系统布局

如图所示,容器 OS 包含四个分区:

  • boot 分区:grub2文件分区
  • Persist 分区:用于存放持久性用户数据,容器 OS 升级时,该分区的数据也会保留
  • 两个 root 分区:容器 OS 采用双分区模式,将 root 分区划分为 rootA 和 rootB。假定初始化时,系统运行在 rootA 分区上,当进行系统更新时,会下载新系统到 rootB 分区,grub会有两个启动项分别为A,B,将 grub 默认启动项设置为B,最后会重启虚拟机。虚拟机启动后容器 OS 将运行在刚更新过的 rootB 分区上。

容器OS的root文件系统为只读,用户的持久化数据存放在Persist持久化数据分区 。

文档捉虫

“有虫”文档片段

问题描述

提交类型 issue
有点复杂...
找人问问吧。
PR
小问题,全程线上修改...
一键搞定!
问题类型
规范和低错类

● 错别字或拼写错误;标点符号使用错误;

● 链接错误、空单元格、格式错误;

● 英文中包含中文字符;

● 界面和描述不一致,但不影响操作;

● 表述不通顺,但不影响理解;

● 版本号不匹配:如软件包名称、界面版本号;

易用性

● 关键步骤错误或缺失,无法指导用户完成任务;

● 缺少必要的前提条件、注意事项等;

● 图形、表格、文字等晦涩难懂;

● 逻辑不清晰,该分类、分项、分步骤的没有给出;

正确性

● 技术原理、功能、规格等描述和软件不一致,存在错误;

● 原理图、架构图等存在错误;

● 命令、命令参数等错误;

● 代码片段错误;

● 命令无法完成对应功能;

● 界面错误,无法指导操作;

风险提示

● 对重要数据或系统存在风险的操作,缺少安全提示;

内容合规

● 违反法律法规,涉及政治、领土主权等敏感词;

● 内容侵权;

您对文档的总体满意度

非常不满意
非常满意
提交
根据您的反馈,会自动生成issue模板。您只需点击按钮,创建issue即可。