RHCOS(Red Hat Enterprise Linux CoreOS )简介

参考：rhcos-about_architecture-rhcos简介

2.3. 强化 RHCOS OpenShift Container Platform 4.11 | Red Hat Customer Portal

RHCOS下载地址：https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/4.11/latest/ 

一、CoreOS简介

       CoreOS 是为云而生的操作系统，它是一种基于 Chrome OS 再定制的轻量级 Linux 发行版本。

       作为一个操作系统，CoreOS 采用了高度精简的系统内核及外围定制，将许多原本需要复杂人工操作或者第三方软件支持的功能在操作系统级别进行了实现，同时剔除了其他对于服务器系统非核心的软件，比如GUI和包管理器。

      CoreOS 没有提供现成的包管理工具，CoreOS 并不鼓励用户将各种应用软件直接安装在操作系统之上，而是提倡将所有服务运行在单独的应用容器中，由应用容器提供应用所需要的基础功能环境。这种做法将操作系统和应用程序的职责做了更彻底的分离，降低操作系统和应用程序的耦合度，使运行这些服务器的公司可以更快速、更廉价地更新自己的线上业务。

1.1 启动速度

       CoreOS 做了最大的精简，不仅使得系统与应用高度分离，更获得了极大的启动速度提升。根据官方数据，其系统运行时内存使用量只有114M（作者注：这是官方数据，实测在Vagrant环境下只有大约80M，比宣传的还要低），只有常见 Linux 服务器系统的一半略多 (约60%)。

       此外，CoreOS 使用经 Mac 系统 launchd 的启发而开发的 Systemd 作为默认系统启动和服务管理器 (CentOS 7 也使用 Systemd 取代了过去的 SysV 启动服务)。与 SysV 相比，Systemd 不但可以更好的追踪系统进程，而且也具备优秀的并行化处理能力，加之按需启动等特点，并结合 Docker 的快速启动能力，在 CoreOS 集群中大规模部署 Docker Containers 与使用其他操作系统相比在性能上的优势将更加明显。

1.2 ​​​​​​​版本升级 

       传统的服务器操作系统，包括大多数Linux发行版，每隔几年都会更换。在这期间，开发者会不断用安全补丁和更新完善这个系统，但是不会进行特别大的改动，最终这个操作系统以及其上的软件会慢慢僵化。

       CoreOS 的思想是成为一个随时可被更新的操作系统，其本身没有跨发布版本升级的概念，而是使用了类似 Arch Linux 的升级通道(Update Channel)和滚动更新的方式，在任何时候系统都能够直接升级成最新的发布版本。甚至在整个更新的过程中，应用程序的运行不会被打断。有了 CoreOS，基础架构会自动升级，就像无需用户操心的 Chrome 浏览器升级一样。

       CoreOS 有两个系统分区 (dual root partition 有些地方翻译为双启动分区，这里实际上应该是系统分区，包括 /bin /sbin /lib 等目录，这些目录都是只读的)。

       两个分区分别被设置成主动模式和被动模式并在系统运行期间各司其职。主动分区负责系统运行，被动分区负责系统升级。一旦新版本的操作系统被发布，一个完整的系统文件将被下载至被动分区，并在系统下一次重启时从新版本分区启动，原来的被动分区将切换为主动分区，而之前的主动分区则被切换为被动分区。这个个过程中，被更新的机器不需要从负载集群中移除。同时，为了保证其它应用程序不被打断，CoreOS 会通过 Linux cgroups 限制更新过程中的硬盘和网络I/O。

       与传统 Linux 服务器不同，CoreOS 的系统分区被设计成在系统运行期间保持只读状态，这样确保了 CoreOS 的安全性，也进一步体现了 CoreOS 不希望用户将应用软件直接安装在操作系统上的态度。同时，集群内高度一致的系统内核和外围应用版本，简化了由于版本问题带来的操作复杂性，使得操作系统自身的维护更加容易。

