Red Hat Enterprise Linux CoreOS | 架构 | OpenShift Container Platform 4.17

关于 RHCOS
查看 Ignition 配置文件
安装后更改 Ignition 配置

关于 RHCOS

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

RHCOS 仅作为 OpenShift Container Platform 4.17 中所有 OpenShift Container Platform 机器的一个组件受支持。RHCOS 是 OpenShift Container Platform 控制平面或主机的唯一受支持操作系统。虽然 RHCOS 是所有集群机器的默认操作系统，但您可以创建使用 RHEL 作为其操作系统的计算机器（也称为工作机器）。RHCOS 在 OpenShift Container Platform 4.17 中有两种主要的部署方式。

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

RHCOS 主要功能

以下列表描述了 RHCOS 操作系统的主要功能。

基于 RHEL：底层操作系统主要由 RHEL 组件组成。支持 RHEL 的相同质量、安全性和控制措施也支持 RHCOS。例如，RHCOS 软件位于 RPM 包中，每个 RHCOS 系统都以 RHEL 内核和由 systemd init 系统管理的一组服务启动。
受控不变性：虽然包含 RHEL 组件，但 RHCOS 的设计比默认 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 固件和引导加载程序更新程序：包管理器和混合系统（如 rpm-ostree）不会更新固件或引导加载程序。借助 bootupd，RHCOS 用户可以访问一个跨发行版、系统无关的更新工具，该工具在 UEFI 和旧版 BIOS 引导模式下管理现代架构（如 x86_64、ppc64le 和 aarch64）上的固件和引导更新。

有关如何安装 bootupd 的信息，请参阅使用 bootupd 更新引导加载程序的文档。
通过 Machine Config Operator 更新：在 OpenShift Container Platform 中，Machine Config Operator 处理操作系统升级。与使用 yum 升级更新单个软件包不同，rpm-ostree 将操作系统的升级作为原子单元交付。新的操作系统部署在升级期间分阶段进行，并在下次重新引导时生效。如果升级出现问题，只需一次回滚和重新引导即可将系统恢复到以前的状态。OpenShift Container Platform 中的 RHCOS 升级在集群更新期间执行。

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

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

选择如何配置 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 证书。有关更多信息，请参阅从过期的控制平面证书中恢复的文档。
建议您在生成 Ignition 配置文件后 12 小时内使用它们，因为 24 小时证书会在集群安装后 16 到 22 小时内轮换。通过在 12 小时内使用 Ignition 配置文件，如果证书更新在安装期间运行，您可以避免安装失败。

选择如何部署 RHCOS

OpenShift Container Platform 的 RHCOS 安装差异取决于您是在安装程序预配的基础设施上部署，还是在用户预配的基础设施上部署。

安装程序预配：某些云环境提供预配置的基础设施，允许您以最少的配置启动 OpenShift Container Platform 集群。对于这些类型的安装，您可以提供 Ignition 配置文件，将内容放置在每个节点上，以便在集群首次启动时即可使用。
用户预配：如果您自己预配基础设施，则在如何向 RHCOS 节点添加内容方面拥有更大的灵活性。例如，您可以在引导 RHCOS ISO 安装程序时添加内核参数来安装每个系统。但是，在大多数需要对操作系统本身进行配置的情况下，最好通过 Ignition 配置文件提供该配置。

Ignition 功能仅在 RHCOS 系统首次设置时运行。之后，可以使用机器配置提供 Ignition 配置文件。

关于 Ignition

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

无论您是安装集群还是向集群添加机器，Ignition 始终执行 OpenShift Container Platform 集群机器的初始配置。大部分实际的系统设置都发生在每台机器本身。对于每台机器，Ignition 获取 RHCOS 镜像并引导 RHCOS 内核。内核命令行中的选项标识部署类型和启用 Ignition 的初始 RAM 磁盘 (initramfs) 的位置。

Ignition 的工作原理

要使用 Ignition 创建机器，您需要 Ignition 配置文件。OpenShift Container Platform 安装程序会创建部署集群所需的 Ignition 配置文件。这些文件基于您直接或通过 install-config.yaml 文件提供给安装程序的信息。

Ignition 配置机器的方式类似于 cloud-init 或 Linux Anaconda kickstart 等工具配置系统的方式，但有一些重要的区别。

