平台 让您简化创作 ，包括云服务提供商的基础设施、虚拟化平台或裸机系统。 为了创建一个真正基于云的平台，我们必须严格控制所使用的所有元素，从而提高复杂自动化流程的可靠性。
显而易见的解决方案是使用 Red Hat Enterprise Linux CoreOS（Red Hat Enterprise Linux 的一个变体）和 CRI-O 作为标准，原因如下......
由于航行这个话题在解释 Kubernetes 和容器的工作时非常适合寻找类比，所以让我们尝试用一个例子来谈谈 CoreOS 和 CRI-O 解决的业务问题 。 1803 年，马克·布鲁内尔 (Marc Brunel) 受命生产 100 个索具组，以满足不断壮大的英国海军的需求。 索具组是一种用于将绳索连接到帆上的索具。 直到 19 世纪初，这些砌块都是手工制作的，但布鲁内尔成功实现了生产自动化，并开始使用机床生产标准化砌块。 这一过程的自动化意味着生成的块本质上是相同的，如果损坏可以轻松更换，并且可以大量生产。
现在想象一下，如果 Brunel 必须为 20 种不同的船舶模型（Kubernetes 版本）和五个具有完全不同海流和风的不同行星（云提供商）完成这项工作。 此外，从船长（管理集群运行的操作员）的角度来看，所有船舶（OpenShift 集群），无论在哪个行星上进行导航，都必须表现得相同。 继续用海事类比来说，船长根本不关心他们的船上使用什么样的索具组 (CRI-O) - 对他们来说最重要的是这些索具坚固可靠。
OpenShift 4 作为一个云平台，面临着非常相似的业务挑战。 如果节点之一发生故障或扩展集群时，必须在创建集群时创建新节点。 创建并初始化新节点时，必须相应配置关键主机组件（包括 CRI-O）。 与任何其他生产一样，必须在一开始就提供“原材料”。 就船舶而言，原材料是金属和木材。 但是，在创建用于在 OpenShift 4 集群中部署容器的主机时，您需要将配置文件和提供 API 的服务器作为输入。 然后，OpenShift 将在整个生命周期中提供所需的自动化水平，为最终用户提供必要的产品支持，从而收回平台投资。
OpenShift 4 的创建方式是为所有主要云计算提供商、虚拟化平台甚至裸机系统提供在平台的整个生命周期（版本 4.X）中方便地更新系统的能力。 为此，必须在可互换元素的基础上创建节点。 当集群需要新版本的 Kubernetes 时，它还会收到 CoreOS 上相应版本的 CRI-O。 由于 CRI-O 版本直接与 Kubernetes 绑定，这极大地简化了用于测试、故障排除或支持目的的任何排列。 此外，这种方法还降低了最终用户和红帽的成本。
这是一种全新的 Kubernetes 集群思考方式，为规划一些非常有用且引人注目的新功能奠定了基础。 CRI-O（容器运行时接口 - 开放容器计划，缩写为 CRI-OCI）被证明是大规模创建与 OpenShift 配合使用所需的节点的最成功选择。 CRI-O 将取代之前使用的 Docker 引擎，为 OpenShift 用户提供服务 – 是的，你没听错 – 一个无聊的容器引擎，专门为与 Kubernetes 一起使用而创建。
开放容器的世界
长期以来，世界一直在朝着开放式容器的方向发展。 无论是在 Kubernetes 中，还是在较低级别， 从而形成各个层面的创新生态系统。
这一切都始于开放容器倡议的创建 。 在工作的早期阶段，容器规范已经形成 и 。 这确保了这些工具可以使用单一标准 以及与它们合作的统一格式。 后来添加了规格 ，让用户轻松分享 .
随后，Kubernetes 社区为可插拔接口开发了一个单一标准，称为 。 因此，除了 Docker 之外，Kubernetes 用户还能够连接各种引擎来使用容器。
红帽和谷歌的工程师看到了市场对能够通过 CRI 协议接受 Kubelet 请求的容器引擎的需求，并引入了与上述 OCI 规范兼容的容器。 所以 。 但是请问，我们不是说这个材料会献给CRI-O吗？ 事实上确实如此，只是随着发布 该项目更名为 CRI-O。
图。 1。
CRI-O 和 CoreOS 的创新
随着 OpenShift 4 平台的推出，它发生了变化 ，在平台中默认使用，并且 Docker 被 CRI-O 取代，为运行与 Kubernetes 并行开发的容器提供了一个经济高效、稳定、简单且无聊的环境。 这极大地简化了集群支持和配置。 容器引擎和主机的配置及其管理在 OpenShift 4 中变得自动化。
等等，这怎么样？
没错，随着 OpenShift 4 的出现，不再需要连接到各个主机并安装容器引擎、配置存储、配置搜索服务器或配置网络。 OpenShift 4 平台经过彻底重新设计，可以使用 不仅涉及最终用户应用程序，还涉及基本平台级操作，例如部署映像、配置系统或安装更新。
Kubernetes 始终允许用户通过定义所需状态并使用 ，以确保实际状态与目标状态尽可能匹配。 这 从开发和运营的角度来看，这都带来了巨大的机遇。 开发人员可以通过以下方式定义所需的状态 以 YAML 或 JSON 文件的形式传递给操作者，然后操作者就可以在生产环境中创建所需的应用实例，并且该实例的运行状态将与指定的完全对应。
通过在平台中使用 Operator，OpenShift 4 将这种新范例（使用设置和实际状态的概念）引入到 RHEL CoreOS 和 CRI-O 的管理中。 配置和管理操作系统和容器引擎版本的任务是使用所谓的自动化 。 MCO 极大地简化了集群管理员的工作，基本上实现了安装最后阶段以及后续安装后操作（第二天操作）的自动化。 所有这些使 OpenShift 4 成为真正的云平台。 我们稍后会讨论这个问题。
运行容器
自版本 3.7 处于技术预览状态以及版本 3.9 处于正式可用状态（当前支持）以来，用户有机会在 OpenShift 平台中使用 CRI-O 引擎。 此外，红帽大量使用 自版本 3.10 起在 OpenShift Online 中。 所有这些使得 CRI-O 团队在大型 Kubernetes 集群上大规模启动容器方面获得了丰富的经验。 为了基本了解 Kubernetes 如何使用 CRI-O，让我们看一下下图，它展示了该架构的工作原理。
米。 2. 容器如何在 Kubernetes 集群中工作
CRI-O 通过在初始化新节点以及发布 OpenShift 平台新版本时同步整个顶层，简化了新容器主机的创建。 整个平台的修订允许事务性更新/回滚，还可以防止容器尾部核心、容器引擎、节点（Kubelet）和 Kubernetes Master 节点之间的依赖关系出现死锁。 通过集中管理所有平台组件，并进行控制和版本控制，从状态 A 到状态 B 始终有一条清晰的路径。这简化了更新过程，提高了安全性，改进了性能报告，并有助于降低更新和安装新版本的成本。
展示替换元素的力量
如前所述，在 OpenShift 4 中使用 Machine Config Operator 管理容器主机和容器引擎提供了新的自动化水平，这在 Kubernetes 平台上以前是不可能实现的。 为了演示新功能，我们将展示如何更改 crio.conf 文件。 为了避免被术语混淆，请尝试关注结果。
首先，让我们创建所谓的容器运行时配置 - Container Runtime Config。 将其视为代表 CRI-O 配置的 Kubernetes 资源。 实际上，它是 MachineConfig 的专门版本，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 后，我们需要修改其中一个 MachineConfigPool，以向 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 来执行此操作。
通常，技术公司发展得如此之快，以至于我们无法解释为什么我们为底层组件选择某些技术。 容器引擎历来是用户直接交互的组件。 由于容器的流行自然是随着容器引擎的出现而开始的，因此用户经常对它们表现出兴趣。 这也是红帽选择CRI-O的另一个原因。 容器正在不断发展，现在的重点是编排，我们发现 CRI-O 在使用 OpenShift 4 时提供了最佳体验。
来源： habr.com