支持控制台（Console）开发人员开始试用联系人

第 9 章 Red Hat Enterprise Linux CoreOS (RHCOS)

9.1. 关于 RHCOS

Red Hat Enterprise Linux CoreOS (RHCOS) 通过提供带有自动化远程升级功能的 Red Hat Enterprise Linux (RHEL) 的质量标准来代表下一代单用途容器操作系统技术。

对于所有 OpenShift Container Platform 机器，仅支持将 RHCOS 作为 OpenShift Container Platform 4.13 的组件。RHCOS 是唯一受 OpenShift Container Platform control plane 或 master 机器支持的操作系统。虽然 RHCOS 是所有集群机器的默认操作系统，但您仍可以创建使用 RHEL 作为其操作系统的计算（compute）机器（也称为 worker ）。OpenShift Container Platform 4.13 中有两个通用的部署 RHCOS 的方法：

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

9.1.1. RHCOS 主要功能

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

  • 基于 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 集群中唯一可用的引擎。

    CRI-O 可以使用 runC 或 crun 容器运行时来启动和管理容器。有关如何启用 crun 的详情，请参考创建 ContainerRuntimeConfig CR 的文档。

  • 容器工具程序组：对于诸如构建、复制和以其他方式管理容器的任务，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 是用于存储容器镜像的图形存储位置。

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

以下是您可以在第 1 天进行定制的示例：

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

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

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

9.1.3. 选择如何部署 RHCOS

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

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

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

9.1.4. 关于 Ignition

Ignition 是 RHCOS 在初始配置期间用于操作磁盘的实用程序。它可完成常见的磁盘任务，如分区磁盘、格式化分区、写入文件和配置用户等。首次启动时，Ignition 从安装介质或您指定的位置读取其配置，并将配置应用到机器。

无论您要安装集群还是向其中添加机器，Ignition 始终都执行 OpenShift Container Platform 集群机器的初始配置。实际的系统设置大多都在每台机器上进行。对于每台机器，Ignition 都会获取 RHCOS 镜像并启动 RHCOS 内核。内核命令行上的选项标识部署的类型，以及启用了 Ignition 的初始 RAM 磁盘 (initramfs) 的位置。

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

9.1.4.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 进程，该过程在系统引导期间运行的机器上启动所有其他服务。

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.