Ignition 从与您安装到的系统分开的初始 RAM 磁盘运行。因此，Ignition 可以重新分区磁盘、设置文件系统并对机器的永久文件系统执行其他更改。相反，cloud-init 在系统启动时作为机器 init 系统的一部分运行，因此难以轻松地对磁盘分区等基础内容进行更改。使用 cloud-init，也很难在节点引导过程中重新配置引导过程。
Ignition 用于初始化系统，而不是更改现有系统。机器初始化并且内核从已安装的系统运行后，OpenShift Container Platform 集群中的机器配置操作员将完成所有未来的机器配置。
Ignition 实现的是声明式配置，而不是完成一组已定义的操作。在新的机器启动之前，它会检查所有分区、文件、服务和其他项目是否已就位。然后它进行更改，例如将文件复制到磁盘，这些文件对于新机器满足指定的配置是必要的。
Ignition 完成机器配置后，内核继续运行，但会丢弃初始 RAM 磁盘并转向磁盘上的已安装系统。所有新的系统服务和其他功能都无需系统重新引导即可启动。
由于 Ignition 确认所有新机器都满足声明的配置，因此您不会拥有部分配置的机器。如果机器设置失败，则初始化过程不会完成，并且 Ignition 不会启动新机器。您的集群将永远不会包含部分配置的机器。如果 Ignition 无法完成，则不会将机器添加到集群。您必须添加一台新机器。此行为避免了在依赖项失败的日期之前不知道失败的配置任务的结果时调试机器的难题。
如果 Ignition 配置存在问题导致机器设置失败，Ignition 将不会尝试使用相同的配置来设置另一台机器。例如，故障可能是由由父配置和子配置组成的 Ignition 配置导致的，这两个配置都想要创建相同的文件。在这种情况下，故障将阻止该 Ignition 配置再次用于设置其他机器，直到问题解决。
如果您有多个 Ignition 配置文件，则会获得该配置文件集的并集。由于 Ignition 是声明式的，因此配置文件之间的冲突可能导致 Ignition 无法设置机器。这些文件中的信息顺序无关紧要。Ignition 将以最有意义的方式对每个设置进行排序和实现。例如，如果一个文件需要一个几层深的目录，如果另一个文件需要该路径上的目录，则先创建后面的文件。Ignition 按深度对所有文件、目录和链接进行排序和创建。
由于 Ignition 可以从完全空的硬盘启动，因此它可以执行 cloud-init 无法执行的操作：使用 PXE 引导等功能从头开始设置裸机系统。在裸机情况下，Ignition 配置被注入到引导分区中，以便 Ignition 可以找到它并正确配置系统。

Ignition 序列

OpenShift Container Platform 集群中 RHCOS 机器 Ignition 过程涉及以下步骤：

机器获取其 Ignition 配置文件。控制平面机器从引导机器获取其 Ignition 配置文件，而工作机器从控制平面机器获取 Ignition 配置文件。
Ignition 在机器上创建磁盘分区、文件系统、目录和链接。它支持 RAID 阵列，但不支持 LVM 卷。
Ignition 将永久文件系统的根目录安装到 initramfs 中的 /sysroot 目录，并在该 /sysroot 目录中开始工作。
Ignition 配置所有已定义的文件系统，并将其设置为在运行时适当挂载。
Ignition 运行 systemd 临时文件以填充 /var 目录中所需的文件。
Ignition 运行 Ignition 配置文件以设置用户、systemd 单元文件和其他配置文件。
Ignition 卸载在 initramfs 中挂载的永久系统中的所有组件。
Ignition 启动新机器的 init 进程，该进程依次启动机器在系统启动期间运行的所有其他服务。

在此过程结束时，机器已准备好加入集群，无需重新引导。

查看 Ignition 配置文件

要查看用于部署引导机器的 Ignition 配置文件，请运行以下命令：

$ openshift-install create ignition-configs --dir $HOME/testconfig

回答几个问题后，您输入的目录中将出现bootstrap.ign、master.ign和worker.ign文件。

要查看bootstrap.ign文件的内容，请将其通过jq过滤器传递。以下是该文件中的一个片段：