1.3 应用容器化

       在 CoreOS 中，所有应用程序都被装在一个个 Docker 容器中，这些容器就像一个个软件代码的集装箱，通过最简单的接口运行在操作系统之上。这意味着它们可以被很轻松的在操作系统和计算机之间转移，就像是在轮船和火车上搬运箱子一样，同时也意味着可以在不中断应用程序的情况下更新操作系统。

        Docker 在开发者将应用部署到云基础架构上时变得日益流行。通过容器化 (containerized) 的运算环境向应用程序提供运算资源，应用程序之间共享系统内核和资源，却互不干涉运行。单个容器的故障能够快速的重启修复，并且容器内的应用故障不会引起整个系统的崩溃。这个思想和浏览器的沙盒是如出一辙的。

1.4 CoreOS 的分布式系统服务

        云的问题，最主要是由集中式到分布式思考方式的转变，分布式服务、分布式部署、分布式管理、分布式数据存储… 而这些都是 CoreOS 带给服务器革命的一部分。

       为了从系统层面上解决这些分布式思维所面临的问题，CoreOS 团队提供了一些重要的工具帮助用户管理 CoreOS 集群以及部署 Docker 容器。

• Cloud-init

      在系统启动时，CoreOS 会读取一个平台定制的用户配置文件 (称为 cloud-config) 完成系统的初始化配置。通过配置中的信息，新启动 CoreOS 服务器将初始化必要的服务进程，并自动发现并指定集群的其他服务器交互信息，然后加入这个集群中。这种基于集群的“自发现”组织方式使得集群管理变得简单且高效。

      通常来说，cloud-config 配置文件至少应当包括服务器所属的集群通信地址，以及启动 etcd 和 fleet 所需服务的参数。用户可以根据需要，在配置中添加更多定制化的服务，使得节点启动后立即成为功能完备的集群成员投入运行。

• Etcd

      在CoreOS 集群中处于骨架地位的是 etcd。 etcd 是一个分布式 key/value 存储服务，CoreOS 集群中的程序和服务可以通过 etcd 共享信息或做服务发现 。etcd 基于非常著名的 raft 一致性算法：通过选举形式在服务器之中选举 Lead 来同步数据，并以此确保集群之内信息始终一致和可用。etcd 以默认的形式安装于每个 CoreOS 系统之中。

      在默认的配置下，etcd 使用系统中的两个端口：4001和7001，其中4001提供给外部应用程序以HTTP+Json的形式读写数据，而7001则用作在每个 etcd 之间进行数据同步。用户更可以通过配置 CA Cert让 etcd 以 HTTPS 的方式读写及同步数据，进一步确保数据信息的安全性。

• Fleet

       fleet 是一个通过 Systemd对CoreOS 集群中进行控制和管理的工具。fleet 与 Systemd 之间通过 D-Bus API 进行交互，每个 fleet agent 之间通过 etcd 服务来注册和同步数据。fleet 提供的功能非常丰富，包括查看集群中服务器的状态、启动或终止 Docker 容器、读取日志内容等。更为重要的是 fleet 可以确保集群中的服务一直处于可用状态。当出现某个通过 fleet 创建的服务在集群中不可用时，如由于某台主机因为硬件或网络故障从集群中脱离时，原本运行在这台服务器中的一系列服务将通过fleet 被重新分配到其他可用服务器中。虽然当前 fleet 还处于非常早期的状态，但是其管理 CoreOS 集群的能力是非常有效的，并且仍然有很大的扩展空间，目前已提供简单的 API 接口供用户集成。

二、CoreOS几个特点

