架构

OpenShift Container Platform 是用于开发和运行容器化应用程序的平台。它旨在允许支持的应用程序和数据中心从少量机器和应用程序扩展到为数百万客户端服务的数千台机器。

OpenShift Container Platform 以 Kubernetes 为基础，为大规模电信、流视频、游戏、银行和其他应用提供引擎技术。借助红帽开放技术中的实现，您可以将容器化应用程序从单一云扩展到内部和多云环境。

1.1.3. OpenShift Container Platform 概述

OpenShift Container Platform 为 Kubernetes 带来企业级增强，具体包括以下所列：

• 混合云部署。您可以将 OpenShift Container Platform 集群部署到各种公有云平台或数据中心中。
• 集成了红帽技术。OpenShift Container Platform 中的主要组件源自 Red Hat Enterprise Linux 和相关的红帽技术。OpenShift Container Platform 得益于红帽企业级优质软件的严格测试和认证计划。
• 开源开发模型。开发以开放方式完成，源代码可从公共软件存储库中获得。这种开放协作促进了快速创新和开发。

虽然 Kubernetes 擅长管理应用程序，但它并未指定或管理平台级要求或部署过程。强大而灵活的平台管理工具和流程是 OpenShift Container Platform 4.3 具备的重要优势。以下各节介绍 OpenShift Container Platform 的一些独特功能和优势。

1.1.3.1. 定制操作系统

OpenShift Container Platform 使用 Red Hat Enterprise Linux CoreOS (RHCOS)，这是一款面向容器的操作系统，结合了 CoreOS 和 Red Hat Atomic Host 操作系统的一些最佳特性和功能。RHCOS 是专门为从 OpenShift Container Platform 运行容器化应用程序而设计的，能够与新工具配合，提供快速安装、基于 Operator 的管理和简化的升级。

RHCOS 包括：

• Ignition，OpenShift Container Platform 将其用作首次启动系统配置来进行机器的初次上线和配置。
• CRI-O，Kubernetes 的原生容器运行时实现，可与操作系统紧密集成来提供高效和优化的 Kubernetes 体验。CRI-O，提供用于运行、停止和重启容器的工具。它完全取代了 OpenShift Container Platform 3 中使用的 Docker Container Engine。
• Kubelet，Kubernetes 的主要节点代理，负责启动和监视容器。

在 OpenShift Container Platform 4.3 中，所有 control plane 都需要使用 RHCOS。但 compute（计算）机器（也被称为 worker ）可以使用 Red Hat Enterprise Linux (RHEL) 做为操作系统。如果选择使用 RHEL worker，与将 RHCOS 用于所有集群机器相比，您必须执行更多的系统维护。

1.1.3.2. 简化的安装和更新流程

使用 OpenShift Container Platform 4.3 时，如果您拥有具有正确权限的帐户，通过运行单个命令并提供几个值，就能在支持的云中部署生产集群。如果使用支持的平台，您还可以自定义云安装或在数据中心中安装集群。

对于将 RHCOS 用于所有机器的集群，不论是更新还是升级，OpenShift Container Platform 都是一个简单又高度自动化的流程。由于 OpenShift Container Platform 可以从中央 control plane 全面控制每台机器上运行的系统和服务（包括操作系统本身），因此升级被设计为一个自动事件。如果集群包含 RHEL worker 机器，则 control plane 可从简化的更新过程中受益，但您还需执行更多任务来升级 RHEL 机器。

1.1.3.3. 其他主要功能

Operator 既是 OpenShift Container Platform 4.3 代码库的基本单元，又是部署供应用程序使用的应用程序和软件组件的便捷方式。在 OpenShift Container Platform 中，Operator 可充当平台的基础，不再需要手动升级操作系统和 control plane 应用程序。OpenShift Container Platform Operator（如 Cluster Version Operator 和 Machine Config Operator）允许对这些关键组件进行简化的集群范围内管理。

Operator Lifecycle Manager (OLM) 和 OperatorHub 提供了相应的工具，可用于存储 Operator 并将其分发给开发和部署应用程序的人员。

Red Hat Quay Container Registry 是一个 Quay.io 容器 registry，为 OpenShift Container Platform 集群提供大多数容器镜像和 Operator。Quay.io 是 Red Hat Quay 的一个公共 registry 版本，可存储数百万镜像和标签。

OpenShift Container Platform 中的其他 Kubernetes 增强功能包括软件定义网络 (SDN)、身份验证、日志聚合、监视和路由方面的改进。OpenShift Container Platform 还提供功能齐全的 web 控制台和自定义 OpenShift CLI (oc) 界面。

