《走进 KubeOS》带你从0到1了解 openEuler KubeOS（一）

        第一篇文章，我们先来讲一下 KubeOS 的架构，我希望本专栏能够带读者朋友们认识 Kubernetes 二次开发、了解 KubeOS 的运用面，并参与到项目的贡献中来。

背景概述

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

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

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

        作为接触生产环境并不多的学生开发者，可能并不是很理解文中反复提到的“业务”，没关系，我来举几个易于理解的例子，便于你进一步理解，注意以下几个重点概念：

1. 容器和 OS 进行独立管理：
   
           在传统的生产环境中，容器和操作系统往往是独立管理的。例如，一个服务器上可能运行着多个容器，每个容器都有自己的操作系统环境。这意味着需要分别管理和维护每个容器的操作系统，包括安装、升级、配置等。而且，容器和操作系统之间的调度和协同也会面临一些困难。
           以一个具体的例子来说明，假设有一个生产环境中运行着多个容器的服务器集群。每个容器都使用不同的操作系统版本，例如有的容器使用 CentOS 7，有的使用 Ubuntu 18.04。在这种情况下，需要分别管理每个容器的操作系统，包括安装软件包、进行系统更新等。同时，由于操作系统版本不同，可能需要针对不同的操作系统进行特定的配置和调优。这样就增加了管理和维护的复杂性。
    
2. 相同版本的 OS 在使用过程中会各自安装、更新、删除软件包：

        相同版本的操作系统在使用过程中，无论是员工用来开发的电脑还是一整批服务器，都可能各自安装、更新和删除软件包。这是因为不同用户或者不同的服务器可能有不同的需求和配置。例如，员工 A 可能需要安装某个特定的开发工具，而员工 B 则需要另外一个工具。因此，他们会根据自己的需求安装和更新软件包。同样地，一批服务器也可能根据不同的业务需求安装不同的软件包。比如员工 A 装了 MySQL，而员工 B 装了 qemu 工具。

        这种情况下，相同版本的操作系统在使用过程中会逐渐变得不一致，因为不同的用户或者服务器会根据自己的需求进行软件包的管理。这可能导致操作系统版本分裂，即不同的服务器或者用户使用的操作系统版本不同，增加了管理和维护的困难。

        3. OS 可能和业务紧耦合，造成大版本升级等比较困难

                                

        "OS 可能和业务紧耦合，造成大版本升级等比较困难" 的意思是，操作系统和业务应用程序之间可能存在紧密的依赖关系。在某些情况下，业务应用程序可能依赖于特定版本的操作系统或者操作系统上的特定配置。当需要升级操作系统时，可能需要同时升级业务应用程序或者进行相关的适配工作，否则可能导致业务应用程序无法正常运行。

        例如，某个业务应用程序可能依赖于旧版本的操作系统上的某个库文件或者配置项。如果直接升级操作系统而不进行相应的适配工作，可能会导致业务应用程序无法找到所需的库文件或者无法读取正确的配置项，从而影响业务的正常运行。这就使得大版本升级变得更加困难，需要仔细考虑和处理操作系统和业务应用程序之间的依赖关系。

业界主流思想

通过改造 OS 来应对上述问题

容器镜像把应用运行所需的依赖都打包到镜像里面，对于操作系统，它所需的功能越来越少。为了容器运行而设计的操作系统，被称为容器 OS 。

容器 OS 特征

简要概括，仅需要三个必要组件

• Linux Kernel
• 容器引擎如 docker
• 安全机制

这带来了四个特点

1. 极简化：它包含的软件包极少，攻击面与漏洞相应的也少了很多，OS 相对来说更安全；
2. 不可变：只读文件系统，让容器 OS 只有在部署的时候可以被修改，一旦部署后就会固定；
3. 原子更新：是由不可变导致的，因为不可变，所以只能整体进行更新；
4. 应用以容器形式运行：既然是容器 OS ，那我们当然希望它只提供最基础的功能，而各种功能以容器形式运行。

业界背景

        近几年，有了新的发展，出现了 Kubernetes OS —— 为Kubernetes 更好运行而设计的一种容器 OS，它相较我们刚才的介绍以外，最主要的特征是集成了某些 Kubernetes 的社区版本，它能够将 OS 的管理交由 Kubernetes 控制。

        其实业界已经有了一些发行的容器 OS，如 AWS 的 Bottlerocket，Rancher 的 k3os，都是针对各自操作系统的用户而做出的版本，各容器 OS 实现细节有所不同，但设计理念大致相同。