• 与传统 Linux 服务器不同，CoreOS 的系统分区被设计成在系统运行期间保持只读状态，这样确保了 CoreOS 的安全性，也进一步体现了 CoreOS 不希望用户将应用软件直接安装在操作系统上的态度。同时，集群内高度一致的系统内核和外围应用版本，简化了由于版本问题带来的操作复杂性，使得操作系统自身的维护更加容易。
• CoreOS是一个采用了高度精简的系统内核及外围定制的操作系统。
• Red Hat Enterprise Linux CoreOS (RHCOS) 通过提供带有自动化远程升级功能的 Red Hat Enterprise Linux (RHEL) 的质量标准, 代表下一代单用途容器操作系统技术。
• 对于所有 OpenShift Container Platform 机器，仅支持将 RHCOS 作为 OpenShift Container Platform 4.11 的组件。RHCOS 是唯一受 OpenShift Container Platform control plane 或 master 机器支持的操作系统。虽然RHCOS是所有群集节点的默认操作系统，但也可以使用RHEL作为 worker 节点的操作系统 。

1.5 CoreOS 重启策略

• best-effort(默认):如果 etcd 运行正常则相当于 etcd-lock，否则相当于 reboot.
• etcd-lock:自动升级完成后自动重启，使用 locksmith 服务调度重启过程.
• reboot:自动升级完成后立即自动重启.
• off:自动升级完成后等待用户手工重启.

2.1 强化 RHCOS：

• 如果在安装程序置备的基础架构上安装集群，则 RHCOS 镜像会在安装过程中下载到目标平台中。适当的 Ignition 配置文件（控制 RHCOS 配置）也被下载并用于部署机器。
• 如果将集群安装到您自己管理的基础架构上，则必须遵循安装文档来获取 RHCOS 镜像，生成 Ignition 配置文件，并且使用 Ignition 配置文件来置备机器。

• Red Hat Enterprise Linux CoreOS (RHCOS) 通过提供带有自动化远程升级功能的 Red Hat Enterprise Linux (RHEL) 的质量标准来代表下一代单用途容器操作系统技术。
• 对于所有 OpenShift Container Platform 机器，仅支持将 RHCOS 作为 OpenShift Container Platform 4.11 的组件。
• RHCOS 是唯一受 OpenShift Container Platform control plane 或 master 机器支持的操作系统。
• 虽然 RHCOS 是所有集群机器的默认操作系统，但仍可以创建使用 RHEL 作为其操作系统的计算（compute）机器（也称为 worker ）。

OpenShift Container Platform 4.11 中有两个通用的部署 RHCOS 的方法：

•  如果在安装程序置备的基础架构上安装集群，则 RHCOS 镜像会在安装过程中下载到目标平台中。适当的 Ignition 配置文件（控制 RHCOS 配置）也被下载并用于部署机器。
• 如果将集群安装到您自己管理的基础架构上，则必须遵循安装文档来获取 RHCOS 镜像，生成 Ignition 配置文件，并且使用 Ignition 配置文件来置备机器。

2.2 RHCOS 主要功能

下表描述了 RHCOS 操作系统的主要功能：

1. 基础操作系统主要由RHEL组件组成，您将获得与在RHEL上实现的质量、安全性和控制措施。
2. RHCOS使用rpm-ostree系统进行事务性升级，更新是通过容器映像传递的，并且是OpenShift更新过程的一部分。部署后，将容器映像提取，提取并写入磁盘，然后修改引导加载程序以引导到新版本。
3. RHCOS使用Podman CLI执行诸如构建，复制和管理容器之类的任务，这将用podman CLI中找到的一组兼容的容器工具代替Docker CLI工具。
4. RHCOS合并了CRI-O容器引擎而不是Docker容器引擎，与提供更大功能集的容器引擎相比，CRI-O提供了与不同Kubernetes版本的特定兼容性，并且占地面积更小，攻击面更小。