1.1.3.4. OpenShift Container Platform 生命周期

下图显示了 OpenShift Container Platform 的基本生命周期：

• 创建 OpenShift Container Platform 集群
• 管理集群
• 开发和部署应用程序
• 扩展应用程序

图 1.1. OpenShift Container Platform 高级概述

OpenShift Container Platform 安装程序为您提供了灵活性。您可以使用安装程序将集群部署到由安装程序置备并由集群维护的基础架构中，也可以将集群部署到您自己准备和维护的基础架构中。

这两种基本类型的 OpenShift Container Platform 集群通常称为安装程序置备的基础架构集群和用户置备的基础架构集群。

两种类型的集群都具有以下特征：

两种类型的集群都使用同一个安装程序来部署。安装程序生成的主要资产是用于 Bootstrap、master 和 worker 机器的 Ignition 配置文件。有了这三个配置和配置得当的基础架构，就能启动 OpenShift Container Platform 集群。

OpenShift Container Platform 安装程序使用一组目标和依赖项来管理集群安装。安装程序具有一组必须实现的目标，并且每个目标都有一组依赖项。因为每个目标仅关注其自己的依赖项，所以安装程序可以采取措施来并行实现多个目标。最终目标是正常运行的集群。通过满足依赖项而不是运行命令，安装程序能够识别和使用现有的组件，而不必运行命令来再次创建它们。

下图显示了安装目标和依赖项的子集：

图 2.1. OpenShift Container Platform 安装目标和依赖项

在安装后，每一个集群机器都将使用 Red Hat Enterprise Linux CoreOS (RHCOS) 作为操作系统。RHCOS 是 Red Hat Enterprise Linux (RHEL) 的不可变容器主机版本，具有默认启用 SELinux 的 RHEL 内核。它包括作为 Kubernetes 节点代理的 kubelet，以及为 Kubernetes 优化的 CRI-O 容器运行时。

OpenShift Container Platform 4.3 集群中的每一 control plane 机器都必须使用 RHCOS，其中包括一个关键的首次启动置备工具，称为 Ignition。这一工具让集群能够配置机器。操作系统更新作为嵌入在容器镜像中的 Atomic OSTree 存储库交付，该镜像由 Operator 在整个集群中推广。实际的操作系统更改通过使用 rpm-ostree 在每台机器上作为原子操作原位进行。通过结合使用这些技术，OpenShift Container Platform 可以像管理集群上的任何其他应用程序一样管理操作系统，通过原位升级使整个平台保持最新状态。这些原位更新可以减轻运维团队的负担。

如果将 RHCOS 用作所有集群机器的操作系统，则集群将管理其组件和机器的所有方面，包括操作系统在内。因此，只有安装程序和 Machine Config Operator 才能更改机器。安装程序使用 Ignition 配置文件设置每台机器的确切状态，安装后则由 Machine Config Operator 完成对机器的更多更改，例如应用新证书或密钥等。

2.1.2. 安装过程

当安装 OpenShift Container Platform 集群时，从 Red Hat OpenShift Cluster Manager 站点上的相应的 Infrastructure Provider 页面下载安装程序。此网站管理以下内容：

• 帐户的 REST API
• registry 令牌，这是用于获取所需组件的 pull secret
• 集群注册，它将集群身份信息与您的红帽帐户相关联，以方便收集使用情况指标

在 OpenShift Container Platform 4.3 中，安装程序是对一组资产执行一系列文件转换的 Go 二进制文件。与安装程序交互的方式因您的安装类型而异。

• 对于具有安装程序置备的基础架构集群，您可以将基础架构启动和置备委派给安装程序，而不是亲自执行。安装程序将创建支持集群所需的所有网络、机器和操作系统。
• 如果亲自为集群置备和管理基础架构，则必须提供所有集群基础架构和资源，包括 Bootstrap 机器、网络、负载均衡、存储和独立的集群机器。您无法使用安装程序置备的基础架构集群所提供的高级机器管理和扩展功能。

安装期间使用三组文件：名为 install-config.yaml 的安装配置文件、Kubernetes 清单，以及您的机器类型适用的 Ignition 配置文件。

重要

安装期间可以修改控制基础 RHCOS 操作系统的 Kubernetes 和 Ignition 配置文件。但是，没有可用的验证机制来确认您对这些对象所做修改是适当的。如果修改了这些对象，集群可能会无法运行。由于存在这种风险，修改 Kubernetes 和 Ignition 配置文件不受支持，除非您遵循记录的流程或在红帽支持指示下操作。