$ cat $HOME/testconfig/bootstrap.ign | jq
{
  "ignition": {
    "version": "3.2.0"
  },
  "passwd": {
    "users": [
      {
        "name": "core",
        "sshAuthorizedKeys": [
          "ssh-rsa AAAAB3NzaC1yc...."
        ]
      }
    ]
  },
  "storage": {
    "files": [
      {
        "overwrite": false,
        "path": "/etc/motd",
        "user": {
          "name": "root"
        },
        "append": [
          {
            "source": "data:text/plain;charset=utf-8;base64,VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2VzIGFyZSByZWxlYXNlLWltYWdlLnNlcnZpY2UgZm9sbG93ZWQgYnkgYm9vdGt1YmUuc2VydmljZS4gVG8gd2F0Y2ggdGhlaXIgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IHJlbGVhc2UtaW1hZ2Uuc2VydmljZSAtdSBib290a3ViZS5zZXJ2aWNlCg=="
          }
        ],
        "mode": 420
      },
...

要解码bootstrap.ign文件中列出的文件的内容，请将表示该文件内容的 base64 编码数据字符串传递给base64 -d命令。以下是如何使用从上面显示的输出中添加到引导机器的/etc/motd文件内容的示例：

$ echo VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2VzIGFyZSByZWxlYXNlLWltYWdlLnNlcnZpY2UgZm9sbG93ZWQgYnkgYm9vdGt1YmUuc2VydmljZS4gVG8gd2F0Y2ggdGhlaXIgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IHJlbGVhc2UtaW1hZ2Uuc2VydmljZSAtdSBib290a3ViZS5zZXJ2aWNlCg== | base64 --decode

示例输出

This is the bootstrap node; it will be destroyed when the master is fully up.

The primary services are release-image.service followed by bootkube.service. To watch their status, run e.g.

  journalctl -b -f -u release-image.service -u bootkube.service

对master.ign和worker.ign文件重复这些命令，以查看每种机器类型的 Ignition 配置文件的来源。对于worker.ign，您应该会看到如下所示的行，说明它如何从引导机器获取其 Ignition 配置：

"source": "https://api.myign.develcluster.example.com:22623/config/worker",

以下是您可以从bootstrap.ign文件中了解的一些信息：

格式：文件的格式在Ignition 配置规范中定义。MCO 稍后将使用相同格式的文件将更改合并到机器的配置中。
内容：由于引导机器为其他机器提供 Ignition 配置，因此引导机器的配置以及主控机器和工作机器的 Ignition 配置信息都存储在bootstrap.ign中。
大小：该文件超过 1300 行，包含各种资源的路径。
实际上，将复制到机器的每个文件的内容都编码为数据 URL，这使得内容难以阅读。（使用前面显示的jq和base64命令可以使内容更易于阅读。）
配置：Ignition 配置文件的不同部分通常用于包含仅放置到机器文件系统中的文件，而不是修改现有文件的命令。例如，与其包含配置该服务的 NFS 部分，不如添加 NFS 配置文件，然后在系统启动时由 init 进程启动该文件。
用户：将创建一个名为core的用户，并将您的 SSH 密钥分配给该用户。这允许您使用该用户名和您的凭据登录到集群。
存储：存储部分标识添加到每台机器的文件。一些值得注意的文件包括/root/.docker/config.json（它提供集群从容器镜像注册表提取所需的凭据）和/opt/openshift/manifests中的一堆清单文件，这些文件用于配置您的集群。
systemd：systemd部分包含用于创建systemd单元文件的内容。这些文件用于在启动时启动服务，以及管理正在运行的系统上的这些服务。
基元：Ignition 还公开了其他工具可以构建其上的低级基元。

安装后更改 Ignition 配置

机器配置池管理节点集群及其对应的机器配置。机器配置包含集群的配置信息。要列出所有已知的机器配置池：

$ oc get machineconfigpools

示例输出

NAME   CONFIG                                  UPDATED UPDATING DEGRADED
master master-1638c1aea398413bb918e76632f20799 False   False    False
worker worker-2feef4f8288936489a5a832ca8efe953 False   False    False

要列出所有机器配置：

$ oc get machineconfig

示例输出

NAME                                      GENERATEDBYCONTROLLER   IGNITIONVERSION   CREATED   OSIMAGEURL

00-master                                 4.0.0-0.150.0.0-dirty   3.2.0             16m
00-master-ssh                             4.0.0-0.150.0.0-dirty                     16m
00-worker                                 4.0.0-0.150.0.0-dirty   3.2.0             16m
00-worker-ssh                             4.0.0-0.150.0.0-dirty                     16m
01-master-kubelet                         4.0.0-0.150.0.0-dirty   3.2.0             16m
01-worker-kubelet                         4.0.0-0.150.0.0-dirty   3.2.0             16m
master-1638c1aea398413bb918e76632f20799   4.0.0-0.150.0.0-dirty   3.2.0             16m
worker-2feef4f8288936489a5a832ca8efe953   4.0.0-0.150.0.0-dirty   3.2.0             16m

在应用这些机器配置方面，机器配置操作员的运行方式与 Ignition 略有不同。机器配置按顺序读取（从 00* 到 99*）。机器配置中的标签标识每个节点的类型（主控或工作节点）。如果同一文件出现在多个机器配置文件中，则最后一个文件有效。例如，出现在 99* 文件中的任何文件都将替换出现在 00* 文件中的相同文件。输入的MachineConfig对象将合并到“渲染的”MachineConfig对象中，该对象将由操作员用作目标，也是您可以在机器配置池中看到的值。

要查看正在从机器配置管理哪些文件，请在特定的MachineConfig对象中查找“Path:” 。例如：

$ oc describe machineconfigs 01-worker-container-runtime | grep Path:

示例输出

            Path:            /etc/containers/registries.conf
            Path:            /etc/containers/storage.conf
            Path:            /etc/crio/crio.conf

请务必为机器配置文件指定一个较后的名称（例如 10-worker-container-runtime）。请记住，每个文件的内容都是 URL 样式的数据。然后将新的机器配置应用于集群。