17.3. 使用 RHACM 和 SiteConfig 资源安装受管集群

您可以使用辅助服务以及启用了 core-reduction 技术的 GitOps 插件策略生成器,以扩展 Red Hat Advanced Cluster Management (RHACM) 来大规模置备 OpenShift Container Platform 集群。ZTP 管道执行集群安装。ZTP 可以在断开连接的环境中使用。

17.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 的实例以及任何支持的资源被删除。

17.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) 后,会自动执行以下操作:

  1. 在目标主机上生成并启动发现镜像 ISO 文件。
  2. 当 ISO 文件成功在目标主机上引导时,它会将主机硬件信息报告给 RHACM。
  3. 在所有主机被发现后,会安装 OpenShift Container Platform。
  4. 当 OpenShift Container Platform 完成安装后,hub 在目标集群上安装 klusterlet 服务。
  5. 请求的附加组件服务安装在目标集群中。

当在 hub 集群上创建受管集群的 Agent CR 时,发现镜像 ISO 过程已完成。

重要

目标裸机主机必须满足 vDU 应用程序工作负载的推荐单节点 OpenShift 集群配置中列出的网络、固件和硬件要求。

17.3.3. 创建受管裸机主机 secret

将受管裸机主机所需的 Secret 自定义资源 (CR) 添加到 hub 集群。您需要 ZTP 管道的 secret 来访问 Baseboard Management Controller (BMC) 和支持的安装程序服务的 secret,以便从 registry 中拉取集群安装镜像。

注意

secret 按名称从 SiteConfig CR 引用。命名空间必须与 SiteConfig 命名空间匹配。

流程

  1. 创建一个 YAML secret 文件,其中包含主机 Baseboard Management Controller (BMC) 和安装 OpenShift 和所有附加组件集群 Operator 所需的凭证:

    1. 将以下 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
      1
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      2
      passwordusername 的 base64 编码值
      3
      必须与相关 SiteConfig CR 中配置的命名空间匹配
      4
      Base64 编码的 pull secret
  2. 将到 example-sno-secret.yaml 的相对路径添加用于安装集群的 kustomization.yaml 文件中。

17.3.4. 使用 GitOps ZTP 为安装配置 Discovery ISO 内核参数

GitOps ZTP 工作流使用 Discovery ISO 作为托管裸机主机的 OpenShift Container Platform 安装过程的一部分。您可以编辑 InfraEnv 资源来为 Discovery ISO 指定内核参数。这对具有特定环境要求的集群安装非常有用。例如,为发现 ISO 配置 rd.net.timeout.carrier 内核参数以促进集群的静态网络,或者在在安装过程中下载根文件系统前接收 DHCP 地址。

注意

在 OpenShift Container Platform 4.12 中,您只能添加内核参数。您不能替换或删除内核参数。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 创建 InfraEnv CR,并编辑 spec.kernelArguments 规格以配置内核参数。

    1. 将以下 YAML 保存到 InfraEnv-example.yaml 文件中:

      注意

      本例中的 InfraEnv CR 使用模板语法,如 {{ .Cluster.ClusterName }},它根据 SiteConfig CR 中的值进行填充。SiteConfig CR 在部署过程中自动填充这些模板的值。不要手动编辑模板。

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        annotations:
          argocd.argoproj.io/sync-wave: "1"
        name: "{{ .Cluster.ClusterName }}"
        namespace: "{{ .Cluster.ClusterName }}"
      spec:
        clusterRef:
          name: "{{ .Cluster.ClusterName }}"
          namespace: "{{ .Cluster.ClusterName }}"
        kernelArguments:
          - operation: append 1
            value: audit=0 2
          - operation: append
            value: trace=1
        sshAuthorizedKey: "{{ .Site.SshPublicKey }}"
        proxy: "{{ .Cluster.ProxySettings }}"
        pullSecretRef:
          name: "{{ .Site.PullSecretRef.Name }}"
        ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}"
        nmStateConfigLabelSelector:
          matchLabels:
            nmstate-label: "{{ .Cluster.ClusterName }}"
        additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"
      1
      指定添加内核参数的 append 操作。
      2
      指定您要配置的内核参数。这个示例配置了 audit 内核参数和 trace 内核参数。
  2. InfraEnv-example.yaml CR 提交到 Git 存储库中具有 SiteConfig CR 并推送您的更改的相同位置。以下示例显示了 Git 存储库结构示例:

    ~/example-ztp/install
              └── site-install
                   ├── siteconfig-example.yaml
                   ├── InfraEnv-example.yaml
                   ...
  3. 编辑 SiteConfig CR 中的 spec.clusters.crTemplates 规格来引用 Git 存储库中的 InfraEnv-example.yaml CR:

    clusters:
      crTemplates:
        InfraEnv: "InfraEnv-example.yaml"

    当您准备好通过提交和推送 SiteConfig CR 来部署集群时,构建管道会使用 Git 存储库中的自定义 InfraEnv-example CR 来配置基础架构环境,包括自定义内核参数。

