第 1 章 OpenShift Container Platform 安装概述
1.1. OpenShift Container Platform 安装概述
OpenShift Container Platform 安装程序为您提供了灵活性。您可以使用安装程序将集群部署到由安装程序置备并由集群维护的基础架构中，也可以将集群部署到您自己准备和维护的基础架构中。
这两种基本类型的 OpenShift Container Platform 集群通常称为安装程序置备的基础架构集群和用户置备的基础架构集群。
两种类型的集群都具有以下特征：
- 默认提供无单点故障的高可用性基础架构
- 管理员可以控制要应用的更新内容和更新的时间
两种类型的集群都使用同一个安装程序来部署。安装程序生成的主要资产是用于 Bootstrap、master 和 worker 机器的 Ignition 配置文件。有了这三个配置和配置得当的基础架构，就能启动 OpenShift Container Platform 集群。
OpenShift Container Platform 安装程序使用一组目标和依赖项来管理集群安装。安装程序具有一组必须实现的目标，并且每个目标都有一组依赖项。因为每个目标仅关注其自己的依赖项，所以安装程序可以采取措施来并行实现多个目标。最终目标是正常运行的集群。通过满足依赖项而不是运行命令，安装程序能够识别和使用现有的组件，而不必运行命令来再次创建它们。
下图显示了安装目标和依赖项的子集：
图 1.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.8 集群中的每一 control plane 机器都必须使用 RHCOS，其中包括一个关键的首次启动置备工具，称为 Ignition。这一工具让集群能够配置机器。操作系统更新作为嵌入在容器镜像中的 Atomic OSTree 存储库交付，该镜像由 Operator 在整个集群中推广。实际的操作系统更改通过使用 rpm-ostree 在每台机器上作为原子操作原位进行。通过结合使用这些技术，OpenShift Container Platform 可以像管理集群上的任何其他应用程序一样管理操作系统，通过原位升级使整个平台保持最新状态。这些原位更新可以减轻运维团队的负担。
如果将 RHCOS 用作所有集群机器的操作系统，则集群将管理其组件和机器的所有方面，包括操作系统在内。因此，只有安装程序和 Machine Config Operator 才能更改机器。安装程序使用 Ignition 配置文件设置每台机器的确切状态，安装后则由 Machine Config Operator 完成对机器的更多更改，例如应用新证书或密钥等。
1.1.1. 安装过程
安装 OpenShift Container Platform 集群时，您可以从 OpenShift Cluster Manager 站点的适当 Infrastructure Provider 页面下载安装程序。此网站管理以下内容：
- 帐户的 REST API
- registry 令牌，这是用于获取所需组件的 pull secret
- 集群注册，它将集群身份信息与您的红帽帐户相关联，以方便收集使用情况指标
在 OpenShift Container Platform 4.8 中，安装程序是对一组资产执行一系列文件转换的 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 计算机器添加到集群中。
安装过程详细信息
由于在置备时集群中的每台机器都需要集群的相关信息，因此 OpenShift Container Platform 在初始配置期间会使用临时 Bootstrap 机器将所需的信息提供给持久 control plane。通过使用描述如何创建集群的 Ignition 配置文件进行启动。bootstrap 机器创建组成 control plane 的 control plane 机器（也称为 master 机器）。然后，control plane 机器创建计算（compute）机器。下图说明了这一过程：
图 1.2. 创建 bootstrap、control plane 和计算机器
集群机器初始化后，Bootstrap 机器将被销毁。所有集群都使用 Bootstrap 过程来初始化集群，但若您自己置备集群的基础架构，则必须手动完成许多步骤。
-
安装程序生成的 Ignition 配置文件包含在 24 小时后过期的证书，然后在过期时进行续订。如果在更新证书前关闭集群，且集群在 24 小时后重启，集群会自动恢复过期的证书。一个例外情况是，您需要手动批准待处理的
node-bootstrapper证书签名请求（CSR）来恢复 kubelet 证书。如需更多信息，请参阅从过期的 control plane 证书中恢复的文档。 - 建议您在生成 12 小时后使用 Ignition 配置文件，因为集群安装后 24 小时证书从 16 小时轮转至 22 小时。通过在 12 小时内使用 Ignition 配置文件，您可以避免在安装过程中运行证书更新时避免安装失败。
bootstrapp 集群涉及以下步骤：
- bootstrap 机器启动并开始托管 control plane 机器引导所需的远程资源。（如果自己配置基础架构，则需要人工干预）
- bootstrap 机器启动单节点 etcd 集群和一个临时 Kubernetes control plane。
- control plane 机器从 bootstrap 机器获取远程资源并完成启动。（如果自己配置基础架构，则需要人工干预）
- 临时 control plane 将生产环境的 control plane 调度到生产环境 control plane 机器。
- Cluster Version Operator（CVO）在线并安装 etcd Operator。etcd Operator 在所有 control plane 节点上扩展 etcd。
- 临时 control plane 关机，并将控制权交给生产环境 control plane。
- bootstrap 机器将 OpenShift Container Platform 组件注入生产环境 control plane。
- 安装程序关闭 bootstrap 机器。（如果自己配置基础架构，则需要人工干预）
- control plane 设置计算节点。
- control plane 以一组 Operator 的形式安装其他服务。
此 bootstrap 过程的结果是正在运行的 OpenShift Container Platform 集群。然后，集群下载并配置日常运作所需的其余组件，包括在受支持的环境中创建计算（compute）机器。
1.1.2. 安装后验证节点状态
当以下安装健康检查成功时，OpenShift Container Platform 安装会完成：
- 置备主机可以访问 OpenShift Container Platform Web 控制台。
- 所有 control plane 节点都已就绪。
- 所有集群 Operator 都可用。
安装完成后，负责 worker 节点的特定集群 Operator 会持续尝试置备所有 worker 节点。可能需要过些时间，所有 worker 节点都报告为 READY。对于在裸机上安装，请在对 worker 节点进行故障排除前至少等待 60 分钟。对于在所有其他平台上安装，请至少等待 40 分钟后再对 worker 节点进行故障排除。负责 worker 节点的集群 Operator 的 DEGRADED 状态取决于 Operator 自己的资源，而不是节点的状态。
安装完成后，您可以继续使用以下步骤监控集群中的节点状况。
先决条件
- 安装程序会在终端中成功解析。
流程
显示所有 worker 节点的状态：
$ oc get nodes
输出示例
NAME STATUS ROLES AGE VERSION example-compute1.example.com Ready worker 13m v1.21.6+bb8d50a example-compute2.example.com Ready worker 13m v1.21.6+bb8d50a example-compute4.example.com Ready worker 14m v1.21.6+bb8d50a example-control1.example.com Ready master 52m v1.21.6+bb8d50a example-control2.example.com Ready master 55m v1.21.6+bb8d50a example-control3.example.com Ready master 55m v1.21.6+bb8d50a
显示所有 worker 机器的阶段：
$ oc get machines -A
输出示例
NAMESPACE NAME PHASE TYPE REGION ZONE AGE openshift-machine-api example-zbbt6-master-0 Running 95m openshift-machine-api example-zbbt6-master-1 Running 95m openshift-machine-api example-zbbt6-master-2 Running 95m openshift-machine-api example-zbbt6-worker-0-25bhp Running 49m openshift-machine-api example-zbbt6-worker-0-8b4c2 Running 49m openshift-machine-api example-zbbt6-worker-0-jkbqt Running 49m openshift-machine-api example-zbbt6-worker-0-qrl5b Running 49m
安装范围
OpenShift Container Platform 安装程序的作用范围特意设计得比较狭窄。它旨在简化操作并确保成功。安装完成后，您可以完成更多的配置任务。
其他资源
- 如需了解有关 OpenShift Container Platform 配置资源的详细信息，请参阅可用的集群自定义。