KubeOS

        KubeOS 就是在这样的技术背景和需求下发展的容器 OS。

        KubeOS 的镜像都是基于 openEuler repo 源进行构造的，KubeOS 部署以后，能够在 Master 节点上仅通过 kubectl 命令行、yaml 文件进行管理集群所有 worker node 上面的 OS 版本。因为 KubeOS 将 OS 作为 Kubernetes 上面的一个组件接入到集群中，这样 OS 与其它业务容器就处于同等地位，达到 Kubernetes 统一管理容器和 OS，实现 OS 和业务调度的协同。同时，还根据 openEuler 的版本进行了定制化的改造，使得 KubeOS 原子化的更新升级，避免版本分裂。

feature 1：OS 作为组件接入 Kubernetes

OS 以 CRD 对接 Kubernetes，使 OS 和业务处于同等地位，通过 Kubernetes Operator 扩展机制对 OS 进行管理。

1. 为 OS 设计了 CRD 的 API 对象，将其注册到集群中
2. 依托于 Kubernetes Operator 扩展机制，定义了一个 OS controller，对 API 对象进行管理和监控

        由此，OS 和 container 具有了同等地位，用户只用输入预期的 OS 版本、状态。其他的操作都可以交由 KubeOS 和 Kubernetes 去进行。

feature 2：OS 原子升级

1. 不提供包管理器，软件包变化即 OS 版本变化
2. OS 轻量化，仅包含 Kubernetes 和 容器运行所需的组件，约二百个包
   1. 减少攻击面，让 OS 更加安全
   2. 可以进行快速升级，替换

如图所示，可以保证集群中 OS 版本一致，可以保证大规模应用的部署。

KubeOS 架构设计

三个重要组件

• os-operator：监控集群中所有节点上的 OS 实例，收集所有节点 OS 信息，实现全局 OS 的生命周期管理。当用户去修改 OS 信息之后，operator 会感知到，并将升级任务下发到各个节点
• os-proxy：监控单节点的 OS 实例，收集单节点 OS 信息，当它接收到 operator 下发的升级任务时，它会封锁节点、迁移 pod，将收集到的 OS 信息转发给 os-agent
• os-agent：接受 os-proxy 相关命令，是 容器 OS 生命周期管理的执行单元，维护容器 OS 安装、升级等

operator、proxy 以容器形式运行，部署在集群中，agent 以进程形式运行在机器中。

KubeOS 文件系统布局设计

rootA、rootB：双分区升级，每个分区存放一个版本的 OS image，每次升级时会下载一个版本到另一个分区，下次启动时将目录切换到另一个分区，就完成了双分区的升级

persist 分区：出于安全性考虑，KubeOS 文件系统是只读的，但是我们还是提供了 persist 分区，供用户存放持久性数据。其中包括
        1. Union Path，采用 overlay 形式，挂载在镜像上覆盖一个叠加层；

        2. Writable Path，使用 bind mount 形式，直接在镜像上增加一个可写层。

boot 分区：grub2文件分区

之前版本的分区大小固定，现在 rootA、rootB、persist 分区可以支持自定义分区大小。

KubeOS 升级流程

1. 用户修改 yaml 文件，指定要收集的 OS 信息，如 OS 版本、存放镜像的地址、一次升级 OS 的数量等，然后将它 apply 到集群中；
2. 当集群中 OS 的状态发生变化以后，os-operator 就会感知到这个变化，随后查询集群中所有节点的变化，发现与变化节点不一致的时候，它就会将需要升级的节点标记为升级节点，相当于将任务下发到各个节点；
3. os-proxy 监控当前节点，它发现自己的节点被标记为升级节点了，它就会开始执行升级操作，它从集群中获取自己要升级到哪个 OS 版本，然后将当前节点的所有 pod 驱逐，然后将当前节点锁定，然后它会把 OS 的信息发送给 os-agent；
4. os-agent 接收到相关信息之后，会前往用户指定的存放镜像服务器，进行镜像下载，设置启动分区，随后进行升级和重启；
5. os-proxy 持续监控当前节点，发现已经升级完成，将当前节点解锁，并取消升级的标记。

好了，这就是对于 KubeOS 的整体介绍，接下来的前进方向有

• 更丰富的功能
  • 系统配置、安全策略...
• 更全面的支持
  • 多架构、多引擎...
• 更方便的部署
  • 一键式部署...

值得一提的是，CNCF 在预备一个 容器 OS group，可能会对当前没有统一标准的容器 OS 提供一个规范，让我们期待一下。