安装配置文件转换为 Kubernetes 清单，然后清单嵌套到 Ignition 配置文件中。安装程序使用这些 Ignition 配置文件来创建集群。

运行安装程序时，所有配置文件会被修剪，因此请务必备份需要再次使用的所有配置文件。

重要

安装之后，您无法修改在安装过程中设置的参数，但可以修改一些集群属性。

采用安装程序置备的基础架构的安装过程

默认安装类型为使用安装程序置备的基础架构。默认情况下，安装程序充当安装向导，提示您输入它无法自行确定的值，并为其余参数提供合理的默认值。您还可以自定义安装过程来支持高级基础架构场景。安装程序将为集群置备底层基础架构。

您可以安装标准集群或自定义集群。对于标准集群，您要提供安装集群所需的最低限度详细信息。对于自定义集群，您可以指定有关平台的更多详细信息，如 control plane 使用的机器数量、集群部署的虚拟机的类型，或 Kubernetes 服务网络的 CIDR 范围。

若有可能，可以使用此功能来避免置备和维护集群基础架构。在所有其他环境中，可以使用安装程序来生成置备集群基础架构所需的资产。

对于安装程序置备的基础架构的集群，OpenShift Container Platform 可以管理集群的所有方面，包括操作系统本身。每台机器在启动时使用的配置引用其加入的集群中托管的资源。此配置允许集群在应用更新时自行管理。

采用用户置备的基础架构的安装过程

您还可以在自己提供的基础架构上安装 OpenShift Container Platform。您可以使用安装程序来生成置备集群基础架构所需的资产，再创建集群基础架构，然后将集群部署到您提供的基础架构中。

如果不使用安装程序置备的基础架构，您必须自己管理和维护集群资源，包括：

• 组成集群的 control plane 和计算机器的底层基础架构
• 负载均衡器
• 集群网络，包括 DNS 记录和所需的子网
• 集群基础架构和应用程序的存储

如果您的集群使用用户置备的基础架构，则可以选择将 RHEL worker 机器添加到集群中。

安装过程详细信息

由于在置备时集群中的每台机器都需要集群的相关信息，因此 OpenShift Container Platform 在初始配置期间会使用临时 Bootstrap 机器将所需的信息提供给持久 control plane。通过使用描述如何创建集群的 Ignition 配置文件进行启动。Bootstrap 机器将创建组成 control plane 的 master 机器。然后，control plane 机器创建计算（compute）机器。下图说明了这一过程：

图 2.2. 创建 Bootstrap、master 和 worker 机器

集群机器初始化后，Bootstrap 机器将被销毁。所有集群都使用 Bootstrap 过程来初始化集群，但若您自己置备集群的基础架构，则必须手动完成许多步骤。

重要

安装程序生成的 Ignition 配置文件中所含的证书会在 24 小时后过期。您必须完成集群安装，并使集群以非降级状态运行 24 小时，以确保完成第一次证书轮转。

bootstrapp 集群涉及以下步骤：

1. bootstrap 机器启动并开始托管 master 机器启动所需的远程资源。（如果自己配置基础架构，则需要人工干预）
2. master 机器从 bootstrap 机器获取远程资源并完成启动。（如果自己配置基础架构，则需要人工干预）
3. master 机器使用 bootstrap 机器来组成 etcd 集群。
4. bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
5. 临时 control plane 将生产环境的 control plane 调度到 master 机器。
6. 临时 control plane 关机，并将控制权交给生产环境 control plane。
7. bootstrap 机器将 OpenShift Container Platform 组件注入生产环境 control plane。
8. 安装程序关闭 bootstrap 机器。（如果自己配置基础架构，则需要人工干预）
9. control plane 设置 worker 节点。
10. control plane 以一组 Operator 的形式安装其他服务。

完成此 bootstrap 过程后，将生成一个全面运作的 OpenShift Container Platform 集群。然后，集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建 worker 机器。

安装过程详细信息

安装范围

OpenShift Container Platform 安装程序的作用范围特意设计得比较狭窄。它旨在简化操作并确保成功。安装完成后，您可以完成更多的配置任务。

OpenShift Container Platform 更新服务是一种托管服务，为 OpenShift Container Platform 和 Red Hat Enterprise Linux CoreOS (RHCOS) 提供无线更新 (over-the air update)。它提供了一个组件 Operator 图，其中包含各个顶点及连接它们的边。图中的边显示可以安全更新的版本，顶点是更新有效负载，用于指定托管集群组件的预期状态。

