2.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.4 集群中的每一 control plane 机器都必须使用 RHCOS，其中包括一个关键的首次启动置备工具，称为 Ignition。这一工具让集群能够配置机器。操作系统更新作为嵌入在容器镜像中的 Atomic OSTree 存储库交付，该镜像由 Operator 在整个集群中推广。实际的操作系统更改通过使用 rpm-ostree 在每台机器上作为原子操作原位进行。通过结合使用这些技术，OpenShift Container Platform 可以像管理集群上的任何其他应用程序一样管理操作系统，通过原位升级使整个平台保持最新状态。这些原位更新可以减轻运维团队的负担。
如果将 RHCOS 用作所有集群机器的操作系统，则集群将管理其组件和机器的所有方面，包括操作系统在内。因此，只有安装程序和 Machine Config Operator 才能更改机器。安装程序使用 Ignition 配置文件设置每台机器的确切状态，安装后则由 Machine Config Operator 完成对机器的更多更改，例如应用新证书或密钥等。
2.1.1. 适用的平台
在 OpenShift Container Platform 4.4 中，您可以在以下平台上安装使用安装程序置备的基础架构集群：
• Amazon Web Services (AWS)
• Google Cloud Platform (GCP)
• Microsoft Azure
• Red Hat OpenStack Platform 版本 13 和 16
o 最新的 OpenShift Container Platform 版本支持最新的 RHOSP 长生命版本和中间版本。如需完整的 RHOSP 发行版本兼容性信息，请参阅 RHOSP 上的 OpenShift Container Platform 支持列表。
• Red Hat Virtualization (RHV)
对于所有这些集群，包括用来运行安装过程的计算机在内的所有机器都必须可直接访问互联网，以便为平台容器拉取镜像并向红帽提供 telemetry 数据。
在 OpenShift Container Platform 4.4 中，您可以在以下平台上安装使用用户置备的基础架构集群：
• AWS
• Azure
• GCP
• RHOSP
• VMware vSphere
• 裸机
在用户置备的基础架构上安装，每台机器都可拥有完整的互联网访问能力，您可以将集群放置在代理后面，也可以执行受限网络安装。在受限网络安装中，您可以下载安装集群所需的镜像（image），将它们放在镜像 registry（mirror registry）中，然后使用那些数据安装集群。虽然您需要访问互联网来为平台容器拉取镜像，但在 vSphere 或裸机基础架构上进行受限网络安装，您的集群机器不需要直接访问互联网。
OpenShift Container Platform 4.x Tested Integrations 页面中提供了有关针对不同平台进行集成测试的详细信息。
2.1.2. 安装过程
当安装 OpenShift Container Platform 集群时，从 Red Hat OpenShift Cluster Manager 站点上的相应的 Infrastructure Provider 页面下载安装程序。此网站管理以下内容：
• 帐户的 REST API
• registry 令牌，这是用于获取所需组件的 pull secret
• 集群注册，它将集群身份信息与您的红帽帐户相关联，以方便收集使用情况指标
在 OpenShift Container Platform 4.4 中，安装程序是对一组资产执行一系列文件转换的 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 集群涉及以下步骤：
- bootstrap 机器启动并开始托管 master 机器启动所需的远程资源。（如果自己配置基础架构，则需要人工干预）
- master 机器从 bootstrap 机器获取远程资源并完成启动。（如果自己配置基础架构，则需要人工干预）
- master 机器使用 bootstrap 机器来组成 etcd 集群。
- bootstrap 机器使用新的 etcd 集群启动临时 Kubernetes control plane。
- 临时 control plane 将生产环境的 control plane 调度到 master 机器。
- 临时 control plane 关机，并将控制权交给生产环境 control plane。
- bootstrap 机器将 OpenShift Container Platform 组件注入生产环境 control plane。
- 安装程序关闭 bootstrap 机器。（如果自己配置基础架构，则需要人工干预）
- control plane 设置 worker 节点。
- control plane 以一组 Operator 的形式安装其他服务。
完成此 bootstrap 过程后，将生成一个全面运作的 OpenShift Container Platform 集群。然后，集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建 worker 机器。
安装过程详细信息
安装范围
OpenShift Container Platform 安装程序的作用范围特意设计得比较狭窄。它旨在简化操作并确保成功。安装完成后，您可以完成更多的配置任务。
2.2. 关于 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 状态。在机器可用前，您无法完成更新。但是，通过设置不可用节点的最大数量可以确保当不可用机器的数量没有超过这个值时，正常的集群操作仍然可以继续进行。
2.3. 支持非受管 OPERATOR 的策略
Operator 的 管理状态 决定了一个 Operator 是否按设计积极管理集群中其相关组件的资源。如果 Operator 设置为 非受管（unmanaged） 状态，它不会响应配置更改，也不会收到更新。
虽然它可以在非生产环境集群或调试过程中使用，但处于非受管状态的 Operator 不被正式支持，集群管理员需要完全掌控各个组件的配置和升级。
可使用以下方法将 Operator 设置为非受管状态：
• 独立 Operator 配置
独立 Operator 的配置中具有 managementState 参数。这可以通过不同的方法来访问，具体取决于 Operator。例如，Cluster Logging Operator 通过修改它管理的自定义资源 (CR) 来达到此目的，而 Samples Operator 使用了集群范围配置资源。
将 managementState 参数更改为 Unmanaged 意味着 Operator 不会主动管理它的资源，也不会执行与相关组件相关的操作。一些 Operator 可能不支持此管理状态，因为它可能会损坏集群，需要手动恢复。
• 警告
将独立 Operator 更改为非受管状态会导致不支持该特定组件和功能。报告的问题必须在 受管（Managed） 状态中可以重复出现才能继续获得支持。
• Cluster Version Operator (CVO) 覆盖
可将 spec.overrides 参数添加到 CVO 配置中，以便管理员提供对组件的 CVO 行为覆盖的列表。将一个组件的 spec.overrides[].unmanaged 参数设置为 true 会阻止集群升级并在设置 CVO 覆盖后提醒管理员：
Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
警告
设置 CVO 覆盖会使整个集群处于不受支持状态。在删除所有覆盖后，必须可以重现报告的问题方可获得支持。
