一款跑在云上的定制容器专属 OS 来了——LifseaOS

引言

在 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 包的升级带来的不确定性，以镜像为粒度的测试发布更能保证升级后系统的稳定性。