19.3. 使用 RHACM 和 SiteConfig 资源安装受管集群
您可以使用辅助服务以及启用了 core-reduction 技术的 GitOps 插件策略生成器,以扩展 Red Hat Advanced Cluster Management (RHACM) 来大规模置备 OpenShift Container Platform 集群。ZTP 管道执行集群安装。ZTP 可以在断开连接的环境中使用。
19.3.1. GitOps ZTP 和 Topology Aware Lifecycle Manager
GitOps 零涉及置备(ZTP)从存储在 Git 中的清单生成安装和配置 CR。这些工件应用到一个中央化的 hub 集群,其中 Red Hat Advanced Cluster Management (RHACM)、辅助服务和 Topology Aware Lifecycle Manager (TALM) 使用 CR 来安装和配置受管集群。ZTP 管道的配置阶段使用 TALM 将配置 CR 的应用程序编排到集群。GitOps ZTP 和 TALM 之间有几个关键集成点。
- 通知策略
-
默认情况下,GitOps ZTP 创建所有带有
inform
的补救操作的策略。这些策略会导致 RHACM 报告与策略相关的集群合规性状态,但不会应用所需的配置。在 ZTP 过程中,在 OpenShift 安装后,TALM 步骤通过创建的inform
策略,并在目标受管集群中强制实施它们。这会将配置应用到受管集群。在集群生命周期的 ZTP 阶段之外,这允许您在不立即将这些更改部署到受影响的受管集群的情况下更改策略。您可以使用 TALM 控制时间和修复的集群集合。 - 自动创建 ClusterGroupUpgrade CR
要自动执行新部署的集群的初始配置,TALM 会监控 hub 集群上所有
ManagedCluster
CR 的状态。任何未应用ztp-done
标签的ManagedCluster
CR,包括新创建的ManagedCluster
CR,会导致 TALM 自动创建一个具有以下特征的ClusterGroupUpgrade
CR:-
在
ztp-install
命名空间中创建并启用ClusterGroupUpgrade
CR。 -
ClusterGroupUpgrade
CR 的名称与ManagedCluster
CR 的名称相同。 -
集群选择器仅包括与该
ManagedCluster
CR 关联的集群。 -
受管策略集合包含 RHACM 在
ClusterGroupUpgrade
创建时绑定到集群的所有策略。 - 禁用预缓存。
- 超时设置为 4 小时(240 分钟)。
启用的
ClusterGroupUpgrade
的自动创建可确保初始零接触集群部署继续进行,而无需用户干预。另外,对任何没有ztp-done
标签的ManagedCluster
自动创建一个ClusterGroupUpgrade
CR,会允许失败的 ZTP 安装重新启动(删除集群的ClusterGroupUpgrade
CR)。-
在
- Waves
从
PolicyGenTemplate
CR 生成的每个策略都包含一个ztp-deploy-wave
注解。此注解基于来自每个 CR 的同一注解,该注解包含在该策略中。wave 注解用于对自动生成的ClusterGroupUpgrade
CR 中的策略进行排序。wave 注解没有用于自动生成的ClusterGroupUpgrade
CR。注意同一策略中的所有 CR 都必须具有
ztp-deploy-wave
注解的设置。在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
- 阶段标签
ClusterGroupUpgrade
CR 会被自动创建,并包含在 ZTP 进程开始和结尾使用标签为ManagedCluster
CR 的说明。当 ZTP 配置安装后启动时,
ManagedCluster
会应用ztp-running
标签。当所有策略都修复至集群并完全合规时,这些指令会导致 TALM 删除ztp-running
标签并应用ztp-done
标签。对于使用
informDuValidator
策略的部署,当集群完全准备好部署应用程序时,会应用ztp-done
标签。这包括 ZTP 应用的配置 CR 的所有协调并产生影响。ztp-done
标签会影响 TALM 创建自动ClusterGroupUpgrade
CR。不要在集群初始 ZTP 安装后操作此标签。- 链接的 CR
-
自动创建的
ClusterGroupUpgrade
CR 将所有者引用设置为派生于ManagedCluster
的 ManagedCluster。此引用可确保删除ManagedCluster
CR 会导致ClusterGroupUpgrade
的实例以及任何支持的资源被删除。
19.3.2. 使用 ZTP 部署受管集群概述
Red Hat Advanced Cluster Management(RHACM)利用零接触置备(ZTP)来部署单节点 OpenShift Container Platform 集群、三节点集群和标准集群。您可以在 Git 存储库中将站点配置数据作为 OpenShift Container Platform 自定义资源 (CR) 进行管理。ZTP 使用声明性 GitOps 方法进行开发一次,部署任意位置模型来部署受管集群。
集群部署包括:
- 在空白服务器上安装主机操作系统 (RHCOS)
- 部署 OpenShift Container Platform
- 创建集群策略和站点订阅
- 为服务器操作系统进行必要的网络配置
- 部署配置集 Operator 并执行任何所需的软件相关配置,如性能配置集、PTP 和 SR-IOV
受管站点安装过程概述
在 hub 集群中应用受管站点自定义资源 (CR) 后,会自动执行以下操作:
- 在目标主机上生成并启动发现镜像 ISO 文件。
- 当 ISO 文件成功在目标主机上引导时,它会将主机硬件信息报告给 RHACM。
- 在所有主机被发现后,会安装 OpenShift Container Platform。
-
当 OpenShift Container Platform 完成安装后,hub 在目标集群上安装
klusterlet
服务。 - 请求的附加组件服务安装在目标集群中。
当在 hub 集群上创建受管集群的 Agent
CR 时,发现镜像 ISO 过程已完成。
目标裸机主机必须满足 vDU 应用程序工作负载的推荐单节点 OpenShift 集群配置中列出的网络、固件和硬件要求。
19.3.3. 创建受管裸机主机 secret
将受管裸机主机所需的 Secret
自定义资源 (CR) 添加到 hub 集群。您需要 ZTP 管道的 secret 来访问 Baseboard Management Controller (BMC) 和支持的安装程序服务的 secret,以便从 registry 中拉取集群安装镜像。
secret 按名称从 SiteConfig
CR 引用。命名空间必须与 SiteConfig
命名空间匹配。
流程
创建一个 YAML secret 文件,其中包含主机 Baseboard Management Controller (BMC) 和安装 OpenShift 和所有附加组件集群 Operator 所需的凭证:
将以下 YAML 保存为文件
example-sno-secret.yaml
:apiVersion: v1 kind: Secret metadata: name: example-sno-bmc-secret namespace: example-sno 1 data: 2 password: <base64_password> username: <base64_username> type: Opaque --- apiVersion: v1 kind: Secret metadata: name: pull-secret namespace: example-sno 3 data: .dockerconfigjson: <pull_secret> 4 type: kubernetes.io/dockerconfigjson
-
将到
example-sno-secret.yaml
的相对路径添加用于安装集群的kustomization.yaml
文件中。
19.3.4. 使用 SiteConfig 和 ZTP 部署受管集群
使用以下步骤创建 SiteConfig
自定义资源 (CR) 和相关文件,并启动零接触置备 (ZTP) 集群部署。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。 - 配置了 hub 集群来生成所需的安装和策略 CR。
您创建了 Git 存储库,用于管理自定义站点配置数据。存储库必须可从 hub 集群访问,且必须将其配置为 ArgoCD 应用程序的源存储库。如需更多信息,请参阅"准备 GitOps ZTP 站点配置存储库"。
注意在创建源存储库时,请确保使用从
ztp-site-generate
容器中提取的argocd/deployment/argocd-openshift-gitops-patch.json
patch-file 来修补 ArgoCD 应用程序。请参阅"使用 ArgoCD 配置 hub 集群"。要准备好置备受管集群,每个裸机主机都需要以下内容:
- 网络连接
- 您的网络需要 DNS。受管集群主机应该可从 hub 集群访问。确保 hub 集群和受管集群主机之间存在第 3 层连接。
- Baseboard Management Controller (BMC) 详情
-
ZTP 使用 BMC 用户名和密码详情来在集群安装过程中连接到 BMC。GitOps ZTP 插件根据站点 Git 仓库中的
SiteConfig
CR 管理 hub 集群上的ManagedCluster
CR。您可以手动为每个主机创建单独的BMCSecret
CR。
流程
在 hub 集群中创建所需的受管集群 secret。这些资源必须位于名称与集群名称匹配的命名空间中。例如,在
out/argocd/example/siteconfig/example-sno.yaml
中,集群名称和命名空间是example-sno
。运行以下命令来导出集群命名空间:
$ export CLUSTERNS=example-sno
创建命名空间:
$ oc create namespace $CLUSTERNS
为受管集群创建 pull secret 和 BMC
Secret
CR。pull secret 必须包含安装 OpenShift Container Platform 和其他需要安装的 Operator 所需的所有凭证。如需更多信息,请参阅"创建受管裸机主机 secret"。注意secret 根据名称从
SiteConfig
自定义资源 (CR) 引用。命名空间必须与SiteConfig
命名空间匹配。在 Git 存储库本地克隆中为集群创建一个
SiteConfig
CR:从
out/argocd/example/siteconfig/
文件夹中选择适合您的 CR 示例。文件夹中包含单一节点、三节点和标准集群的示例文件:-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
更改示例文件中的集群和主机详情,以匹配您想要的集群类型。例如:
单节点 OpenShift 集群 SiteConfig CR 示例
apiVersion: ran.openshift.io/v1 kind: SiteConfig metadata: name: "<site_name>" namespace: "<site_name>" spec: baseDomain: "example.com" pullSecretRef: name: "assisted-deployment-pull-secret" 1 clusterImageSetNameRef: "openshift-4.10" 2 sshPublicKey: "ssh-rsa AAAA..." 3 clusters: - clusterName: "<site_name>" networkType: "OVNKubernetes" clusterLabels: 4 common: true group-du-sno: "" sites : "<site_name>" clusterNetwork: - cidr: 1001:1::/48 hostPrefix: 64 machineNetwork: - cidr: 1111:2222:3333:4444::/64 serviceNetwork: - 1001:2::/112 additionalNTPSources: - 1111:2222:3333:4444::2 #crTemplates: # KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5 nodes: - hostName: "example-node.example.com" 6 role: "master" #biosConfigRef: # filePath: "example-hw.profile" 7 bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8 bmcCredentialsName: name: "bmh-secret" 9 bootMACAddress: "AA:BB:CC:DD:EE:11" bootMode: "UEFI" 10 rootDeviceHints: wwn: "0x11111000000asd123" cpuset: "0-1,52-53" nodeNetwork: 11 interfaces: - name: eno1 macAddress: "AA:BB:CC:DD:EE:11" config: interfaces: - name: eno1 type: ethernet state: up ipv4: enabled: false ipv6: 12 enabled: true address: - ip: 1111:2222:3333:4444::aaaa:1 prefix-length: 64 dns-resolver: config: search: - example.com server: - 1111:2222:3333:4444::2 routes: config: - destination: ::/0 next-hop-interface: eno1 next-hop-address: 1111:2222:3333:4444::1 table-id: 254
- 1
- 使用与
SiteConfig
CR 相同的命名空间创建assisted-deployment-pull-secret
CR。 - 2
clusterImageSetNameRef
定义 hub 集群中可用的镜像集。要查看 hub 集群上支持的版本列表,请运行oc get clusterimagesets
。- 3
- 配置用于访问集群的 SSH 公钥。
- 4
- 集群标签必须与您定义的
PolicyGenTemplate
CR 中的bindingRules
字段对应。例如,policygentemplates/common-ranGen.yaml
应用到所有带有common: true
设置的集群,policygentemplates/group-du-sno-ranGen.yaml
应用到所有带有group-du-sno: ""
设置的所有集群。 - 5
- 可选的。
KlusterletAddonConfig
下的 CR specifed 用于覆盖为集群创建的默认KlusterletAddonConfig
。 - 6
- 对于单节点部署,请定义一个主机。对于三节点部署,请定义三个主机。对于标准部署,使用
role: master
定义三个主机,使用role: worker
定义两个或更多主机。 - 7
- 可选的。使用
biosConfigRef
为主机配置所需的固件。 - 8
- 适用于所有集群类型。指定 BMC 地址。
- 9
- 创建指定 BMC 凭证的
bmh-secret
CR。使用与SiteConfig
CR 相同的命名空间。 - 10
- 使用
UEFISecureBoot
在主机上启用安全引导。 - 11
- 指定节点的网络设置。
- 12
- 配置主机的 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群,特定于节点的 API 和 Ingress IP 应该相同。
注意有关 BMC 寻址的更多信息,请参阅"添加资源"部分。
-
您可以在
out/argocd/extra-manifest
中检查默认的 extra-manifestMachineConfig
CR。它在安装时会自动应用到集群。 -
可选: 要在置备的集群中置备额外的安装清单,请在 Git 存储库中创建一个目录,如
sno-extra-manifest/
,并将自定义清单 CR 添加到这个目录中。如果您的SiteConfig.yaml
在extraManifestPath
字段中引用这个目录,则这个引用目录中的所有 CR 都会被附加到默认的额外的清单集合中。
-
在
kustomization.yaml
文件中将SiteConfig
CR 添加到generators
部分中 ,类似于out/argocd/example/siteconfig/kustomization.yaml
中显示的示例。 在 Git 存储库中提交
SiteConfig
CR 及关联的kustomization.yaml
更改并推送更改。ArgoCD 管道检测到更改并开始受管集群部署。
19.3.5. 监控受管集群安装进度
ArgoCD 管道使用 SiteConfig
CR 生成集群配置 CR,并将其与 hub 集群同步。您可以在 ArgoCD 仪表板中监控此同步的进度。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
流程
同步完成后,安装通常会按如下方式进行:
Assisted Service Operator 会在集群中安装 OpenShift Container Platform。您可以运行以下命令来从 RHACM 仪表板或命令行监控集群安装进度:
导出集群名称:
$ export CLUSTER=<clusterName>
查询受管集群的
AgentClusterInstall
CR:$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
获取集群的安装事件:
$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
19.3.6. 通过验证安装 CR 对 GitOps ZTP 进行故障排除
ArgoCD 管道使用 SiteConfig
和 PolicyGenTemplate
自定义资源 (CR) 生成集群配置 CR 和 Red Hat Advanced Cluster Management (RHACM) 策略。使用以下步骤对此过程中可能出现的问题进行故障排除。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
流程
您可以使用以下命令检查安装 CR 是否已创建:
$ oc get AgentClusterInstall -n <cluster_name>
如果没有返回对象,请使用以下步骤对从
SiteConfig
文件到安装 CR 的 ArgoCD 管道流进行故障排除。验证
ManagedCluster
CR 是否使用 hub 集群上的SiteConfig
CR 生成:$ oc get managedcluster
如果缺少
ManagedCluster
,请检查clusters
应用程序是否将 Git 存储库中的文件与 hub 集群同步:$ oc describe -n openshift-gitops application clusters
检查
Status.Conditions
字段以查看受管集群的错误日志。例如,在SiteConfig
CR 中为extraManifestPath:
设置无效的值会引发以下错误:Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1 Type: ComparisonError
检查
Status.Sync
字段。如果有日志错误,Status.Sync
字段可能会指示Unknown
错误:Status: Sync: Compared To: Destination: Namespace: clusters-sub Server: https://kubernetes.default.svc Source: Path: sites-config Repo URL: https://git.com/ran-sites/siteconfigs/.git Target Revision: master Status: Unknown
19.3.7. 从 ZTP 管道中删除受管集群站点
您可以从 ZTP 管道中删除受管站点以及关联的安装和配置策略 CR。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
过程
通过从
kustomization.yaml
文件中删除关联的SiteConfig
和PolicyGenTemplate
文件来删除站点和相关 CR。当您再次运行 ZTP 管道时,生成的 CR 将被删除。
-
可选: 如果要永久删除站点,您还应从 Git 仓库中删除
SiteConfig
和特定站点的PolicyGenTemplate
文件。 -
可选:如果要临时删除站点,例如在重新部署站点时,可以保留 Git 存储库中的
SiteConfig
和特定站点的PolicyGenTemplate
CR。
从 Git 仓库中删除 SiteConfig
文件后,如果对应的集群一直处于 detach 过程中,请检查 hub 集群上的 Red Hat Advanced Cluster Management (RHACM),以了解有关清理分离集群的信息。
其他资源
- 有关删除集群的详情,请参考从管理中删除集群。
19.3.8. 从 ZTP 管道中删除过时的内容
如果对 PolicyGenTemplate
配置的更改会导致过时的策略,例如,如果您重命名策略,请使用以下步骤删除过时的策略。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
流程
-
从 Git 存储库中删除受影响的
PolicyGenTemplate
文件,提交并推送到远程存储库。 - 等待更改通过应用程序同步,并将受影响的策略从 hub 集群中删除。
将更新的
PolicyGenTemplate
文件重新添加到 Git 存储库,然后提交并推送到远程存储库。注意从 Git 仓库中删除零接触置备 (ZTP) 策略,因此也会从 hub 集群中删除它们,不会影响受管集群的配置。由该策略管理的策略和 CR 保留在受管集群上。
可选:作为替代方案,在修改了导致过时策略的
PolicyGenTemplate
CR 后,您可以手动从 hub 集群中删除这些策略。您可以使用 Governance 选项卡或运行以下命令来从 RHACM 控制台删除策略:$ oc delete policy -n <namespace> <policy_name>
19.3.9. 弃用 ZTP 管道
您可以删除 ArgoCD 管道和所有生成的 ZTP 工件。
先决条件
-
已安装 OpenShift CLI(
oc
)。 -
已以具有
cluster-admin
权限的用户身份登录到 hub 集群。
流程
- 从 hub 集群上的 Red Hat Advanced Cluster Management (RHACM)分离所有集群。
使用以下命令,删除
deployment
目录中的kustomization.yaml
文件:$ oc delete -k out/argocd/deployment
- 提交您的更改并推送到站点存储库。