关于RHCOS
Red Hat Enterprise Linux CoreOS (RHCOS)代表了下一代的单用途容器操作系统技术。RHCOS是由创建Red Hat Enterprise Linux Atomic Host和CoreOS Container Linux的开发团队创建的，它将Red Hat Enterprise Linux (RHEL)的质量标准与Container Linux的自动化、远程升级特性结合在一起。
RHCOS仅作为OpenShift容器平台4.3的一个组件被支持，适用于所有的OpenShift容器平台机器。RHCOS是OpenShift容器平台控制平面或主机的唯一支持的操作系统。虽然RHCOS是所有集群机器的默认操作系统，但是您可以创建使用RHEL作为其操作系统的 compute 节点(也称为 worker 节点)。RHCOS在OpenShift容器平台上的部署方式有两种:
如果您将集群安装在集群提供的基础设施上（IPI），安装过程中将下载RHCOS映像到目标平台，并使用控制RHCOS配置的适当点火配置文件来部署机器。
如果您在自己管理的基础设施上安装集群（UPI），则必须按照安装文档获取RHCOS映像，生成点火配置文件，并使用点火配置文件来配置您的机器。
RHCOS的关键特性
基于RHEL: 底层操作系统主要由RHEL组件组成。支持RHEL的同样质量、安全和控制措施也支持RHCOS。例如，RHCOS软件在RPM包中，每个RHCOS系统都启动一个RHEL内核和一组由systemd init系统管理的服务。
受控不变性: 虽然它包含RHEL组件，但RHCOS的设计比默认的RHEL安装管理更严格。管理是在OpenShift容器平台集群中远程执行的。当您设置您的RHCOS机器时，您只能修改一些系统设置。这种受控制的不变性允许OpenShift容器平台在集群中存储RHCOS系统的最新状态，因此它总是能够创建额外的机器，并根据最新的RHCOS配置执行更新。
crio容器运行时:虽然RHCOS包含运行Docker所需的OCI和libcontainer格式容器的特性，但它合并了crio容器引擎，而不是Docker容器引擎。通过专注于Kubernetes平台所需的特性(如OpenShift容器平台)，crio可以提供与Kubernetes不同版本的特定兼容性。与提供更大特性集的容器引擎相比，crio还提供了更小的足迹和更少的攻击面。目前，crio仅作为OpenShift容器平台集群中的容器引擎可用。
容器工具集:对于诸如构建、复制和以其他方式管理容器的任务，RHCOS使用一组兼容的容器工具替换Docker CLI工具。podman CLI工具支持许多容器运行时特性，比如运行、启动、停止、列出和删除容器和容器映像。skopeo CLI工具可以复制、验证和签署图像。您可以使用crictl CLI工具来处理来自crio容器引擎的容器和吊舱。虽然不鼓励在RHCOS中直接使用这些工具，但是可以将它们用于调试目的。
rpm-ostree升级:RHCOS提供使用rpm-ostree系统的事务升级。更新是通过容器映像交付的，并且是OpenShift容器平台更新过程的一部分。部署后，将提取、提取容器映像并将其写入磁盘，然后修改引导装载程序以引导到新版本。机器将以滚动的方式重新启动更新，以确保集群容量受到的影响最小。
通过MachineConfigOperator更新:在OpenShift容器平台中，Machine Config Operator 处理操作系统升级。与通过yum升级来升级单个包不同，rpm-ostree将操作系统的升级作为一个原子单元来交付。新的操作系统部署在升级期间进行，并在下一次重新启动时生效。如果升级出现问题，一次回滚和重新启动将使系统恢复到以前的状态。OpenShift容器平台中的RHCOS升级是在集群更新期间执行的。
对于RHCOS系统，rpm-ostree文件系统的布局具有以下特点:
/usr是存储操作系统二进制文件和库的只读位置。我们不支持改变这一点。
/etc、/boot、/var在系统上是可写的，但只能由机器配置操作符修改。
/var/lib/containers是用于存储容器映像的图形存储位置。
选择如何配置RHCOS_1
RHCOS被设计成部署在OpenShift容器平台集群上，只需要最少的用户配置。其最基本的形式包括:
从提供的基础设施(如AWS上的基础设施)开始，或者自己提供基础设施。
在安装配置中提供一些信息，如凭据和集群名。运行openshift-install时的yaml文件。
因为OpenShift容器平台中的RHCOS系统被设计为在此之后完全由OpenShift容器平台集群管理，所以不鼓励直接更改RHCOS机器。虽然可以出于调试目的对RHCOS机器集群进行有限的直接访问，但是不应该直接配置RHCOS系统。相反，如果您需要在您的OpenShift容器平台节点上添加或更改特性，请考虑通过以下方式进行更改:
Kubernetes工作负载对象(DaemonSets, Deployments等):如果需要向集群添加服务或其他用户级特性，可以考虑将它们添加为Kubernetes工作负载对象。将这些特性保留在特定节点配置之外是降低在后续升级中破坏集群的风险的最佳方法。
Day-2 customizations:如果可能，在不对集群节点进行任何自定义的情况下启动集群，并在集群启动后对节点进行必要的更改。这些更改在以后更容易跟踪，而且不太可能破坏更新。创建MachineConfigs或修改操作员自定义资源是实现这些自定义的方法。
Day-1 customizations:对于在集群首次出现时必须实现的自定义，可以通过一些方法修改集群，以便在第一次引导时实现更改。Day-1 customizations 可以通过在openshift-install期间激活配置和清单文件，或者在用户提供的ISO安装期间添加引导选项来完成。
下面是一些你可以在 day-1 进行的定制的例子:
内核参数:当集群第一次启动时，节点上是否需要特定的内核特性或调优。
磁盘加密:如果您的安全需要对节点上的根文件系统进行加密，例如使用FIPS支持。
内核模块:如果特定的硬件设备，例如网卡或显卡，在Linux内核中默认没有可用的模块。
Chronyd:如果你想为你的节点提供特定的时钟设置，比如时间服务器的位置。
为了完成这些任务，您可以扩展openshift-install过程，以包括额外的对象，如MachineConfigs。那些导致创建MachineConfigs的过程可以在集群启动后传递给Machine Config Operator。
安装程序生成的Ignition config文件包含24小时后过期的证书。您必须完成您的集群安装，并保持集群在非降级状态下运行24小时，以确保第一个证书循环已经完成。
选择如何配置RHCOS_2
针对OpenShift容器平台的RHCOS部署之间的差异取决于您是部署在安装程序提供的基础设施上，还是部署在用户提供的基础设施上:
Installer provisioned: 一些云环境提供预配置的基础设施，允许您以最少的配置打开OpenShift容器平台集群。对于这些类型的部署，您可以提供在每个节点上放置内容的Ignition配置，以便在集群第一次启动时它就在那里。
User provisioned: 如果您准备自己的基础设施，那么在如何向RHCOS节点添加内容方面有更大的灵活性。例如，可以在引导RHCOS ISO安装程序安装每个系统时添加内核参数。但是，在操作系统本身需要配置的大多数情况下，最好通过Ignition配置来提供配置。
Ignition只有在首次安装RHCOS系统时才能运行。之后，可以使用MachineConfigs提供Ignition配置。
关于Ignition
Ignition是在初始配置期间被RHCOS用来操作磁盘的实用工具。它完成常见的磁盘任务，包括分区磁盘、格式化分区、编写文件和配置用户。在第一次启动时，Ignition从安装介质或您指定的位置读取其配置，并将配置应用到机器上。
无论您是安装集群还是向集群中添加机器，Ignition总是执行OpenShift容器平台集群机器的初始配置。大多数实际的系统设置是在每台机器上进行的。对于每台机器，Ignition将获取RHCOS镜像并启动RHCOS内核。在内核命令行上的选项，识别部署类型和启用了启动的初始Ram磁盘(initramfs)的位置。
Ignition如何工作的
要使用Ignition创建机器，您需要Ignition配置文件。OpenShift容器平台安装程序创建了部署集群所需的Ignition配置文件。这些文件基于您直接或通过安装配置提供信息给install-config.yaml 文件。
Ignition配置机器的方式与cloud-init或Linux Anaconda kickstart等工具配置系统的方式类似，但有一些重要的区别:
Ignition从一个初始RAM磁盘运行，它与您安装到的系统是分离的。因此，Ignition可以重新分区磁盘，设置文件系统，并对机器的永久文件系统执行其他更改。相比之下，当系统启动时，cloud-init作为机器init系统的一部分运行，因此对磁盘分区之类的东西进行基本更改就不那么容易了。使用cloud-init，当您处于节点引导过程的中间时，也很难重新配置引导过程。
Ignition意味着初始化系统，而不是改变现有的系统。在机器初始化并从安装的系统运行内核之后，来自OpenShift容器平台集群的Machine Config Operator完成所有未来的机器配置。
Ignition实现了一个声明性配置，而不是完成一组已定义的动作。它在新机器启动之前检查所有分区、文件、服务和其他项是否就绪。然后进行更改，比如将新机器所需的文件复制到磁盘以满足指定的配置。
在Ignition完成对机器的配置之后，内核将继续运行，但会丢弃初始RAM磁盘并转到磁盘上安装的系统。所有新的系统服务和其他功能都无需重新启动即可启动。
因为Ignition确认所有新机器都符合声明的配置，所以不能有部分配置的机器。如果机器的安装失败，初始化过程就没有完成，Ignition也没有启动新机器。您的集群将永远不会包含部分配置的机器。如果Ignition不能完成，机器不添加到集群。你必须增加一台新机器。这种行为避免了调试一台机器的困难情况，因为失败的配置任务的结果直到依赖于它的某些东西在以后失败时才会被知道。
如果Ignition配置有问题，导致机器的设置失败，Ignition将不会尝试使用相同的配置来设置另一台机器。例如，由父配置和子配置组成的Ignition配置可能会导致失败，它们都希望创建相同的文件。这种情况下的失败将阻止再次使用Ignition配置来设置其他机器，直到问题得到解决。
如果您有多个Ignition配置文件，您将得到该配置集的并集。由于Ignition是声明性的，配置之间的冲突可能导致Ignition无法设置机器。这些文件中信息的顺序无关紧要。Ignition将排序和实现的方式，每一个设置，使最有意义。例如，如果一个文件需要一个层次较深的目录，如果另一个文件需要一个沿该路径的目录，则先创建后面的文件。Ignition排序和创建的所有文件，目录，和链接的深度。
因为Ignition可以从一个完全空的硬盘开始，它可以做一些cloud-init做不到的事情:从头开始在裸金属上建立系统(使用PXE启动等特性)。在裸金属的情况下，点火配置被注入到启动分区，这样Ignition可以找到它，并正确配置系统。
Ignition启动顺序
在OpenShift容器平台集群中，RHCOS机器的Ignition过程包括以下几个步骤:
机器获得它的Ignition配置文件。master从bootstrap获得它们的点火配置文件，而worker从master获得点火配置文件。
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": \\{
"config": \\{},
"storage": \\{
"files": [
\\{
"filesystem": "root",
"path": "/etc/motd",
"user": \\{
"name": "root"
},
"append": true,
"contents": \\{
"source": "data:text/plain;charset=utf-8;base64,VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2UgaXMgImJvb3RrdWJlLnNlcnZpY2UiLiBUbyB3YXRjaCBpdHMgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IGJvb3RrdWJlLnNlcnZpY2UK",
解码 bootstrap.ign文件内容。将表示该文件内容的base64编码的数据字符串通过管道传输到base64 -d命令。下面是一个例子，使用/etc/motd文件的内容从上面的输出添加到引导机:
$ echo VGhpcyBpcyB0aGUgYm9vdHN0cmFwIG5vZGU7IGl0IHdpbGwgYmUgZGVzdHJveWVkIHdoZW4gdGhlIG1hc3RlciBpcyBmdWxseSB1cC4KClRoZSBwcmltYXJ5IHNlcnZpY2UgaXMgImJvb3RrdWJlLnNlcnZpY2UiLiBUbyB3YXRjaCBpdHMgc3RhdHVzLCBydW4gZS5nLgoKICBqb3VybmFsY3RsIC1iIC1mIC11IGJvb3RrdWJlLnNlcnZpY2UK | base64 -d
This is the bootstrap machine; it will be destroyed when the master is fully up.
The primary service is "bootkube.service". To watch its status, run, e.g.:
journalctl -b -f -u bootkube.service
在master.ign 和 worker.ign 文件上重复这些命令，查看每种机器类型的Ignition配置文件的来源。对于worker.ign，您应该看到类似下面这样的一行。确定它如何从引导机获得Ignition配置:
"source": "https://api.myign.develcluster.example.com:22623/config/worker",
下面是一些你可以从bootstrap.ign文件学到:
- 格式:文件的格式在Ignition config spec中定义。MCO稍后将使用相同格式的文件将更改合并到机器的配置中。
内容:由于bootstrap机服务于其他机器的Ignition配置，所以master 和 worker 的Ignition配置信息都存储在bootstrap中。
文件大小:文件长度超过1300行，包含各种类型资源的路径。
将被复制到机器上的每个文件的内容实际上都被编码到url格式的数据中，这使得内容读起来有点痛苦。(使用前面显示的jq和base64命令使内容更具可读性。)
配置:Ignition配置文件的不同部分通常意味着包含刚刚放入机器文件系统中的文件，而不是修改现有文件的命令。例如，您只需添加一个NFS配置文件，而不是在NFS上配置该服务，然后在系统启动时由init进程启动该文件。
用户:将创建一个名为core的用户，并将您的ssh密钥分配给该用户。这允许您使用该用户名和您的凭证登录到集群。
存储:存储部分标识添加到每台机器的文件。一些值得注意的文件包括/root/.docker/config.json(它提供了您的集群需要从容器映像注册中心获取的凭证)和/opt/openshift/manifest中用于配置您的集群的一堆清单文件。
systemd: systemd部分包含用于创建systemd单元文件的内容。这些文件用于在启动时启动服务，以及在运行的系统上管理这些服务。
原语:Ignition还暴露了其他工具可以构建的低级原语。
安装后更换Ignition配置
Machine Config Pools管理节点集群及其相应的Machine Configs。Machine Configs包含集群的配置信息。列出所有已知的Machine Config Pools：
$ oc get machineconfigpools
NAME CONFIG UPDATED UPDATING DEGRADED
master master-1638c1aea398413bb918e76632f20799 False False False
worker worker-2feef4f8288936489a5a832ca8efe953 False False False
列出所有的Machine Config:
$ oc get machineconfig
NAME GENERATEDBYCONTROLLER IGNITIONVERSION CREATED OSIMAGEURL
00-master 4.0.0-0.150.0.0-dirty 2.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 2.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 2.2.0 16m
01-worker-kubelet 4.0.0-0.150.0.0-dirty 2.2.0 16m
master-1638c1aea398413bb918e76632f20799 4.0.0-0.150.0.0-dirty 2.2.0 16m
worker-2feef4f8288936489a5a832ca8efe953 4.0.0-0.150.0.0-dirty 2.2.0 16m
在应用这些MachineConfigs时，Machine Config Operator 的行为与Ignition有所不同。machineconfigs按顺序读取(从00到99)。machineconfigs中的标签标识每个节点(主节点或工作节点)的类型。如果相同的文件出现在多个machineconfig文件中，则最后一个获胜。因此，例如，出现在99文件中的任何文件都将替换出现在00文件中的相同文件。输入的machineconfig对象被合并到一个“呈现的”machineconfig对象中，该对象将被operator用作目标，并且是您可以在machineconfigpool中看到的值。
要查看从一个MachineConfigs中管理哪些文件，请在一个特定的MachineConfigs中查找“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
如果您想要更改其中一个文件中的设置，例如将crio.conf文件中的pids_limit更改为1500 (pids_limit = 1500)，您可以创建一个新的只包含您想要更改的文件的machineconfig。
确保稍后为machineconfig指定一个名称(例如10-worker-container-runtime)。请记住，每个文件的内容都是url样式的数据。然后将新的machineconfig应用于集群。
原文链接
https://docs.openshift.com/container-platform/4.3/architecture/architecture-rhcos.html