集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务，并根据当前组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时，OpenShift Container Platform CVO 使用该更新的发行镜像来升级您的集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。

为了使 OpenShift Container Platform 更新服务仅提供兼容的更新，提供了一个版本验证管道来驱动自动化。每个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本后，OpenShift Container Platform 更新服务会通知您可以进行更新。

对于连续更新模式，会运行两个控制器。一个控制器不断更新有效负载清单，将它们应用于集群，并输出受控 Operator 部署的状态（可用、正在进行升级或失败）。第二个控制器轮询 OpenShift Container Platform 更新服务以确定更新是否可用。

在升级过程中，Machine Config Operator (MCO) 会将新配置应用到集群机器。它将机器配置池中由 maxUnavailable 字段指定数量的节点保护起来，并将其标记为不可用。在默认情况下，这个值被设置为 1。然后，它会应用新配置并重启机器。如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker，MCO 不会在这些机器上更新 kubelet，因为您必须首先在这些机器上更新 OpenShift API。因为新版本的规格被应用到旧的 kubelet，所以 RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更新。但是，通过设置不可用节点的最大数量可以确保当不可用机器的数量没有超过这个值时，正常的集群操作仍然可以继续进行。

Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管（unmanaged） 状态，它不会响应配置更改，也不会收到更新。

虽然它可以在非生产环境集群或调试过程中使用，但处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。

可使用以下方法将 Operator 设置为非受管状态：

control plane 由 master 机器组成，负责管理 OpenShift Container Platform 集群。control plane 机器管理计算机器（也被称为 worker）上的工作负载。集群本身通过Cluster Version Operator、Machine Config Operator 和一组单独 Operator 的操作来管理对机器的所有升级。

您可以通过多种方式使用容器来进行应用程序开发，每种方法更适合的使用情景也各不相同。为了说明这种多样性，本文在介绍一系列方法时首先从开发单个容器开始，最后将容器部署为面向大型企业的任务关键型应用程序。这些方法展示了不同的工具、格式和方法，供您用于容器化应用程序开发。本主题描述：

您对应用程序有了一个想法，想要对其进行容器化。

首先，您需要一个用于构建容器的工具，如 buildah 或 docker，还需要一个描述容器中内容的文件，通常是 Dockerfile。

接下来，您需要一个位置来推送生成的容器镜像，以便可以将它拉取到您想要它运行的位置。这个位置就是容器 registry。

大多数 Linux 操作系统上都会默认安装各个组件的一些示例，但 Dockerfile 除外，需要您自己提供。

下图显示了构建和推送镜像的流程：

图 4.1. 创建简单容器化应用程序并将其推送到 registry

如果您使用运行 Red Hat Enterprise Linux (RHEL) 作为操作系统的计算机，则容器化应用程序创建过程需要以下几个步骤：

如需有关如何构建容器镜像、将其推送到 registry 并运行它们的过程的更多详细信息，请参阅使用 Buildah 自定义镜像构建。

4.2.2. 基础镜像选项

选择用来构建应用程序的基础镜像包含一组软件，这些软件为应用程序提供一个 Linux 系统。在您构建自己的镜像时，您的软件将放置到该文件系统中，可以像对待操作系统一样看待该文件系统。基础镜像的选择会对容器未来的安全性、效率和可升级性产生重大影响。

红帽提供了一组新的基础镜像，称为红帽通用基础镜像 (UBI)。这些镜像基于 Red Hat Enterprise Linux，与红帽过去提供的基础镜像相似，但有一个主要区别：无需红帽订阅就能自由重新分发。因此，您可以在 UBI 镜像上构建应用程序，不必担心如何共享它们或需要为不同的环境创建不同的镜像。

这些 UBI 镜像具有标准、初始和最低版本。您还可以将 Red Hat Software Collections 镜像用作依赖特定运行时环境（如 Node.js、Perl 或 Python）的应用程序的基础。其中一些运行时基础镜像的特殊版本称为 Source-to-Image (S2I) 镜像。使用 S2I 镜像时，您可以将代码插入到可随时运行该代码的基础镜像环境中。

您可以直接从 OpenShift Container Platform Web UI 中使用 S2I 镜像，只需选择 Catalog → Developer Catalog 便可，如下图中所示：

图 4.2. 为需要特定运行时的应用选择 S2I 基础镜像