• 基于 RHEL：底层操作系统主要由 RHEL 组件构成。支持 RHEL 的相同质量、安全性和控制措施也支持 RHCOS。例如，RHCOS 软件位于 RPM 软件包中，并且每个 RHCOS 系统都以 RHEL 内核以及由 systemd 初始化系统管理的一组服务启动。
• 控制的不可变性：尽管 RHCOS 包含 RHEL组件，但它的管理要比默认的 RHEL 安装更加严格。管理从 OpenShift Container Platform 集群远程执行。设置 RHCOS 机器时，您只能修改一些系统设置。这种受控的不变性使 OpenShift Container Platform 可以存储集群中 RHCOS 系统的最新状态，因而始终都能创建额外的机器并根据最新的 RHCOS 配置执行更新。
• CRI-O 容器运行时：尽管 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 中直接使用这些工具，但可以把它们用于调试目的。
• rpm-ostree 升级：RHCOS 具有使用rpm-ostree 系统进行事务升级的功能。更新是通过容器镜像交付的，并且是 OpenShift Container Platform 更新过程的一部分。部署之后，拉取、提取容器镜像并将其写入磁盘，然后修改启动加载程序以启动到新版本。机器将以滚动方式重启并进入更新，确保对集群容量的影响最小。
• Bootupd 固件和 bootloader 更新：Package manager 和混合系统（如如 rpm-ostree）不会更新固件或者 bootloader。通过 bootupd，RHCOS 用户现在可以访问跨系统发行、系统分析操作系统更新工具，该工具管理在现代架构中（如 x86_64、ppc64le 和 aarch64）运行的 UEFI 和旧 BIOS 引导模式中的固件和引导更新。
• 有关如何安装 bootupd 的详情，请参考 使用 bootupd 更新引导装载程序文档。
• 通过 Machine Config Operator 更新：在 OpenShift Container Platform 中，Machine Config Operator 处理操作系统升级。rpm-ostree 以原子单元形式提供升级，不像 yum 升级那样单独升级各个软件包。新的操作系统部署在升级过程中进行，并在下次重启时才会生效。如果升级出现问题，则进行一次回滚并重启就能使系统返回到以前的状态。OpenShift Container Platform 中的 RHCOS 升级是在集群更新期间执行的。

对于 RHCOS 系统，rpm-ostree 文件系统的布局具有以下特征：

• /usr 是操作系统二进制文件和库的存储位置，并且是只读的。我们不支持更改此设置。
• /etc、/boot 和 /var 在系统上是可写的，但只能由 Machine Config Operator 更改。
• /var/lib/containers 是用于存储容器镜像的图形存储位置。

2.3 选择如何配置 RHCOS

RHCOS 的设计思想是，在需要最小用户配置的情况下在 OpenShift Container Platform 集群中进行部署。在它的最基本的形式中包括：

• 从置备的基础架构（如 AWS）开始，或者自行置备基础架构。
• 在运行 openshift-install 时，在 install-config.yaml 文件中提供少量信息，如凭证和集群名称。

由于 OpenShift Container Platform 中的 RHCOS 系统被设计为通过 OpenShift Container Platform 集群来进行全面管理，因此不建议直接修改 RHCOS 机器。为了调试，您可以对 RHCOS 机器集群进行有限的直接访问，但您不应该直接配置 RHCOS 系统。相反，如果您需要在 OpenShift Container Platform 节点上添加或更改功能，请考虑采用以下方式进行更改：

• Kubernetes 工作负载对象，如 DaemonSet 和 Deployment：如果要将服务或其他用户级别功能添加到集群中，请考虑将它们添加为 Kubernetes 工作负载对象。为了减少在后续的升级中破坏集群的风险，在特定节点配置之外应用这些功能是最佳方法。
• 自定义配置任务：如果可能，在不对集群节点进行任何自定义配置的情况下启动集群，并在集群启动后再进行必要的节点更改。这些更改可以更轻松地管理，且不太可能破坏以后的更新。创建机器配置或修改 Operator 自定义资源是进行这些自定义的方法。
• 自定义配置：对于集群首次启动时必须执行的自定义配置，可以使用以下方法修改集群以便更改可在首次引导时就生效。自定义配置可通过运行 openshift-install 期间的 Ignition 配置和清单文件实现，也可以在由用户置备的 ISO 安装过程中添加引导选项实现。

定制示例：

