OpenShift Container Platform安装程序提供四种部署集群的方法,详情如下:
交互式:您可以使用基于Web的辅助安装程序部署集群。对于连接到互联网的网络集群,这是一种理想的方法。辅助安装程序是安装OpenShift Container Platform最简单的方法,它提供智能默认值,并在安装集群之前执行预检验证。它还提供RESTful API用于自动化和高级配置场景。
基于本地代理的:您可以使用面向断开连接的环境或受限网络的基于代理的安装程序在本地部署集群。它提供了辅助安装程序的许多好处,但是您必须首先下载并配置基于代理的安装程序。配置通过命令行界面完成。此方法非常适合断开连接的环境。
自动化的:您可以在安装程序预置的基础架构上部署集群。安装程序使用每个集群主机的底板管理控制器 (BMC) 进行预置。您可以在连接或断开连接的环境中部署集群。
完全控制:您可以在您准备和维护的基础架构上部署集群,这提供了最大的可定制性。您可以在连接或断开连接的环境中部署集群。
每种方法都部署具有以下特征的集群:
默认情况下可用的高可用性基础架构,没有单点故障。
管理员可以控制应用哪些更新以及何时应用。
您可以使用安装程序部署每种类型的集群。安装程序生成主要资产,例如引导程序、控制平面和计算机的Ignition配置文件。如果您正确配置了基础架构,则可以使用这三种机器配置启动OpenShift Container Platform集群。
OpenShift Container Platform安装程序使用一组目标和依赖项来管理集群安装。安装程序具有一组必须实现的目标,每个目标具有一组依赖项。因为每个目标只关心它自己的依赖项,所以安装程序可以并行地执行多个目标,最终目标是运行的集群。安装程序识别并使用现有组件,而不是再次运行命令来创建它们,因为程序满足了依赖关系。
安装后,每个集群机器都使用Red Hat Enterprise Linux CoreOS (RHCOS) 作为操作系统。RHCOS是Red Hat Enterprise Linux (RHEL) 的不可变容器主机版本,具有默认启用SELinux的RHEL内核。RHCOS包含`kubelet`(Kubernetes节点代理)和CRI-O容器运行时(针对Kubernetes进行了优化)。
每个 OpenShift Container Platform 4.17 集群中的控制平面机器都必须使用 RHCOS,其中包含一个名为 Ignition 的关键首次启动配置工具。此工具使集群能够配置机器。操作系统更新作为可引导容器镜像交付,使用**OSTree**作为后端,由机器配置操作员在集群中部署。实际的操作系统更改通过使用**rpm-ostree**作为原子操作在每台机器上就地进行。这些技术共同使 OpenShift Container Platform 能够像管理集群上的任何其他应用程序一样管理操作系统,通过就地升级来保持整个平台最新。这些就地更新可以减轻运维团队的负担。
如果将 RHCOS 用作所有集群机器的操作系统,则集群将管理其组件和机器的所有方面,包括操作系统。因此,只有安装程序和机器配置操作员才能更改机器。安装程序使用 Ignition 配置文件来设置每台机器的精确状态,而机器配置操作员在安装后完成对机器的更多更改,例如应用新的证书或密钥。
在 OpenShift Container Platform 4.17 中,您可以安装一个使用安装程序预配基础架构的集群,这些平台包括:
Amazon Web Services (AWS)
裸机
Google Cloud Platform (GCP)
IBM Cloud®
Microsoft Azure
Microsoft Azure Stack Hub
Nutanix
Red Hat OpenStack Platform (RHOSP)
最新的 OpenShift Container Platform 版本同时支持最新的 RHOSP 长期支持版本和中间版本。有关完整的 RHOSP 版本兼容性,请参阅RHOSP 上的 OpenShift Container Platform 支持矩阵。
VMware vSphere
对于这些集群,所有机器(包括运行安装过程的计算机)都必须具有直接的互联网访问权限,才能提取平台容器的镜像并向 Red Hat 提供遥测数据。
安装后,不支持以下更改:
|
在 OpenShift Container Platform 4.17 中,您可以安装一个使用用户预配基础架构的集群,这些平台包括:
AWS
Azure
Azure Stack Hub
裸机
GCP
IBM Power®
IBM Z® 或 IBM® LinuxONE
RHOSP
最新的 OpenShift Container Platform 版本同时支持最新的 RHOSP 长期支持版本和中间版本。有关完整的 RHOSP 版本兼容性,请参阅RHOSP 上的 OpenShift Container Platform 支持矩阵。
VMware Cloud on AWS
VMware vSphere
根据平台支持的案例,您可以在用户预配的基础架构上执行安装,以便您可以运行具有完全互联网访问权限的机器,将集群置于代理之后,或执行脱机安装。
在脱机安装中,您可以下载安装集群所需的镜像,将它们放在镜像注册表中,并使用这些数据来安装集群。虽然您需要互联网访问权限才能提取平台容器的镜像,但在 vSphere 或裸机基础架构上的脱机安装中,您的集群机器不需要直接访问互联网。
OpenShift Container Platform 4.x 测试集成页面包含有关不同平台集成测试的详细信息。
除了辅助安装程序外,安装 OpenShift Container Platform 集群时,必须从 OpenShift 集群管理器混合云控制台上的相应集群类型页面下载安装程序。此控制台管理:
帐户的 REST API。
注册表令牌,即用于获取所需组件的拉取密钥。
集群注册,它将集群标识与您的 Red Hat 帐户关联起来,以方便收集使用情况指标。
在 OpenShift Container Platform 4.17 中,安装程序是一个 Go 二进制文件,它对一组资产执行一系列文件转换。与安装程序交互的方式取决于您的安装类型。请考虑以下安装用例:
要使用辅助安装程序部署集群,必须使用辅助安装程序配置集群设置。无需下载和配置安装程序。完成集群配置设置后,下载一个发现 ISO,然后使用该镜像启动集群机器。您可以使用辅助安装程序在 Nutanix、vSphere 和裸机上安装集群,并实现完全集成,也可以在其他平台上安装,但没有集成。如果在裸机上安装,则必须提供所有集群基础设施和资源,包括网络、负载均衡、存储和各个集群机器。
要使用基于代理的安装程序部署集群,您可以首先下载基于代理的安装程序。然后,您可以配置集群并生成发现镜像。使用发现镜像启动集群机器,该镜像将安装一个代理,该代理与安装程序通信并为您处理配置,而不是您自己与安装程序交互或自行设置配置器机器。您必须提供所有集群基础设施和资源,包括网络、负载均衡、存储和各个集群机器。这种方法非常适合脱机环境。
对于安装程序预配基础架构的集群,您将基础架构引导和配置委托给安装程序,而不是自己进行。安装程序将创建支持集群所需的所有网络、机器和操作系统,除非您在裸机上安装。如果在裸机上安装,则必须提供所有集群基础设施和资源,包括引导机器、网络、负载均衡、存储和各个集群机器。
如果您预配和管理集群的基础架构,则必须提供所有集群基础设施和资源,包括引导机器、网络、负载均衡、存储和各个集群机器。
对于安装程序,程序在安装过程中使用三组文件:名为install-config.yaml
的安装配置文件、Kubernetes 清单和机器类型的 Ignition 配置文件。
您可以在安装过程中修改 Kubernetes 和控制底层 RHCOS 操作系统的 Ignition 配置文件。但是,没有可用的验证来确认您对这些对象所做任何修改的适用性。如果修改这些对象,可能会导致集群无法正常工作。由于存在此风险,除非您遵循已记录的过程或 Red Hat 支持人员指示您这样做,否则不支持修改 Kubernetes 和 Ignition 配置文件。 |
安装配置文件将转换为 Kubernetes 清单,然后将清单打包到 Ignition 配置文件中。安装程序使用这些 Ignition 配置文件来创建集群。
运行安装程序时,所有安装配置文件都将被修剪,因此请务必备份所有想要再次使用的配置文件。
您无法修改安装过程中设置的参数,但可以在安装后修改许多集群属性。 |
使用Assisted Installer进行安装涉及使用基于 Web 的用户界面或 RESTful API 交互式地创建集群配置。除非您在用户界面或 API 中更改它们,否则 Assisted Installer 用户界面会提示您输入所需的值,并为其余参数提供合理的默认值。Assisted Installer 会生成一个发现镜像,您可以下载并使用它来启动集群机器。该镜像会安装 RHCOS 和一个代理,并且该代理会为您处理预配工作。您可以使用 Assisted Installer 和 Nutanix、vSphere 和裸机上的完全集成来安装 OpenShift Container Platform。此外,您还可以在其他平台上使用 Assisted Installer 安装 OpenShift Container Platform,而无需集成。
OpenShift Container Platform 管理集群的所有方面,包括操作系统本身。每台机器都使用引用其加入的集群中托管的资源的配置启动。此配置允许集群在应用更新时自行管理。
如果可能,请使用 Assisted Installer 功能,以避免必须下载和配置基于代理的安装程序。
基于代理的安装类似于使用 Assisted Installer,不同之处在于您必须首先下载并安装基于代理的安装程序。当您需要 Assisted Installer 的便利性,但需要在断开连接的环境中安装集群时,基于代理的安装非常有用。
如果可能,请使用基于代理的安装功能,以避免必须创建具有引导 VM 的预配程序机器,然后预配和维护集群基础设施。
默认安装类型使用安装程序预配的基础设施。默认情况下,安装程序充当安装向导,提示您输入它无法自行确定的值,并为其余参数提供合理的默认值。您还可以自定义安装过程以支持高级基础设施场景。安装程序会为集群预配底层基础设施。
您可以安装标准集群或自定义集群。对于标准集群,您只需提供安装集群所需的最低限度详细信息。对于自定义集群,您可以指定有关平台的更多详细信息,例如控制平面使用的机器数量、集群部署的虚拟机类型或 Kubernetes 服务网络的 CIDR 范围。
如果可能,请使用此功能以避免必须预配和维护集群基础设施。在所有其他环境中,您都使用安装程序来生成预配集群基础设施所需的资产。
对于安装程序预配的基础设施集群,OpenShift Container Platform 管理集群的所有方面,包括操作系统本身。每台机器都使用引用其加入的集群中托管的资源的配置启动。此配置允许集群在应用更新时自行管理。
您也可以在您提供的基础设施上安装 OpenShift Container Platform。您可以使用安装程序生成预配集群基础设施所需的资产,创建集群基础设施,然后将集群部署到您提供的基础设施。
如果您不使用安装程序预配的基础设施,则必须自行管理和维护集群资源。以下列表详细介绍了其中一些自行管理的资源
构成集群的控制平面和计算机器的底层基础设施
负载均衡器
集群网络,包括 DNS 记录和所需的子网
集群基础设施和应用程序的存储
如果您的集群使用用户预配的基础设施,您可以选择向集群添加 RHEL 计算机器。
预配集群时,集群中的每台机器都需要有关集群的信息。OpenShift Container Platform 在初始配置期间使用临时引导机器,向永久控制平面提供所需的信息。临时引导机器使用描述如何创建集群的 Ignition 配置文件启动。引导机器创建构成控制平面的控制平面机器。然后,控制平面机器创建计算机器,也称为工作机器。下图说明了此过程
集群机器初始化后,引导机器将被销毁。所有集群都使用引导过程来初始化集群,但是如果您预配集群的基础设施,则必须手动完成许多步骤。
|
引导集群涉及以下步骤
引导机器启动并开始托管控制平面机器启动所需的远程资源。如果您预配基础设施,此步骤需要手动干预。
引导机器启动单节点 etcd 集群和临时 Kubernetes 控制平面。
控制平面机器从引导机器获取远程资源并完成启动。如果您预配基础设施,此步骤需要手动干预。
临时控制平面将生产控制平面调度到生产控制平面机器。
集群版本运算符 (CVO)上线并安装 etcd 运算符。etcd 运算符会将 etcd 扩展到所有控制平面节点。
临时控制平面关闭并控制权移交给生产控制平面。
引导机器将 OpenShift Container Platform 组件注入生产控制平面。
安装程序关闭引导机器。如果您预配基础设施,此步骤需要手动干预。
控制平面设置计算节点。
控制平面以一组运算符的形式安装其他服务。
此引导过程的结果是一个正在运行的 OpenShift Container Platform 集群。然后,集群将下载并配置日常运营所需的其余组件,包括在受支持的环境中创建计算机器。
OpenShift Container Platform 安装程序的范围有意限定得很窄。这旨在简化安装流程并确保安装成功。您可以在安装完成后完成更多配置任务。
有关 OpenShift Container Platform 配置资源的详细信息,请参阅 可用的集群自定义项。
OpenShift 更新服务 (OSUS) 为 OpenShift Container Platform(包括 Red Hat Enterprise Linux CoreOS (RHCOS))提供更新建议。它提供一个图表或示意图,其中包含组件 Operator 的顶点以及连接它们的边。图表中的边显示您可以安全更新到的版本。顶点是更新负载,指定托管集群组件的目标状态。
集群中的集群版本 Operator (CVO) 会检查 OpenShift 更新服务,以查看基于当前组件版本和图表中信息的有效更新和更新路径。当您请求更新时,CVO 使用相应的发布镜像来更新您的集群。发布工件作为容器镜像托管在 Quay 上。
为了允许 OpenShift 更新服务仅提供兼容的更新,发布验证流水线驱动自动化。每个发布工件都经过验证,以确保其与支持的云平台和系统架构以及其他组件包兼容。流水线确认发布的适用性后,OpenShift 更新服务会通知您它已可用。
OpenShift 更新服务将显示当前集群的所有推荐更新。如果 OpenShift 更新服务不推荐更新路径,可能是因为与更新路径相关的已知问题,例如不兼容性或可用性问题。 |
在持续更新模式下,会运行两个控制器。第一个控制器持续更新负载清单,将清单应用于集群,并输出 Operator 的受控推出状态,以指示它们是可用、正在升级还是失败。第二个控制器轮询 OpenShift 更新服务以确定是否有可用的更新。
仅支持更新到较新版本。不支持将集群还原或回滚到以前的版本。如果更新失败,请联系 Red Hat 支持。 |
在更新过程中,机器配置 Operator (MCO) 会将新配置应用于您的集群机器。MCO 会隔离机器配置池中 maxUnavailable
字段指定的节点数量,并将它们标记为不可用。默认情况下,此值设置为 1
。MCO 会根据 topology.kubernetes.io/zone
标签按字母顺序按区域更新受影响的节点。如果某个区域有多个节点,则首先更新最旧的节点。对于不使用区域的节点(例如在裸机部署中),节点会按年龄更新,最旧的节点首先更新。MCO 每次更新机器配置池中 maxUnavailable
字段指定的节点数量。然后,MCO 应用新配置并重新引导机器。
OpenShift Container Platform 中所有机器配置池的 |
如果您使用 Red Hat Enterprise Linux (RHEL) 机器作为工作节点,则 MCO 不会更新 kubelet,因为您必须首先更新机器上的 OpenShift API。
使用应用于旧 kubelet 的新版本规范,RHEL 机器无法返回到 Ready
状态。在机器可用之前,您无法完成更新。但是,最大不可用节点数已设置,以确保在一定数量的机器停用情况下,集群的正常运行可以继续。
OpenShift 更新服务由一个 Operator 和一个或多个应用程序实例组成。
Operator 的管理状态决定 Operator 是否正在积极管理集群中其相关组件的资源(按设计)。如果 Operator 设置为非托管状态,它不会响应配置更改,也不会接收更新。
虽然这在非生产集群或调试过程中可能很有用,但处于非托管状态的 Operator 不受支持,集群管理员承担各个组件配置和升级的全部控制。
可以使用以下方法将 Operator 设置为非托管状态
单个 Operator 配置
各个 Operator 在其配置中都有一个 managementState
参数。可以根据 Operator 的不同,通过不同的方式访问它。例如,Red Hat OpenShift Logging Operator 通过修改它管理的自定义资源 (CR) 来实现此目的,而 Cluster Samples Operator 使用集群范围的配置资源。
将 managementState
参数更改为 Unmanaged
表示 Operator 不会积极管理其资源,并且不会采取与相关组件相关的任何操作。某些 Operator 可能不支持此管理状态,因为它可能会损坏集群并需要手动恢复。
将各个 Operator 更改为 |
集群版本 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 覆盖会使整个集群处于不受支持的状态。必须在移除任何覆盖后重现报告的问题,才能继续进行支持。 |