尽管容器镜像是容器化应用程序的基本构建块，但需要更多信息才能在 Kubernetes 环境（如 OpenShift Container Platform）中管理和部署该应用程序。创建镜像后的典型后续步骤：

如果您的应用程序要提供给他人运行，最好将其打包并部署为 Operator。如前文所述，Operator 向您的应用程序添加了一个生命周期组件。使用它可以实现在安装应用程序后需要进行的维护任务。

在将应用程序创建为 Operator 时，您可以纳入自己有关如何运行和维护应用程序的知识。您可以内置用来升级、备份、扩展应用程序或跟踪其状态的功能。正确配置应用程序后，维护任务（如更新 Operator）可以自动发生，并且不为 Operator 用户所见。

例如，设置为在特定时间自动备份数据的 Operator 就非常实用。让 Operator 在设定的时间管理应用程序备份，可以使系统管理员免于记忆这些事务。

传统上手动完成的任何应用程序维护（如备份数据或轮转证书）都可以借助 Operator 自动完成。

Red Hat Enterprise Linux CoreOS (RHCOS) 代表了下一代单用途容器操作系统技术。RHCOS 由创建了 Red Hat Enterprise Linux Atomic Host 和 CoreOS Container Linux 的同一开发团队打造，它将 Red Hat Enterprise Linux (RHEL) 的质量标准与 Container Linux 的自动化远程升级功能结合在一起。

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

要查看用于部署 bootstrap 机器的 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 命令。以下示例使用了上方输出中添加至 bootstrap 机器的 /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，您应该会看到类似于下面这一行，它确认了如何从 bootstrap 获取 Ignition 配置：

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

您可以从 bootstrap.ign 文件中了解到以下内容：

机器配置池管理节点集群及其相应的机器配置（Machine Configs）。机器配置包含集群的配置信息。列出所有已知的机器配置池：

$ 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   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

在涉及到应用这些机器配置时，Machine Config Operator 的行为与 Ignition 有些不同。MachineConfig 按顺序读取（从 00* 到 99*）。MachineConfig 中的标签标识每个所用于的节点类型（master 节点或 worker 节点）。如果同一文件出现在多个 MachineConfig 文件中，则以最后一个文件为准。例如，出现在 99* 文件中的任何文件都将替换出现在 00* 文件中的同一文件。输入的 MachineConfig 对象将合并为一个“渲染的”MachineConfig 对象，该对象将被 Operator 用作目标，也是您可以在 MachineConfigPool 中看到的值。

要查看正在通过 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

确保为 MachineConfig 提供更新的名称（例如 10-worker-container-runtime）。请记住，每个文件的内容都是 URL 样式的数据。然后，将新 MachineConfig 应用到集群。

持续集成 是开发人员自动化的过程。应用程序的代码更改会定期构建、测试并合并到共享的存储库。

持续提供 和 连续部署是有时可互换使用的概念，指的是管道的自动化。持续提供使用自动化，以确保开发人员对应用程序的更改经过测试并发送到软件仓库，操作团队可以将它们部署到产品环境中。持续部署可以实现更改的发行，从存储库开始，并以生产结束。持续部署会加快应用程序的交付使用的速度，并可减少操作团队的工作量。

GitOps 是一组使用 Git 拉取请求来管理基础架构和应用程序配置的实践。GitOps 中的 Git 存储库是系统和应用程序配置的唯一来源。该程序库包含该系统的完整状态，以便可查看并可审核更改到系统状态。GitOps 允许您实施 DevOps 方法。

您可以使用 GitOps 工具来创建可重复和可预测的进程来管理和重新创建 OpenShift Container Platform 集群和应用程序。通过使用 GitOps，您可以处理基础架构和应用程序配置 sprawl 的问题。它通过将您的基础架构和应用程序定义为“代码”，简化了跨多个群集的基础架构和应用程序配置的传播。 为集群配置文件实现 GitOps 可方便自动安装，并可让您配置自动化集群自定义。您可以将在 Git 存储库中开发和维护软件的核心原则应用到创建和管理集群和应用程序配置文件。

通过使用 OpenShift Container Platform 自动执行集群配置和容器开发过程，您可以选择在哪里和何时执行 GitOps 操作。使用与您的 GitOps 策略和执行计划相对应的 CI 管道是最理想的选择。OpenShift Container Platform 提供了选择何时和如何将这个方法整合到您的业务实践和管道中的灵活性。

通过 GitOps 集成，您可以声明性地配置和存储 OCP 集群配置

GitOps 可在 OpenShift Container Platform 中正常工作，因为您可以声明性地配置集群并将集群配置状态存储在 Git 中。如需更多信息，请参阅 可用的集群自定义。