验证

要验证是否应用了内核参数,在 Discovery 镜像验证 OpenShift Container Platform 是否准备好安装后,您可以在安装过程开始前通过 SSH 连接到目标主机。此时,您可以在 /proc/cmdline 文件中查看发现 ISO 的内核参数。

  1. 使用目标主机开始 SSH 会话:

    $ ssh -i /path/to/privatekey core@<host_name>
  2. 使用以下命令查看系统的内核参数:

    $ cat /proc/cmdline

17.3.5. 使用 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。

    流程

    1. 在 hub 集群中创建所需的受管集群 secret。这些资源必须位于名称与集群名称匹配的命名空间中。例如,在 out/argocd/example/siteconfig/example-sno.yaml 中,集群名称和命名空间是 example-sno

      1. 运行以下命令来导出集群命名空间:

        $ export CLUSTERNS=example-sno
      2. 创建命名空间:

        $ oc create namespace $CLUSTERNS
    2. 为受管集群创建 pull secret 和 BMC Secret CR。pull secret 必须包含安装 OpenShift Container Platform 和其他需要安装的 Operator 所需的所有凭证。如需更多信息,请参阅"创建受管裸机主机 secret"。

      注意

      secret 根据名称从 SiteConfig 自定义资源 (CR) 引用。命名空间必须与 SiteConfig 命名空间匹配。

    3. 在 Git 存储库本地克隆中为集群创建一个 SiteConfig CR:

      1. out/argocd/example/siteconfig/ 文件夹中选择适合您的 CR 示例。文件夹中包含单一节点、三节点和标准集群的示例文件:

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. 更改示例文件中的集群和主机详情,以匹配您想要的集群类型。例如:

        单节点 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.12" 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"
                bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 7
                bmcCredentialsName:
                  name: "bmh-secret" 8
                bootMACAddress: "AA:BB:CC:DD:EE:11"
                bootMode: "UEFI" 9
                rootDeviceHints:
                  wwn: "0x11111000000asd123"
                cpuset: "0-1,52-53"  10
                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
        用于访问主机的 BMC 地址。适用于所有集群类型。
        8
        使用主机 BMC 凭证单独创建的 bmh-secret CR 的名称。在创建 bmh-secret CR 时,请使用与置备主机的 SiteConfig CR 相同的命名空间。
        9
        配置主机的引导模式。默认值为 UEFI。使用 UEFISecureBoot 在主机上启用安全引导。
        10
        cpuset 应该与用于工作负载分区的集群 PerformanceProfile CR .spec.cpu.reserved 字段中设置的值匹配。
        11
        指定节点的网络设置。
        12
        配置主机的 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群,特定于节点的 API 和 Ingress IP 应该相同。
        注意

        有关 BMC 寻址的更多信息,请参阅"添加资源"部分。

      3. 您可以在 out/argocd/extra-manifest 中检查默认的 extra-manifest MachineConfig CR。它在安装时会自动应用到集群。
      4. 可选: 要在置备的集群中置备额外的安装清单,请在 Git 存储库中创建一个目录,如 sno-extra-manifest/,并将自定义清单 CR 添加到这个目录中。如果您的 SiteConfig.yamlextraManifestPath 字段中引用这个目录,则这个引用目录中的所有 CR 都会被附加到默认的额外的清单集合中。
    4. kustomization.yaml 文件中将 SiteConfig CR 添加到 generators 部分中 ,类似于 out/argocd/example/siteconfig/kustomization.yaml 中显示的示例。
    5. 在 Git 存储库中提交 SiteConfig CR 及关联的 kustomization.yaml 更改并推送更改。

      ArgoCD 管道检测到更改并开始受管集群部署。

