第 5 章 Red Hat Enterprise Linux CoreOS (RHCOS)
5.1. 关于 RHCOS
Red Hat Enterprise Linux CoreOS (RHCOS) 代表了下一代单用途容器操作系统技术。RHCOS 由创建了 Red Hat Enterprise Linux Atomic Host 和 CoreOS Container Linux 的同一开发团队打造，它将 Red Hat Enterprise Linux (RHEL) 的质量标准与 Container Linux 的自动化远程升级功能结合在一起。
对于所有 OpenShift Container Platform 机器，仅支持将 RHCOS 作为 OpenShift Container Platform 4.2 的组件。RHCOS 是唯一受 OpenShift Container Platform control plane 或 master 机器支持的操作系统。虽然 RHCOS 是所有集群机器的默认操作系统，但您仍可以创建使用 RHEL 作为其操作系统的计算（compute）机器（也称为 worker ）。
如果将集群安装到集群置备的基础架构上，则要在安装过程中将 RHCOS 镜像下载到目标平台，并且使用控制 RHCOS 配置的合适 Ignition 配置文件来部署机器。如果将集群安装到您自己管理的基础架构上，则必须遵循安装文档来获取 RHCOS 镜像，生成 Ignition 配置文件，并且使用 Ignition 配置文件来置备机器。
5.1.1. RHCOS 主要功能
下表描述了 RHCOS 操作系统的主要功能：
底层操作系统主要由 RHEL 组件构成。支持 RHEL 的相同质量、安全性和控制措施也支持 RHCOS。例如，RHCOS 软件位于 RPM 软件包中，并且每个 RHCOS 系统都以 RHEL 内核以及由 systemd 初始化系统管理的一组服务启动。
尽管 RHCOS 包含 RHEL组件，但它的管理要比默认的 RHEL 安装更加严格。管理从 OpenShift Container Platform 集群远程执行。设置 RHCOS 机器时，您只能修改一些系统设置。这种受控的不变性使 OpenShift Container Platform 可以存储集群中 RHCOS 系统的最新状态，因而始终都能创建额外的机器并根据最新的 RHCOS 配置执行更新。
尽管 RHCOS 包含运行 Docker 所需的 OCI 和 libcontainer 格式容器的功能，但它融合的是 CRI-O 容器引擎，而非 Docker 容器引擎。通过专注于 Kubernetes 平台（例如 OpenShift Container Platform）所需的功能，CRI-O 可以提供与不同 Kubernetes 版本兼容的特定功能。与提供更大功能集的容器引擎相比，CRI-O 对内存的要求更低，且对安全的攻击面更小。目前，CRI-O 仅可用作 OpenShift Container Platform 集群中的容器引擎。
对于诸如构建、复制和以其他方式管理容器的任务，RHCOS 用一组兼容的容器工具来代替 Docker CLI 工具。podman CLI 工具支持许多容器运行时功能，例如运行、启动、停止、列举和删除容器及容器镜像。skopeo CLI 工具可以复制、身份认证和签名镜像。您可以使用 crictl CLI 工具来处理 CRI-O 容器引擎中的容器和 Pod。虽然不建议在 RHCOS 中直接使用这些工具，但可以把它们用于调试目的。
RHCOS 具有使用 rpm-ostree 系统进行事务升级的功能。更新是通过容器镜像交付的，并且是 OpenShift 更新过程的一部分。部署之后，拉取、提取容器镜像并将其写入磁盘，然后修改启动加载程序以启动到新版本。机器将以滚动方式重启并进入更新，确保对集群容量的影响最小。
对于 RHCOS 系统，rpm-ostree 文件系统的布局具有以下特征：
-
/usr是操作系统二进制文件和库的存储位置，并且是只读的。我们不支持更改此设置。 -
/etc、/boot和/var在系统上是可写的，但只能由 Machine Config Operator 更改。 -
/var/lib/containers是用于存储容器镜像的图形存储位置。
在 OpenShift Container Platform 中，Machine Config Operator 处理操作系统升级。rpm-ostree 以原子单元形式提供升级，不像 yum 升级那样单独升级各个软件包。新的操作系统部署在升级过程中进行，并在下次重启时才会生效。如果升级出现问题，则进行一次回滚并重启就能使系统返回到以前的状态。OpenShift Container Platform 中的 RHCOS 升级是在集群更新期间执行的。
5.1.2. 在 OpenShift Container Platform 中配置 RHCOS
对于 OpenShift Container Platform，RHCOS 镜像最初使用称为 Ignition 的功能进行设置，该功能仅在系统首次启动时运行。首次启动后，RHCOS 系统由 OpenShift Container Platform 集群中运行的 Machine Config Operator (MCO) 进行管理。
由于 OpenShift Container Platform 中的 RHCOS 系统设计为可从 OpenShift Container Platform 集群中进行全面管理，因此不建议直接登录 RHCOS 机器。出于调试目的，可以对 OpenShift Container Platform 集群中的 RHCOS 机器进行有限的直接访问。
5.1.3. 关于 Ignition
Ignition 是 RHCOS 在初始配置期间用于操作磁盘的实用程序。它可完成常见的磁盘任务，如分区磁盘、格式化分区、写入文件和配置用户等。首次启动时，Ignition 从安装介质或您指定的位置读取其配置，并将配置应用到机器。
无论您要安装集群还是向其中添加机器，Ignition 始终都执行 OpenShift Container Platform 集群机器的初始配置。实际的系统设置大多都在每台机器上进行。对于每台机器，Ignition 都会获取 RHCOS 镜像并启动 RHCOS 内核。内核命令行上的选项标识部署的类型，以及启用了 Ignition 的初始 Ram 磁盘 (initramfs) 的位置。
OpenShift Container Platform 使用 Ignition 版本 2 和 Ignition 配置版本 2.3
5.1.3.1. Ignition 工作方式
要使用 Ignition 创建机器，需要 Ignition 配置文件。OpenShift Container Platform 安装程序创建部署集群所需的 Ignition 配置文件。这些文件基于您直接提供给安装程序或通过 install-config.yaml 文件提供的信息。
Ignition 配置机器的方式类似于 cloud-init 或 Linux Anaconda kickstart 等工具配置系统的方式，但有一些重要的区别：
- Ignition 从一个初始 RAM 磁盘运行，该磁盘与您要安装到的系统相隔开。因此，Ignition 可以重新分区磁盘、设置文件系统，以及对机器的持久文件系统执行其他更改。与之相反，cloud-init 会在系统启动时作为机器的初始系统的一部分运行，因而不易对磁盘分区之类的事项进行基本的更改。使用 cloud-init 时，难以在节点启动期间重新配置启动过程。
- Ignition 旨在初始化系统，而不是更改现有系统。机器完成初始化且内核在安装的系统上运行之后，OpenShift Container Platform 集群中的 Machine Config Operator 将完成所有后续的机器配置。
- Ignition 不是完成一组定义的操作，而是实施声明性配置。它会在新机器启动之前检查所有分区、文件、服务和其他项目是否就位。然后进行更改，例如将必要的文件复制到磁盘，以便新机器符合指定的配置。
- 在 Ignition 完成机器配置之后，内核将继续运行，但会丢弃初始 RAM 磁盘，并转至磁盘上已安装的系统。所有新的系统服务和其他功能都将启动，无需重启系统。
- 因为 Ignition 会确认所有新机器是否都符合声明的配置，所以不会存在配置不全的机器。如果机器设置失败，则初始化过程不会完成，而且 Ignition 也不会启动新机器。您的集群永不会包含配置不全的机器。如果 Ignition 无法完成，机器就不会添加到集群中。您必须添加新的机器。一些失败配置任务的结果可能一直不为人所知，直到后来依赖它的某些事物也失败才被发现。对这类问题的故障排除将会非常困难。而 Ignition 配置的工作方式可以防止出现这个问题。
- 如果 Ignition 配置存在问题，而导致一台机器的设置失败，Ignition 不会尝试使用相同的配置来设置另一台机器。例如，故障可能源自于某一个 Ignition 配置，而构成该配置的父级和子级配置都希望创建同一个文件。在这种情况下，出现的故障将导致 Ignition 配置无法再次用于设置其他机器，直到问题解决为止。
- 如果您有多个 Ignition 配置文件，您可获得该组配置的并集。由于 Ignition 是声明性的，配置之间的冲突可能会导致 Ignition 无法设置机器。这些文件中信息的次序无关紧要。Ignition 将以最有成效的方式对每项设置进行分类和实施。例如，如果一个文件需要有多个层级深的目录，而另一个文件需要其路径上的某一目录，则首先创建后一个文件。Ignition 按深度排序并创建所有文件、目录和链接。
- 因为 Ignition 可以从全空的硬盘开始，所以它可以做 cloud-init 不能做的任务：从头开始在裸机上设置系统（使用 PXE 启动等功能）。在裸机情形中，Ignition 配置注入启动分区，以便 Ignition 可以找到它并正确配置系统。
5.1.3.2. Ignition 操作序列
OpenShift Container Platform 集群中 RHCOS 机器的 Ignition 过程包括以下步骤：
- 机器获取其 Ignition 配置文件。Master 机器从 bootstrap 机器获取 Ignition 配置文件，worker 机器从 master 机器获取 Ignition 配置文件。
- Ignition 在机器上创建磁盘分区、文件系统、目录和链接。它支持 RAID 阵列，但不支持 LVM 卷。
-
Ignition 将持久文件系统的根目录挂载到 initramfs 中的
/sysroot目录，然后开始在/sysroot中工作。 - Ignition 配置所有定义的文件系统，并将它们设置为在运行时进行相应地挂载。
-
Ignition 运行
systemd临时文件，将必要的文件填充到/var目录。 - Ignition 运行 Ignition 配置文件，以设置用户、systemd 单元文件和其他配置文件。
- Ignition 卸载 initramfs 中挂载的持久系统中的所有组件。
- Ignition 启动新机器的初始化过程，该过程再启动系统启动期间在机器上运行的所有其他服务。
然后，机器便已准备好加入集群，不需要重启。
