第 4 章 使用 RHACM 和 SiteConfig 资源安装受管集群
您可以使用辅助服务以及启用了 core-reduction 技术的 GitOps 插件策略生成器，以扩展 Red Hat Advanced Cluster Management (RHACM) 来大规模置备 OpenShift Container Platform 集群。GitOps Zero Touch Provisioning (ZTP) 管道执行集群安装。GitOps ZTP 可以在断开连接的环境中使用。
使用 PolicyGenTemplate CR 管理和部署到受管集群的策略将在即将发布的 OpenShift Container Platform 发行版本中弃用。使用 Red Hat Advanced Cluster Management (RHACM) 和 PolicyGenerator CR 提供了等效的和改进的功能。
有关 PolicyGenerator 资源的更多信息，请参阅 RHACM 策略生成器 文档。
4.1. GitOps ZTP 和 Topology Aware Lifecycle Manager
GitOps Zero Touch Provisioning (ZTP) 从 Git 中存储的清单生成安装和配置 CR。这些工件应用到一个中央化的 hub 集群，其中 Red Hat Advanced Cluster Management (RHACM)、辅助服务和 Topology Aware Lifecycle Manager (TALM) 使用 CR 来安装和配置受管集群。GitOps ZTP 管道的配置阶段使用 TALM 将配置 CR 的应用程序编排到集群。GitOps ZTP 和 TALM 之间有几个关键集成点。
- 通知策略
-
默认情况下，GitOps ZTP 创建所有带有
inform的补救操作的策略。这些策略会导致 RHACM 报告与策略相关的集群合规性状态，但不会应用所需的配置。在 GitOps ZTP 过程中，在 OpenShift 安装后，TALM 步骤通过创建的inform策略，并在目标受管集群中强制实施它们。这会将配置应用到受管集群。在集群生命周期的 GitOps ZTP 阶段之外，这允许您在不立即将这些更改部署到受影响的受管集群的情况下更改策略。您可以使用 TALM 控制时间和修复的集群集合。 - 自动创建 ClusterGroupUpgrade CR
要自动执行新部署的集群的初始配置，TALM 会监控 hub 集群上所有
ManagedClusterCR 的状态。任何未应用ztp-done标签的ManagedClusterCR，包括新创建的ManagedClusterCR，会导致 TALM 自动创建一个具有以下特征的ClusterGroupUpgradeCR：-
在
ztp-install命名空间中创建并启用ClusterGroupUpgradeCR。 -
ClusterGroupUpgradeCR 的名称与ManagedClusterCR 的名称相同。 -
集群选择器仅包括与该
ManagedClusterCR 关联的集群。 -
受管策略集合包含 RHACM 在
ClusterGroupUpgrade创建时绑定到集群的所有策略。 - 禁用预缓存。
- 超时设置为 4 小时（240 分钟）。
启用的
ClusterGroupUpgrade的自动创建可确保初始零接触集群部署继续进行，而无需用户干预。另外，为任何没有ztp-done标签的ManagedCluster自动创建一个ClusterGroupUpgradeCR，可以通过删除集群的ClusterGroupUpgradeCR 来重启失败的 GitOps ZTP 安装。-
在
- Waves
从
PolicyGenerator或PolicyGentemplateCR 生成的每个策略都包含一个ztp-deploy-wave注解。此注解基于来自每个 CR 的同一注解，该注解包含在该策略中。wave 注解用于对自动生成的ClusterGroupUpgradeCR 中的策略进行排序。wave 注解没有用于自动生成的ClusterGroupUpgradeCR。注意同一策略中的所有 CR 都必须具有
ztp-deploy-wave注解的设置。可以在PolicyGenerator或PolicyGentemplate中覆盖每个 CR 的此注解的默认值。源 CR 中的 wave 注解用来决定和设置策略 wave 注解。此注解已从每个构建 CR 中删除，该 CR 在运行时包含在生成的策略中。TALM 按照 wave 注解指定的顺序应用配置策略。在移至下一个策略前，TALM 会等待每个策略兼容。确保每个 CR 的 wave 注解考虑要应用到集群的任何 CR 的先决条件。例如，必须在 Operator 配置之前或同时安装 Operator。同样，Operator 的
CatalogSource必须在 Operator Subscription 之前或同时安装 wave。每个 CR 的默认 wave 值会考虑这些先决条件。多个 CR 和策略可以共享相同的 wave 编号。拥有较少的策略可缩短部署速度并降低 CPU 用量。将多个 CR 分组到相对较少的waves 是最佳实践方案。
要检查每个源 CR 中的默认 wave 值，请针对从 ztp-site-generate 容器镜像中提取的 out/source-crs 目录运行以下命令：
$ grep -r "ztp-deploy-wave" out/source-crs
- 阶段标签
ClusterGroupUpgradeCR 会被自动创建，并包含在 GitOps ZTP 进程开始和结尾使用标签为ManagedClusterCR 的说明。当 GitOps ZTP 配置安装后启动时，
ManagedCluster会应用ztp-running标签。当所有策略都修复至集群并完全合规时，这些指令会导致 TALM 删除ztp-running标签并应用ztp-done标签。对于使用
informDuValidator策略的部署，当集群完全准备好部署应用程序时，会应用ztp-done标签。这包括 GitOps ZTP 应用的配置 CR 的所有协调并产生影响。ztp-done标签会影响 TALM 创建自动ClusterGroupUpgradeCR。不要在集群初始 GitOps ZTP 安装后操作此标签。- 链接的 CR
-
自动创建的
ClusterGroupUpgradeCR 将所有者引用设置为派生于ManagedCluster的 ManagedCluster。此引用可确保删除ManagedClusterCR 会导致ClusterGroupUpgrade的实例以及任何支持的资源被删除。
