共计 4406 个字符，预计需要花费 12 分钟才能阅读完成。
简介：如果能够把运维 API 化，那咱们是不是能够把 OS 也作为一个 K8S 能够治理的资源，让 K8S 像治理容器一样治理 OS？
引言
在 2021 年 10 月的云栖大会上，为云原生而生的 OS Lifsea 正式对外公布，并集成进入阿里云容器服务 ACK Pro 的托管节池，成为可选的操作系统选项。
不久前，LifseaOS 外围代码正式在龙蜥社区开源，用户能够基于 LifseaOS 开源代码构建、定制一个属于本人的容器专属 OS。
WHY LifseaOS？
说到 LifseaOS，不得不提到其次要面向的场景：容器。
从最早的 UNIX chroot，到 Linux 的 LXC，晚期以 cgroup、namespace 为根底的容器运行时技术始终在继续演进，但并没有呈现阶段性的冲破。直到 2013 年，docker 的呈现间接推动了容器的疾速遍及，通过短短几年的倒退，容器曾经成为了支流的 IT 基础设施技术被宽泛地利用。容器的疾速倒退 docker 功不可没，而咱们回顾过后 docker 最后的工作，能够发现其并没有进行颠覆性的技术改革，其外围翻新次要包含以下两个局部：
- 定义了容器分层镜像规范以及镜像仓库：容器镜像将利用运行环境，包含代码、依赖库、工具、资源文件和元信息等，打包成一种操作系统发行版无关的不可变更软件包
- 定义了笼罩容器全生命周期 restful API：restful API 的将整个容器的创立、监控、销毁过程标准化，部署、运维人员能够在一个集群内对大量的容器进行统一化的治理
这两个要害翻新带来了整个开发、集成、部署的反动。首先镜像能力为 devops 提供了一条便捷的路线，开发人员能够在开发过程中便实现对于整个运行环境的把控，将本人开发成绩间接上线部署生产投入，无需再去思考操作系统兼容、库依赖等环境因素，实现了 docker 的口号“Build，Ship and Run Any App，Anywhere”。其次，restful API 呈现使得容器的生命周期治理更加的便捷，利用编排工具对容器的治理，SRE 能够疾速、无差别地进行利用的部署、降级、下线，实现了针对利用治理由“宠物”到“牛群”的质的飞越。
随同着容器一起倒退的是以容器为根底衍生而出的容器编排、容器存储、容器网络等畛域，这些畛域紧密结合造成了“云原生”生态，并且在 2015 年开始，围绕着 K8S 逐步形成了一套残缺的“云原生操作系统”。通过 K8S，用户能够在一个分布式集群内疾速、高效地部署容器，无需再去关注简单的集群资源分配、容器调度等工作。为了残缺地反对 K8S，云厂商也进行了大量的 K8S 的撑持对接，纷纷提供适配本身 I 层基础设施的 CNI（Container Network Interface）、CSI（Container Storage Interface）以及绝对应的 cluster-autoscaler 等组件，让 K8S 能够完满的治理本人的存储、网络、计算资源。
在基础设施纷纷“云原生化”的过程中，有一个同属于 Infra 的组件却步骤迟缓，这就是操作系统，也就是咱们始终说的 OS。尽管存在感并不是很强，然而 OS 作为下接硬件、上接业务的底层软件，默默地为利用提供了单机资源管理、运行环境构建等能力，施展着无足轻重的作用。然而在云原生场景下，传统操作系统曾经逐步体现出各种“不适”：
- 体积臃肿：传统的操作系统为了兼容不同的应用场景，蕴含了各种各样的硬件驱动、软件包、零碎库、零碎服务等，操作系统后盾服务繁多，体积也显得宏大。在云原生容器场景下，必要的服务大都曾经被容器化，以容器的形式被部署到节点上，通过容器的形式来实现版本、配置的治理，逐渐取代了传统 OS 上的零碎服务；同时，云上硬件资源通过云厂商的虚拟化形象往往更加地简化，并不需要去反对各种硬件。而容器镜像自身就有运行时自蕴含的能力，因而很多传统 OS 上的能力会显得厚重而冗余，这些厚重的组件还会使整个 OS 启动变慢并占用相当的系统资源（CPU、内存等）。
- 版本零散：为了可能反对不同的诉求，操作系统提供了各种各样不同的软件，并以软件包为粒度进行版本治理，每个软件包有本人独立的性能以及代码、版本号，由用户依据本身的需要进行软件包的增、删。这样每台宿主机上的 OS 状态是由大量不同软件包版本号组成的，而在日常运维时个别是针对某一个软件包进行治理。在云原生的场景下，集群计算节点日趋增多，生产过程中因为 bugfix、问题定位等可能在某一节点上针对某个包进行治理（降级、配置批改等），如果没有一套残缺的集群 OS 运维机制，极容易呈现集群内 OS 状态不对立的状况，如果在灰度的过程中呈现依赖组件版本不一，可能会导致整个公布流程碰壁，给运维人员带来极大的艰难。
- 平安危险：一方面，传统操作系统蕴含了大量云原生场景下不须要的软件包和零碎服务，带来更大的攻击面。另一方面，传统操作系统的运维人员大多通过 ssh 登录进零碎进行黑屏的运维操作，过程难以追溯，误操作极易带来灾难性的结果。
以上的问题次要还是体现在运维上，这时咱们回头看下，在 docker 呈现之前，利用的运维人员也有相似的问题：如何保障利用在不同条件下运行环境的匹配统一、如何便捷疾速地治理利用等。而 docker 很好地解决了应用层的问题，那是不是咱们能够借鉴 docker 的思路来解决 OS 运维的问题？
其实在业界曾经有了一些容器优化版操作系统，即咱们常说的 ContainerOS，包含 AWS 的 bottlerocket、Redhat 的 Fodera CoreOS 以及 Rancher 的 RancherOS 等，它们大多具备以下特点：
- 轻量化：操作系统仅仅蕴含足够撑持容器运行所需的软件包与零碎服务，大大减少攻击面，启动快。
- 原子降级回滚：基于不可变基础设施的设计准则，提供只读根文件系统保证系统不被歹意篡改，操作系统的治理以镜像为粒度，不提供 YUM 等包管理软件，整个零碎以镜像为粒度进行降级与回滚。Bottlerocket 采纳了 A/B 双分区的形式实现镜像的原子降级，CoreOS 则通过 rpm-ostree 像治理一个 git 代码仓一样治理一个 OS 版本，而 RancherOS 则更加激进地把所有的零碎服务全副容器化，实现用容器 ” 治理 ” 操作系统镜像。
- 默认集成云原生组件：默认装置 docker/containerd/kubernetes 等云原生组件，操作系统开箱即用，不须要用户进行额定的安装操作，简略易用。
- 受控的运维通道：零碎去除 sshd 服务，不容许间接登录零碎进行运维，同时提供丰盛的 API 接口用于主机的运维，另外还提供专用的运维容器作为最初的“进路”用以登录零碎。
这些特点其实也印证了咱们的思考：用镜像的形式解决版本零散的问题，用 API 解决集群运维的问题，而咱们更是发现，如果能够把运维 API 化，那咱们是不是能够把 OS 也作为一个 K8S 能够治理的资源，让 K8S 像治理容器一样治理 OS？
LifseaOS：为云而生的操作系统
基于以上的思考，咱们推出了 LifSeaOS，一款为云原生而生的 OS。
LifseaOS 连续了 CoreOS rpm-ostree 的技术流派，基于由龙蜥社区 (OpenAnolis) 公布的龙蜥操作系统(Anolis OS) 作为软件包选型根底。
LifseaOS 应用了 rpm-ostree 的性能，实现镜像的原子性降级回滚，让用户能够在集群维度对 OS 镜像进行 rolling upgrade，像治理牛群一样治理一整个集群的操作系统；同时做了大量的裁剪优化，使整体 OS 更轻、更快、更平安。
同时，咱们提供了一个用于 OS 运维的小工具（性能还在继续丰盛中），将惯例的 OS 运维形象进去并进行收敛，借助阿里云云助手或自动化运维编排服务，用户针对 OS 的运维操作通过调用运维工具的形式进行，缩小针对操作系统的开放性操作，并进行相应的审计。
API 化运维更重要的作用是将 OS 运维往云原生的方向牵引，咱们能够通过一个 K8s 的 controller 对接运维 API，联合上述的 OS 版本化，让 K8s 像治理一个容器一样治理一个 HostOS。
当然，LifseaOS 的特色不仅仅是以上形容的镜像版本化和运维 API 化，它的名字也间接论述了 LifseaOS 作为一个为云而生、为容器而生的 OS 所具备的特质：
Lightweight
LifseaOS 默认集成 containerd、kubernetes 组件，仅仅保留 kubernetes pods 运行所需的零碎服务与软件包，整个零碎大概只有 200 左右的软件包，相比传统操作系统（Alibaba Cloud Linux 2/3、CentOS）500+ 软件包而言，数量缩小 60%，更加的轻量。
沉重的 cloud-init（云厂商罕用的云主机元数据管理组件）套件被替换为 CoreOS 的 Ignition，且裁剪了大量不须要的性能，仅保留最根底的磁盘扩容、hostname 配置、chronyd 时区同步服务器配置与执行 user-data 脚本的性能。去除了不必要的内核模块、systemd 服务（比方 systemd-logind、systemd-resolved）以及 systemd 附带的许多实用性极低的小工具。
Fast
LifseaOS 的定位是跑在云上虚拟机的操作系统，所以不会波及到太多的硬件驱动，必要的内核驱动模块批改为 built-in 模式，去除了 initramfs，udev 规定也被大大简化，这样，启动速度失去了大幅晋升，以 ecs.g7.large 规格的 ECS 实例为例，LifseaOS 的首次启动工夫放弃在 2s 左右：
传统的操作系统，以 Alibaba Cloud Linux 3 为例，首次启动工夫则在 1min 以上：
Security
LifseaOS 根文件系统为只读权限，只有 /etc 和 /var 目录可写以满足根底的系统配置需要。这种设计既合乎云原生场景下的基础设施不可变准则，又能避免逃逸容器篡改主机文件系统。不反对 python 但依然保留了 shell（因为 ACK 在集群部署阶段须要执行一系列的 shell 脚本来进行初始化工作，后续会思考进一步去除）。
另外，LifseaOS 去除了 sshd 服务，禁止用户间接登录到零碎中进行一系列可能无奈追溯的操作；当然，思考到非凡运维或者紧急运维的须要，LifseaOS 依然提供一个专用的运维容器满足非日常的运维需要，运维容器须要通过 API 按需拉起，默认不开启。
Atomic
LifseaOS 不反对单个 rpm 包的装置、降级和卸载，不提供 yum，所以去除了 Fedora CoreOS 里的 rpm-ostree 软件包而仅保留 ostree 的性能（前者提供了以 rpm 包为粒度的治理性能，而后者仅仅管理文件）。以整个镜像为粒度的更新和回滚极大水平上保障整个集群内的各个节点的软件包版本与系统配置的一致性。每个镜像通过外部严格的测试之后才会上线，相较于传统操作系统基于单个 rpm 包的降级带来的不确定性，以镜像为粒度的测试公布更能保障降级后零碎的稳定性。
原文链接
本文为阿里云原创内容，未经容许不得转载。