ArgoCD 是一个声明式连续交付工具，它利用 GitOps 来维护集群资源。ArgoCD 是作为控制器实现的，可持续监控 Git 存储库中定义的应用程序定义和配置，并将这些配置的指定状态与集群中的实时状态进行比较。和 Git 存储库中指定状态不同的配置被归类为 OutOfSync。ArgoCD 报告这些不同之处，并允许管理员自动或者手动将配置重新同步到定义的状态。

ArgoCD 可让您提供全局自定义资源，如用于配置 OpenShift Container Platform 集群的资源。

红帽不提供对这个工具的支持。要获得对 ArgoCD 的支持，请参阅 ArgoCD 文档的支持信息。

有关使用 ArgoCD 的更多信息，请参见 ArgoCD 文档。

准入（Admission）插件用于帮助规范 OpenShift Container Platform 4.3 的功能。在请求被验证并授权后，准入插件截取到主 API 的请求，验证资源请求以确保符合相关的策略。例如，它们通常会被用来强制执行安全策略、资源限制或配置要求。

准入插件以准入链的形式按序列运行。如果序列中的任何准入插件拒绝某个请求，则整个链将中止并返回错误。

OpenShift Container Platform 为每个资源类型都启用了默认的准入插件。这些是集群正常工作所需要的。准入插件会忽略那些不由它们负责的资源。

除了默认的插件外，准入链还可以通过调用自定义 webhook 服务器的 webhook 准入插件动态进行扩展。webhook 准入插件有两种： 变异准入插件和验证准入插件。变异准入插件会首先运行，它可以修改资源并验证请求。验证准入插件会验证请求，并在变异准入插件之后运行，以便由变异准入插件触发的改变也可以被验证。

通过一个变异准入插件调用 webhook 服务器可能会对与目标对象相关的资源产生副作用。在这种情况下,，必须执行相应的步骤来验证最终结果是正确的。

OpenShift Container Platform 4.3 中启用了一组默认准入插件。这些默认插件可实现基本的 control plane 功能，如入口策略、集群资源限制覆盖和配额策略。

除了 OpenShift Container Platform 默认准入插件外，也可以通过称为 webhook 服务器的 webhook 准入插件来实施动态准入，从而扩展准入链的功能。Webhook 服务器通过 HTTP 在定义的端点调用。

OpenShift Container Platform 中有两个类型的 webhook 准入插件：

当 API 请求到来时，变异或验证准入插件会使用配置中的外部 webhook 列表,并并行调用它们：

webhook 准入插件和 webhook 服务器之间的通信必须使用 TLS。生成一个 CA 证书，使用该证书为您的 webhook 准入服务器使用的服务器证书签名。PEM 编码的 CA 证书使用某种机制（如 service serving 证书 secret）提供给 webhook 准入插件。

下图演示了调用多个 webhook 服务器的序列准入链进程。

图 8.1. 带有变异准入插件和验证准入插件的 API 准入链

webhook 准入插件用例示例。这这个示例中，所有 pod 都必须具有一组通用标签。在本例中，变异准入插件可以注入标签，验证准入插件可以检查标签是否如预期。之后，OpenShift Container Platform 可以调度包含所需标签的 pod，并拒绝那些没有所需标签的 pod。

Webhook 准入插件常见使用案例包括：

集群管理员可以通过 API 服务器准入链中的变异准入插件或验证准入插件调用 webhook 服务器。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default 5
      name: kubernetes 6
     path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: None

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration 1
metadata:
  name: <webhook_name> 2
webhooks:
- name: <webhook_name> 3
  clientConfig: 4
    service:
      namespace: default  5
      name: kubernetes 6
     path: <webhook_url> 7
    caBundle: <ca_signing_certificate> 8
  rules: 9
  - operations: 10
    - <operation>
    apiGroups:
    - ""
    apiVersions:
    - "*"
    resources:
    - <resource>
  failurePolicy: <policy> 11
  sideEffects: Unknown

此流程概述了配置动态准入的高级步骤。通过配置 webhook 准入插件来调用 webhook 服务器以扩展准入链的功能。

webhook 服务器也被配置为一个聚合的 API 服务器。这允许其他 OpenShift Container Platform 组件使用内部凭证与 webhook 通信，并可使用 oc 命令进行测试。另外，这还可在 webhook 中启用基于角色的访问控制（RBAC），并防止向 webhook 公开其他 API 服务器的令牌信息。