• 内核参数：如果在集群首次引导时需要特定的内核功能或调整。
• 磁盘加密：如果您的安全规则需要对节点上的根文件系统加密，比如 FIPS 支持。
• 内核模块：如果 Linux 内核没有默认为某个特定的硬件设备（如网卡或视频卡）提供可用的模块。
• Chronyd：如果要为节点提供特定的时钟设置，如时间服务器的位置。

为 openshift-install 提供参数，使其包含额外的对象，如 MachineConfig。这些创建机器配置的步骤可在集群启动后传递给 Machine Config Operator。

注意

• 安装程序生成的 Ignition 配置文件包含在 24 小时后过期的证书，然后在过期时进行续订。
• 如果在更新证书前关闭集群，且集群在 24 小时后重启，集群会自动恢复过期的证书。一个例外是，您必须手动批准待处理的 node-bootstrapper 证书签名请求(CSR)来恢复 kubelet 证书。如需更多信息，请参阅从过期的 control plane 证书 中恢复的文档。
• 建议您在 Ignition 配置文件生成后的 12 小时内使用它们，因为 24 小时的证书会在集群安装后的 16 小时到 22 小时间进行轮转。通过在 12 小时内使用 Ignition 配置文件，您可以避免在安装过程中因为执行了证书更新而导致安装失败的问题。

2.4 选择如何部署 RHCOS

OpenShift Container Platform 的 RHCOS 安装的区别取决于，您是在安装程序置备的基础架构上部署，还是在由用置备的基础架构上部署：

• 安装程序置备：有些云环境提供预配置的基础架构，以便您使用最小配置来启动 OpenShift Container Platform 集群。对于这些类型的安装，您可以提供 Ignition 配置来在每个节点上放置内容，以便在集群首次启动时可用。
• 用户置备：如果您置备自己的基础架构，则具有更大的灵活性来向 RHCOS 节点中添加内容。例如：引导 RHCOS ISO 安装程序时您可以添加内核参数来安装每个系统。但是，在多数情况下，如果操作系统本身需要配置，最好通过 Ignition 配置来提供那些配置。

Ignition 工具仅在首次设置 RHCOS 系统时运行。之后，可以使用机器配置来提供 Ignition 配置。

2.5 关于 Ignition

• Ignition 是 RHCOS 在初始配置期间用于操作磁盘的实用程序。它可完成常见的磁盘任务，如分区磁盘、格式化分区、写入文件和配置用户等。首次启动时，Ignition 从安装介质或您指定的位置读取其配置，并将配置应用到机器。
• 无论您要安装集群还是向其中添加机器，Ignition 始终都执行 OpenShift Container Platform 集群机器的初始配置。实际的系统设置大多都在每台机器上进行。对于每台机器，Ignition 都会获取 RHCOS 镜像并启动 RHCOS 内核。内核命令行上的选项标识部署的类型，以及启用了 Ignition 的初始 RAM 磁盘 (initramfs) 的位置。

2.5.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 可以找到它并正确配置系统。

2.5.2. Ignition 操作序列

OpenShift Container Platform 集群中 RHCOS 机器的 Ignition 过程包括以下步骤：

• 机器获取其 Ignition 配置文件。control plane 机器从 bootstrap 机器获取 Ignition 配置文件，worker 机器从 control plane 机器获取 Ignition 配置文件。
• Ignition 在机器上创建磁盘分区、文件系统、目录和链接。它支持 RAID 阵列，但不支持 LVM 卷。
• Ignition 将持久文件系统的根目录挂载到 initramfs 中的 /sysroot 目录，然后开始在 /sysroot 中工作。
• Ignition 配置所有定义的文件系统，并将它们设置为在运行时进行相应地挂载。
• Ignition 运行 systemd 临时文件，将必要的文件填充到 /var 目录。
• Ignition 运行 Ignition 配置文件，以设置用户、systemd 单元文件和其他配置文件。
• Ignition 卸载 initramfs 中挂载的持久系统中的所有组件。
• Ignition 启动新机器的 init 进程，该过程在系统引导期间运行的机器上启动所有其他服务。

在此过程结束时，计算机已准备好加入群集，不需要重启。