红帽OpenShift容器平台4平台允许您流化用于创建
容器的
主机创建流程，包括在云服务提供商的基础架构中，在虚拟化平台上或在裸机系统中。 为了创建一个完整的云平台，我们必须严格控制所有使用的元素，从而提高复杂自动化流程的可靠性。
显而易见的解决方案是使用Red Hat Enterprise Linux CoreOS（Red Hat Enterprise Linux的一个变体）和CRI-O作为标准，这就是为什么...
由于导航主题非常成功，可以找到类比来解释Kubernetes和容器的操作，因此，我们以
Brunel生产索具的发明为例，来讨论CoreOS和CRI-O解决的那些业务问题。 1803年，马克·布鲁内尔（Mark Brunel）的任务是制造10万个索具，以满足不断发展的英国海军的需求。 起重滑车是一种将绳索固定到帆上的钻机。 直到19世纪初，这些砖块都是手工制作的，但Brunel能够实现自动化生产，并开始使用机器生产标准化砖块。 此过程的自动化意味着所有块几乎都是相同的，在发生故障时可以轻松更换，并且可以大量生产。
现在想象一下，布鲁内尔将必须为20种不同的船舶模型（Kubernetes版本）和具有完全不同的海流和风的5种不同行星（云提供商）执行此工作。 另外，要求所有船（OpenShift集群），无论正在航行的行星是什么，从船长（操作集群的操作员）的角度来看，都是一样的。 继续进行海洋类比，船长绝对不在乎其船上使用的索具（CRI-O）-对他们而言，主要是这些索具坚固且可靠。
作为云平台，OpenShift 4面临着非常相似的业务挑战。 必须在创建集群时，其中一个节点发生故障或扩展集群时创建新节点。 在创建和初始化新节点时，必须相应配置关键主机组件，包括CRI-O。 与其他任何生产一样，必须在开始时提供“原材料”。 就船舶而言，金属和木材是原材料。 但是，如果您创建用于在OpenShift 4集群中部署容器的主机，则必须在输入处提供配置文件和API服务器。 之后，OpenShift将在整个生命周期中提供必要的自动化水平，为最终用户提供必要的产品支持，从而在平台上获得回报。
OpenShift 4的创建旨在为云计算，虚拟化平台甚至裸机系统的所有主要供应商提供在平台的整个生命周期（适用于4.X版）中方便地更新系统的能力。 为此，必须在可互换元素的基础上创建节点。 当集群需要Kubernetes的新版本时，它还会在CoreOS上收到相应的CRI-O版本。 由于CRI-O版本直接与Kubernetes绑定，因此所有这些都极大地简化了测试，故障排除或支持的所有排列。 另外，这种方法降低了最终用户和Red Hat的成本。
这是Kubernetes集群的全新面貌，为计划新的高度有用和有吸引力的功能奠定了基础。 CRI-O（开放式容器项目“容器运行时接口-开放式容器计划”，缩写为CRI-OCI）是批量创建节点的最成功选择，而使用OpenShift则是必需的。 CRI-O将取代以前使用的Docker引擎，为OpenShift用户提供
经济，稳定，简单和无聊的功能 -是的，您没听错-专为与Kubernetes协同工作而设计的无聊容器引擎。
开放式容器的世界
长期以来，世界一直在向开放的容器前进。 无论是在Kubernetes还是较低级别，
容器标准的
发展都会在每个级别上形成创新生态系统。
这一切始于
2015年6月开放容器倡议的创建。 在工作的早期阶段，就形成了容器
映像（映像）和
运行时的规范。 这样就可以保证工具可以使用单一标准的
容器映像和单一格式来使用它们。 后来添加了
分发规范，使用户可以轻松交换
容器图像 。
然后，Kubernetes社区开发了一种称为
容器运行时接口（CRI）的单一可插接接口标准。 因此，除了Docker之外，Kubernetes用户还可以连接各种引擎来处理容器。
红帽和Google的工程师看到了对容器引擎的市场需求，该容器引擎可以使用CRI协议接受来自Kubelet的请求，并推出了与上述OCI规范兼容的容器。 因此
有一个OCID 。 但是，对不起，因为我们说过这些材料将专门用于CRI-O？ 实际上，仅在
1.0版发布时
，该项目便被重命名为CRI-O。
图 1。CRI-O和CoreOS的创新
随着OpenShift 4平台的发布，默认平台中使用的
容器引擎发生了变化，Docker被CRI-O取代，后者提供了与Kubernetes并行开发的经济，稳定，简单和无聊的容器启动环境。 这极大地简化了集群支持和配置。 在OpenShift 4中，配置容器引擎和主机以及对其进行管理变得自动化。
停下来，怎么了？
没错，随着OpenShift 4的到来，现在不再需要连接到单个主机并安装容器引擎，配置存储，配置用于搜索的服务器或配置网络。 OpenShift 4平台经过了完全重新设计，不仅可以在最终用户应用程序方面使用
操作员框架 ，还可以在基本平台级操作（例如部署映像，配置系统或安装更新）方面使用
操作员框架 。
Kubernetes始终允许用户通过确定所需状态并使用
控制器来确保实际状态尽可能接近给定状态来管理应用程序。 从开发的角度和操作的角度来看，这种
使用给定状态和实际状态的方法都带来了巨大的机会。 开发人员可以确定所需的状态，
并将其以 YAML或JSON文件的形式
传输给操作员，然后操作员可以在操作环境中创建必要的应用程序实例，而此实例的操作状态将完全与指定的状态相对应。
通过使用平台中的Operators，OpenShift 4将这一新范例（使用集合和实际状态的概念）引入到RHEL CoreOS和CRI-O的管理中。 使用所谓的
机器配置操作员（MCO）自动配置和版本控制操作系统和容器引擎的任务。 MCO大大简化了群集管理员的工作，从根本上实现了安装最后阶段以及安装后的后续操作（第二天的操作）的自动化。 所有这些使OpenShift 4成为真正的云平台。 稍后我们将对此进行详细介绍。
集装箱下水
用户有机会在OpenShift平台中从Tech Preview状态的3.7版本开始，从3.9版本的General Available（当前受支持）状态开始使用CRI-O引擎。 此外，从3.10版本开始，红帽
广泛使用
CRI-O在OpenShift Online中
启动生产工作负载 。 所有这些使从事CRI-O的团队在大型Kubernetes集群上大规模启动容器方面获得了丰富的经验。 为了基本了解Kubernetes如何使用CRI-O，让我们看一下下图，该图显示了架构的工作方式。
图 2.容器如何在Kubernetes集群中工作CRI-O在初始化新节点和发布OpenShift平台的新版本时，通过同步整个顶层来简化新容器主机的创建。 整个平台审核可以进行事务更新/回滚，还可以防止在容器尾部内核，容器引擎，Kubelets和Kubernetes Master之间的依赖关系中出现死锁。 通过集中管理所有平台组件以及版本控制和管理，您始终可以跟踪从状态A到状态B的清晰路径。这简化了更新过程，提高了安全性，改善了性能报告，并有助于降低更新和安装新版本的成本。
展示可互换元素的力量
如前所述，在OpenShift 4中使用Machine Config Operator管理容器主机和容器引擎提供了前所未有的自动化水平，这在Kubernetes平台上是不可能的。 为了演示新功能，我们展示了如何更改crio.conf文件。 为了避免混淆术语，请尝试着重于结果。
首先，让我们创建一个所谓的容器运行时配置-容器运行时配置。 考虑这是代表CRI-O配置的Kubernetes资源。 实际上，这是所谓的MachineConfig的专用版本，它是在OpenShift集群内的RHEL CoreOS计算机上部署的任何配置。
发明了这个名为ContainerRuntimeConfig的自定义资源，以使群集管理员可以更轻松地配置CRI-O。 这是一个功能强大的工具，根据MachineConfigPool的设置，它只能应用于某些节点。 考虑这组服务于相同目的的机器。
请注意我们将在/etc/crio/crio.conf文件中更改的最后两行。 这两行与crio.conf文件中的行非常相似，它们是：
vi ContainerRuntimeConfig.yaml
结论：
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug
现在，将此文件发送到Kubernetes集群，并验证它是否实际创建。 请注意，该操作与任何其他Kubernetes资源的执行方式相同：
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
结论：
NAME AGE set-log-and-pid 22h
创建ContainerRuntimeConfig之后，我们需要修改其中一个MachineConfigPools，以使Kubernetes了解我们希望将此配置应用于集群中的特定计算机组。 在这种情况下，我们将更改主节点的MachineConfigPool：
oc edit MachineConfigPool/master
结论（为清楚起见，剩下的要点）：
... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ...
此时，MCO开始为群集创建一个新的crio.conf文件。 在这种情况下，可以使用Kubernetes API查看完整完成的配置文件。 请记住，ContainerRuntimeConfig只是MachineConfig的专用版本，因此我们可以通过查看MachineConfigs中的行来查看结果：
oc get MachineConfigs | grep rendered
结论：
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
请注意，结果是主节点的配置文件比原始配置要新。 要查看它，请运行以下命令。 顺便说一句，我们注意到这可能是Kubernetes历史上最好的单行脚本之一：
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
结论：
pids_limit = 2048
现在，确保已将配置应用于所有主节点。 首先，我们获得集群中节点的列表：
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
现在查看已安装的文件。 您将看到该文件已使用我们在ContainerRuntimeConfig资源中指定的新pid和debug指令进行了更新。 优雅本身：
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
结论：
... pids_limit = 2048 ... log_level = "debug" ...
即使没有启动SSH，集群中的所有这些更改也已完成。 通过联系Kuberentes主节点完成了所有工作。 也就是说，这些新参数仅在主节点上配置。 同时，工作节点没有发生变化，这证明了Kubernetes方法的优点，即使用集状态和当前状态应用于容器和具有可互换元素的容器引擎的主机的当前状态。
上面的示例显示了对具有三个工作节点的小型OpenShift Container Platform 4集群或具有3000个节点的大型生产集群进行更改的能力。 在任何情况下，工作量都是相同的-并且非常小-只需配置ContainerRuntimeConfig文件，然后在MachineConfigPool中更改一个标签即可。 您可以在Kubernetes整个生命周期中使用的任何版本的OpenShift Container Platform 4.X平台上执行此操作。
通常，技术公司的发展速度如此之快，以至于我们无法解释为什么我们选择某些技术作为基本组件。 容器引擎历来是用户直接交互的组件。 由于容器的普及自然是随着容器引擎的出现而开始的，因此用户经常对它们表现出兴趣。 这是Red Hat选择CRI-O的另一个原因。 容器在不断发展，今天的重点是业务流程，我们得出的结论是，CRI-O在使用OpenShift 4时可提供最佳体验。