17.3.5.1. 单节点 OpenShift SiteConfig CR 安装参考

表 17.3. 单节点 OpenShift 集群的 SiteConfig CR 安装选项

SiteConfig CR 字段描述

metadata.name

name 设置为 assisted-deployment-pull-secret,并在与 SiteConfig CR 相同的命名空间中创建 assisted-deployment-pull-secret CR。

spec.clusterImageSetNameRef

为站点中的所有集群配置 hub 集群上可用的镜像集。要查看 hub 集群上支持的版本列表,请运行 oc get clusterimagesets

installConfigOverrides

installConfigOverrides 字段设置为在集群安装前启用或禁用可选组件。

重要

使用示例 SiteConfig CR 中指定的引用配置。在系统中添加其他组件可能需要额外的保留 CPU 容量。

spec.clusters.clusterLabels

配置集群标签,使其与您定义的 PolicyGenTemplate CR 中的 bindingRules 字段对应。例如,policygentemplates/common-ranGen.yaml 应用到所有带有 common: true 设置的集群,policygentemplates/group-du-sno-ranGen.yaml 应用到所有带有 group-du-sno: "" 设置的所有集群。

spec.clusters.crTemplates.KlusterletAddonConfig

可选。将 KlusterletAddonConfig 设置为 KlusterletAddonConfigOverride.yaml,以覆盖为集群创建的默认 'KlusterletAddonConfig

spec.clusters.nodes.hostName

对于单节点部署,请定义一个主机。对于三节点部署,请定义三个主机。对于标准部署,使用 role: master 定义三个主机,使用 role: worker 定义两个或更多主机。

spec.clusters.nodes.bmcAddress

用于访问主机的 BMC 地址。适用于所有集群类型。{ztp} 支持使用 Redfish 或 IPMI 协议进行 iPXE 和虚拟介质引导。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 寻址的更多信息,请参阅"添加资源"部分。

spec.clusters.nodes.bmcAddress

用于访问主机的 BMC 地址。适用于所有集群类型。{ztp} 支持使用 Redfish 或 IPMI 协议进行 iPXE 和虚拟介质引导。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 寻址的更多信息,请参阅"添加资源"部分。

注意

在边缘 Telco 用例中,只有虚拟介质可用于 GitOps {ztp}。

spec.clusters.nodes.bmcCredentialsName

配置使用主机 BMC 凭证单独创建的 bmh-secret CR。在创建 bmh-secret CR 时,请使用与置备主机的 SiteConfig CR 相同的命名空间。

spec.clusters.nodes.bootMode

将主机的引导模式设置为 UEFI。默认值为 UEFI。使用 UEFISecureBoot 在主机上启用安全引导。

spec.clusters.nodes.rootDeviceHints

指定用于部署的设备。建议在重启后稳定的标识符,例如 wwn: <disk_wwn>deviceName: /dev/disk/by-path/<device_path>。有关 stable 标识符的详细列表,请参阅 "About root device hints 部分"。

spec.clusters.nodes.diskPartition

可选。提供的 diskPartition 示例用于配置额外的磁盘分区。

spec.clusters.nodes.cpuset

配置 cpuset,以匹配您在工作负载分区的集群 PerformanceProfile CR spec.cpu.reserved 字段中设置的值。

spec.clusters.nodes.nodeNetwork

配置节点的网络设置。

spec.clusters.nodes.nodeNetwork.config.interfaces.ipv6

为主机配置 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群,特定于节点的 API 和 Ingress IP 应该相同。

17.3.6. 监控受管集群安装进度

ArgoCD 管道使用 SiteConfig CR 生成集群配置 CR,并将其与 hub 集群同步。您可以在 ArgoCD 仪表板中监控此同步的进度。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

