作者 | 李元戎
策动 | 王一鹏
在云原生场景下，容器和kubernetes在开发、测试、出产中的运用愈来愈普遍，传统的操作零碎往往会带来平安性、运维开消、OS 版本等方面的问题，容器操作零碎即容器 OS 是针对云原生场景设计的一种轻量化操作零碎。本次分享首先引见容器 OS 的理念，而后分享在openEuler社区孵化的容器操作零碎 KubeOS 的设计思绪和解决的问题，最初深化引见 KubeOS 的架构、功用和使用。
本文整顿自华为操作零碎开发工程师、KubeOS 开源名目担任人李元戎在DIVE寰球根底软件翻新大会 2022 的演讲分享，主题为“KubeOS : 面向云原生场景的容器操作零碎”。分享次要分为三部份：1.云原?场景下 OS 办理问题与解决?法；2.KubeOS:?向云原?场景的容器操作零碎；3.将来的任务。
云原?场景下 OS 办理问题与解决?法
当初说起容器，大家想到的根本上都是Docker。
Docker 在 2013 年开源当前就当即火爆了起来，能够说 Docker 将容器技术推向了巅峰。那末 Docker 技术究竟解决了一个甚么样的问题呢？Docker 本人鼓吹的标语是：一次构建四处运转。
它一举解决了开发、测试、出产中环境纷歧致这困扰业界多年的问题。从更高的维度来讲，Docker 其实解决的是软件究竟应该经过甚么样的形式进行交付。当软件的交付形式变得明晰明白当前，那末咱们做托管软件的平台也就变得十分简略明了了。
Docker 提供了三个概念：容器、镜像和镜像仓库，经过 Docker Client 能够以 Restful API 的形式去办理容器的全生命周期。那末 Docker 最中心的翻新是甚么呢？其实就是 Docker 镜像这个概念，经过 Docker 容器镜像，能够将一个运用软件运转依赖的整个环境都打包在一同，让这个顺序经过 Docker 容器运转的时分能够与操作零碎是有关的。这样也就根本上完成了它所鼓吹的 run anywhere。
Docker 镜像为了能够同享资源，在制造过程当中引入了层的概念。也就是说假如想做一个新的容器镜像，不需求从头开始做，只需求找到一个有 Root FS 的 Base Image ，当前需求甚么就能一层一层的往上叠加。Docker 容器其实也是基于分层概念，容器运转的时分它就会在镜像下面减少一个可写层，也就是咱们常说的容器层，而后容器层上面是镜像层，镜像层都是只读的。容器镜像的一个中心的特性就是 copy on right，能够把关于容器的修正全限度在容器层下，不会影响其余同享这个镜像的容器。Docker 在单机上的打包、发送、运转的机能是很优秀的，但只在单机上运转其实不能发扬它最大的价值。业界更但愿基于 Docker 技术能够造成云化的集群零碎，而后进行业务容器的调度和编排。那咱们就要说接上去的 Kubernetes 了。
Kubernetes 当初能够说曾经真正成了寰球的主流技术。2017 年的时分，Kubernetes、Swarm 和 Mesos 三家容器编排零碎的大战就根本上完结了，Kubernetes 成了最初的赢家，成了容器编排零碎的事实规范。Kubernetes 的思想是将所有都视为资源，好比说 node、POD、deployment、service，这些日常的、内置的资源关于个别的零碎部署降级和办理是够用的。然而在一些特定的场景下，当内置的资源不知足需要的时分，Kubernetes 又提供了一种扩展的机制，你能够把需求的新资源笼统成 Kubernetes 的 API 对象，而后注册到集群中，和其余资源一同来使用，即 CRD 机制。说起 CRD 就不能不提 operator。其实从 Kubernetes 的设计和定义来看，它其实似乎更合用于无形态的运用。
然而 CoreOS 公司它基于 Kubernetes 的声明式 API 机制提出的 Kubernetes operator 能够无效解决有形态的运用或者是散布式运用的形态形容，在 operator 傍边的 API 对象再也不是形容单形态运用的形态，而是去形容散布式运用集群的形态。也就是说它把一个残缺的散布式运用的集群都算作 Kubernetes 它需求终究去保护的这类终究的形态。当你定义的散布式运用集群的形态产生改动当前，operator 会按照完成代码去履行相应的逻辑功用，而后达到向咱们预期的形态不断演进的功用。
能够说容器和 Kubernetes 增进了云原生生态的开展，在根底设施纷纭云化的状况下，云原生场景下 OS 办理的问题也就随之而来了。
首先是 Kubernetes 其实不能对集群节点的 OS 进行办理，所以云原生场景下 OS 办理的第一个问题，Kubernetes 和 OS 是分别独立进行办理的。Kubernetes 也需求进行更新保护，而后进行用户权限管制，这和 OS 的办理其实十分相似。所以当运维人员分别对 Kubernetes 和 OS 进行办理的时分，他往往需求进行得多冗余操作。按理来讲是但愿它们相互可以感知的，然而实际上这两套零碎相互协调十分难题，乃至它们之间基本就没有协调。所以当 OS 降级影响到了节点可用性的时分，Kubernetes 无奈进行感知。假如 OS 进行降级，又但愿集群中业务不间断，运维人员首先需求锁定节点，让任务负载再也不调配到这个节点，而后需求把这个节点上的 POD 调入到其余节点，而后能力去降级这个节点，最初再把这个节点解锁，恢复正常的运用，这无疑减少了运维的难度和开消。
第二个问题就是 OS 的版本办理问题。一个通用的 Linux 操作零碎，个别都会内置一个软件更新降级的保证理器，经过这个保证理器，每一个个包独立进行装置、降级、删除，这关于操作零碎来讲十分灵敏。
然而在云原生场景下，往往会带来版天职裂的问题。就像图中所示，一开始这个集群中两个节点的包版本都是统一的。然而跟着使用，有的包降级了，有的包没降级，或者降级的版本纷歧致。时间久了集群中每一个台节点都会有不同的软件包，不同的版本，这样酿成的版天职裂问题是很重大的。
假如 OS 和业务耦合对比严密的话，OS 进行大版本的降级也会对比难题。业界对比主流的思想是经过革新 OS 来解决以上问题。由于容器把运用运转所需求依赖的环境都打包到了容器镜像外面。它对一个操作零碎所需求的功用愈来愈少，所以就有了轻量级的操作零碎。为了容器运转而设计的这类轻量级操作零碎，咱们叫它为容器 OS，也就是 Container OS，也能够叫做 Container specific OS。
那末对一个容器 OS 来讲，都需求它有甚么呢？首先确定是有一个 Linux kernel，而后要有容器引擎，好比 Docker，而后还需求一些平安的机制，这些就够了。所以容器 OS 第一个特征就是极简化，它包孕的软件包对比少，相应的攻打面和破绽确定就少，容器 OS 就更平安。第二个特征是不成变，只要在部署的时分能够修正，一旦部署就是固定的。第三个是原子更新，由于它不成变，所以只能总体进行更新。最初是运用以容器的方式运转。
KubeOS:?向云原?场景的容器操作零碎
近几年容器 OS 又有了新的开展，Kubernetes OS 除了方才讲的容器 OS 的特点之外，最明显的特点是集成为了 Kubernetes 的某些社区版本。它会把 OS 的办理交由 Kubernetes 去管制，由 Kubernetes 来管制 OS 的更新。其实业界曾经有一些主流的操作零碎公司推出了这样的容器 OS，KubeOS 就是 openEuler 推出的这样一款容器 OS。
KubeOS 的镜像都是基于 openEuler Repo 源进行结构的。KubeOS 部署当前，用户能够在 master 节点上只经过命令行和 Yaml 文件就去办理集群一切 worker node 下面的 OS 版本。由于 KubeOS 将 OS 作为 Kubernetes 的一个组件接入到集群中,这样 OS 和其它的业务容器就位于等同位置，能够经过 Kubernetes 一致去办理容器和 OS，完成 OS 和业务容器的协同调度。而且咱们还基于 openEuler 的版本进行了一些定制化的革新，让 KubeOS 能够进行原子化更新降级，防止版天职裂的问题。
上面对KubeOS进行一个具体的引见。KubeOS 的第一个特性是将 OS 作为组件接入到 Kubernetes 中。咱们利用 Kubernetes 的 API 扩展机制为 OS 设计了一个 CRD 的 API 对象，而后把它注册到集群中，而且依靠于 Kubernetes 的 operator 扩展机制订义了一个 OS controller，去对以前注册阿谁 OS 对象进行办理和监控。这样就让 OS 和集群中其余的内置资源处于等同位置，均可以经过 kubernetes 进行办理。用户只需求修正 OS 的 CR，而后输出预期的 OS 版本和形态，其余操作均可以由 KubeOS 和 Kubernetes 实现。这样 OS 的办理就在云端进行了。
KubeOS 的第二个特性是 OS 是进行原子降级的，KubeOS 中不提供保证理器，软件包的变动即 OS 版本的变动，也就是说每一个个 OS 的版本都会对应一个肯定的 OS 镜像，或者说一组肯定的 RPM 包的组合。如图所示，软件包的更新即为 OS 版本的更新，这样能够让任什么时候候集群中的 OS 的版本是肯定的、统一的，有助于大范围运用的部署。而且咱们 OS 是尽可能轻量化的，只包孕 Kubernetes 和容器运转所需求的组件，这样不只增加攻打面，让 OS 更为平安，也能够进行疾速的更新，疾速的降级。
如图是 KubeOS 的架构设计，KubeOS 一共分红三个模块，第一个模块 OS operator 部署在 master 节点上的，它是全局的 OS 办理器，会监控集群中一切节点的 OS 的形态。当用户去更改集群中 OS 信息的时分，好比说指定了新的版本，Operator 会感知到，而后把降级工作下发到各个节点上。OSProxy 它就是部署在每一个个节点上，它就是单节点的 OS 办理器，会监控以后节点的形态，当他接到 Operator 下发的降级工作时，会去做好比说封锁节点、迁徙 Pod 这些操作，而且把需求降级的 OS 信息转发给 OS Agent，OS Agent 是真实的 OS 降级的履行单元，它接纳来自于 OS Proxy 的相干信息，实现降级和重启操作。
如图是 KubeOS 的文件零碎规划的设计，首先是 Root 分区，由于 KubeOS 咱们采取了双分区降级的形式，每一个个分区它会寄放一个 OS 的版本，所以说分红了 RootA 和 RootB，每次降级的时分会下载 OS 镜像到此外一个分区，在下次启动的时分将启动目录切换到此外一个分区，就实现了双分区的降级，而且 KubeOS 文件零碎是只读的，这也是为了平安性的斟酌，然而咱们仍是提供了一个 persist 分区，用它寄放耐久性的用户数据，它其中有一个 Union Path，它采取 overlay 的方式，在镜像上减少叠加层，还有一个 Writable Path，它次要使用 bind mount 方式，间接在镜像下面减少了一个可写层，最初是 Boot 分区，寄放的是 grub2 文件。
最初咱们再引见一下 KubeOS 的降级流程。首先第一步，用户经过修正 OS 的 Yaml 文件，指定要降级的 OS 信息，好比 OS 的版本、寄放镜像的地址，以及一次降级的 OS 的数量。
当集群中 OS 的形态产生了变动当前，OS Operator 就会感知到这个变动，去查问集群中一切节点的形态，若发现和以后节点的形态纷歧致，就会把需求降级的节点标志为降级节点，至关于把工作下发到各个节点了。
OSProxy 监控发现以后的节点被标志为降级节点了，就开始履行降级操作，从集群中获得要降级到的 OS 的版本，它把以后节点的一切 Pod 进行摈除，并把以后节点锁定，把 OS 的信息发送给 OS Agent，Os Agent 接纳到相干的信息当前，从一开始用户指定的降级镜像寄放的办事器下载镜像，而后设置启动分区，进行重启和降级。降级当前 OS Proxy 看以后节点的形态发现曾经降级实现了，就把以后节点从新解锁，而且勾销降级标志。
将来的任务
咱们接上去要做甚么？首先咱们需求去不停丰硕 KubeOS 的功用，好比提供零碎配置下发的功用，提供更多的平安战略。第二点是要不停完美，好比更片面的反对，提供反对更多的架构，更多的容器引擎等等。还有就是让 KubeOS 的使用和部署变得更为便利，好比提供一键式的部署。
注册会员