同步完成后,安装通常会按如下方式进行:

  1. Assisted Service Operator 会在集群中安装 OpenShift Container Platform。您可以运行以下命令来从 RHACM 仪表板或命令行监控集群安装进度:

    1. 导出集群名称:

      $ export CLUSTER=<clusterName>
    2. 查询受管集群的 AgentClusterInstall CR:

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
    3. 获取集群的安装事件:

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

17.3.7. 通过验证安装 CR 对 GitOps ZTP 进行故障排除

ArgoCD 管道使用 SiteConfigPolicyGenTemplate 自定义资源 (CR) 生成集群配置 CR 和 Red Hat Advanced Cluster Management (RHACM) 策略。使用以下步骤对此过程中可能出现的问题进行故障排除。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 您可以使用以下命令检查安装 CR 是否已创建:

    $ oc get AgentClusterInstall -n <cluster_name>

    如果没有返回对象,请使用以下步骤对从 SiteConfig 文件到安装 CR 的 ArgoCD 管道流进行故障排除。

  2. 验证 ManagedCluster CR 是否使用 hub 集群上的 SiteConfig CR 生成:

    $ oc get managedcluster
  3. 如果缺少 ManagedCluster,请检查 clusters 应用程序是否将 Git 存储库中的文件与 hub 集群同步:

    $ oc describe -n openshift-gitops application clusters
    1. 检查 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
    2. 检查 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

17.3.8. 在 Supermicro 服务器上对 {ztp} 虚拟介质引导进行故障排除

在使用 https 协议提供镜像时,Supermicro X11 服务器不支持虚拟介质安装。因此,此环境的单节点 OpenShift 部署无法在目标节点上引导。要避免这个问题,请登录到 hub 集群并禁用 Provisioning 资源中的传输层安全 (TLS)。这样可确保镜像不通过 TLS 提供,即使镜像地址使用 https 方案。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

步骤

  1. 运行以下命令,在 Provisioning 资源中禁用 TLS:

    $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
  2. 继续部署单节点 OpenShift 集群的步骤。

17.3.9. 从 ZTP 管道中删除受管集群站点

您可以从 ZTP 管道中删除受管站点以及关联的安装和配置策略 CR。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 通过从 kustomization.yaml 文件中删除关联的 SiteConfigPolicyGenTemplate 文件来删除站点和相关 CR。

    当您再次运行 ZTP 管道时,生成的 CR 将被删除。

  2. 可选: 如果要永久删除站点,您还应从 Git 仓库中删除 SiteConfig 和特定站点的 PolicyGenTemplate 文件。
  3. 可选:如果要临时删除站点,例如在重新部署站点时,可以保留 Git 存储库中的 SiteConfig 和特定站点的 PolicyGenTemplate CR。

其他资源

17.3.10. 从 ZTP 管道中删除过时的内容

如果对 PolicyGenTemplate 配置的更改会导致过时的策略,例如,如果您重命名策略,请使用以下步骤删除过时的策略。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 从 Git 存储库中删除受影响的 PolicyGenTemplate 文件,提交并推送到远程存储库。
  2. 等待更改通过应用程序同步,并将受影响的策略从 hub 集群中删除。
  3. 将更新的 PolicyGenTemplate 文件重新添加到 Git 存储库,然后提交并推送到远程存储库。

    注意

    从 Git 仓库中删除零接触置备 (ZTP) 策略,因此也会从 hub 集群中删除它们,不会影响受管集群的配置。由该策略管理的策略和 CR 保留在受管集群上。

  4. 可选:作为替代方案,在修改了导致过时策略的 PolicyGenTemplate CR 后,您可以手动从 hub 集群中删除这些策略。您可以使用 Governance 选项卡或运行以下命令来从 RHACM 控制台删除策略:

    $ oc delete policy -n <namespace> <policy_name>

17.3.11. 弃用 ZTP 管道

您可以删除 ArgoCD 管道和所有生成的 ZTP 工件。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。

流程

  1. 从 hub 集群上的 Red Hat Advanced Cluster Management (RHACM)分离所有集群。
  2. 使用以下命令,删除 deployment 目录中的 kustomization.yaml 文件:

    $ oc delete -k out/argocd/deployment
  3. 提交您的更改并推送到站点存储库。