流程

1. 登录到镜像主机。

2. 从 mirror.openshift.com 获取 RHCOS ISO 和 RootFS 镜像，例如：

   1. 将所需的镜像名称和 OpenShift Container Platform 版本导出为环境变量：

      $ export ISO_IMAGE_NAME=<iso_image_name> 1

      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1

      $ export OCP_VERSION=<ocp_version> 1

      1

      ISO 镜像名称，如 rhcos-4.15.1-x86_64-live.x86_64.iso

      1

      RootFS 镜像名称，如 rhcos-4.15.1-x86_64-live-rootfs.x86_64.img

      1

      OpenShift Container Platform 版本，如 4.15.1

   2. 下载所需的镜像：

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.15/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

流程

1. 启用 Provisioning 资源，以监视所有命名空间并为断开连接的环境配置镜像。如需更多信息，请参阅启用中央基础架构管理服务。

2. 运行以下命令来更新 AgentServiceConfig CR：

   $ oc edit AgentServiceConfig

3. 在 CR 的 items.spec.osImages 字段中添加以下条目：

   - cpuArchitecture: x86_64
       openshiftVersion: "4.15"
       rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
       url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

   其中：

   <host>

   是目标镜像 registry HTTP 服务器的完全限定域名 (FQDN)。

   <path>

   是目标镜像 registry 上镜像的路径。

   保存并退出编辑器以应用更改。

流程

1. 创建包含镜像 registry 配置的 ConfigMap：

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: assisted-installer-mirror-config
     namespace: multicluster-engine 1
     labels:
       app: assisted-service
   data:
     ca-bundle.crt: | 2
       -----BEGIN CERTIFICATE-----
       <certificate_contents>
       -----END CERTIFICATE-----
   
     registries.conf: | 3
       unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
   
       [[registry]]
          prefix = ""
          location = "quay.io/example-repository" 4
          mirror-by-digest-only = true
   
          [[registry.mirror]]
          location = "mirror1.registry.corp.com:5000/example-repository" 5

   1

   ConfigMap 命名空间必须设置为 multicluster-engine。

   2

   创建镜像 registry 时使用的镜像 registry 证书。

   3

   镜像 registry 的配置文件。镜像 registry 配置将镜像信息添加到发现镜像的 /etc/containers/registries.conf 文件中。当信息传递给安装程序时，镜像信息会存储在 install-config.yaml 文件的 imageContentSources 部分中。在 hub 集群上运行的 Assisted Service pod 从配置的镜像 registry 获取容器镜像。

   4

   镜像 registry 的 URL。在配置镜像 registry 时，您必须运行 oc adm release mirror 命令使用 imageContentSources 部分中的 URL。如需更多信息，请参阅 Mirroring the OpenShift Container Platform image repository 部分。

   5

   registries.conf 文件中定义的 registry 必须由存储库范围，而不是由 registry 范围。在本例中，quay.io/example-repository 和 mirror1.registry.corp.com:5000/example-repository 存储库都限定了 example-repository 存储库。

   这会更新 AgentServiceConfig 自定义资源中的 mirrorRegistryRef，如下所示：

   输出示例

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
     namespace: multicluster-engine 1
   spec:
     databaseStorage:
       volumeName: <db_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <db_storage_size>
     filesystemStorage:
       volumeName: <fs_pv_name>
       accessModes:
       - ReadWriteOnce
       resources:
         requests:
           storage: <fs_storage_size>
     mirrorRegistryRef:
       name: assisted-installer-mirror-config 2
     osImages:
       - openshiftVersion: <ocp_version>
         url: <iso_url> 3

   1

   将 AgentServiceConfig 命名空间设置为 multicluster-engine，以匹配 ConfigMap 命名空间

   2

   将 mirrorRegistryRef.name 设置为与相关 ConfigMap CR 中指定的定义匹配

   3

   设置在 httpd 服务器上托管的 ISO 的 URL

流程

1. 运行以下命令来更新 AgentServiceConfig 自定义资源 (CR)：

   $ oc edit AgentServiceConfig agent

2. 在 CR 中添加 unauthenticatedRegistries 字段：

   apiVersion: agent-install.openshift.io/v1beta1
   kind: AgentServiceConfig
   metadata:
     name: agent
   spec:
     unauthenticatedRegistries:
     - example.registry.com
     - example.registry2.com
     ...

   未经身份验证的 registry 在 AgentServiceConfig 资源的 spec.unauthenticatedRegistries 下列出。任何此列表中的 registry 都不需要在用于 spoke 集群安装的 pull secret 中有一个条目。assisted-service 通过确保包含用于安装的每个镜像 registry 的身份验证信息来验证 pull secret。

1. 在 hub 集群中打开一个 debug shell 提示符：

   $ oc debug node/<node_name>

2. 运行以下命令测试对未经身份验证的 registry 的访问：

   sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

   其中：

   <unauthenticated_registry>

   新的 registry，如 unauthenticated-image-registry.openshift-image-registry.svc:5000。

   输出示例

   Login Succeeded!

流程

1. 准备 ArgoCD 管道配置：

   1. 创建 Git 存储库，其目录结构类似于 example 目录。如需更多信息，请参阅"准备 GitOps ZTP 站点配置存储库"。

   2. 使用 ArgoCD UI 配置对存储库的访问。在 Settings 下配置以下内容：

      • Repositories - 添加连接信息。URL 必须以 .git 结尾，例如 https://repo.example.com/repo.git 和凭证。
      • 证书 - 如果需要，为存储库添加公共证书。

   3. 根据您的 Git 仓库修改两个 ArgoCD 应用程序, out/argocd/deployment/clusters-app.yaml 和 out/argocd/deployment/policies-app.yaml ：

      • 更新 URL 以指向 Git 存储库。URL 以 .git 结尾，例如 https://repo.example.com/repo.git。
      • targetRevision 表示要监控的 Git 存储库分支。
      • path 指定到 SiteConfig 和 PolicyGenTemplate CR 的路径。

2. 要安装 GitOps ZTP 插件，请使用之前提取到 out/argocd/deployment/ 目录中的补丁文件来修补 hub 集群中的 ArgoCD 实例。运行以下命令:

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

3. 在 RHACM 2.7 及更高版本中，多集群引擎默认启用 cluster-proxy-addon 功能。应用以下补丁来禁用 cluster-proxy-addon 功能，并删除负责此附加组件的相关 hub 集群和受管 pod。运行以下命令:

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

4. 运行以下命令，将管道配置应用到 hub 集群：

   $ oc apply -k out/argocd/deployment

流程

1. 使用 SiteConfig 和 PolicyGenTemplate CR 的单独路径创建一个目录结构。

   注意

   在单独的目录中，保持 SiteConfig 和 PolicyGenTemplate CR。SiteConfig 和 PolicyGenTemplate 目录必须包含一个 kustomization.yaml 文件，该文件明确包含该目录中的文件。

2. 使用以下命令，从 ztp-site-generate 容器镜像导出 argocd 目录：

   $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15

   $ mkdir -p ./out

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

3. 检查 out 目录是否包含以下子目录：

   • out/extra-manifest 包含 SiteConfig 用来生成额外清单 configMap 的源 CR 文件。
   • out/source-crs 包含 PolicyGenTemplate 用来生成 Red Hat Advanced Cluster Management(RHACM)策略的源 CR 文件。
   • out/argocd/deployment 包含补丁和 YAML 文件，可在 hub 集群中应用，以便在此过程的下一步中使用。
   • out/argocd/example 包含代表推荐的配置的 siteConfig 和 PolicyGenTemplate 文件的示例。
4. 将 out/source-crs 文件夹和内容复制到 PolicyGentemplate 目录。

5. out/extra-manifests 目录包含 RAN DU 集群的参考清单。将 out/extra-manifests 目录复制到 SiteConfig 文件夹。此目录应包含来自 ztp-site-generate 容器的 CR。不要在此处添加用户提供的 CR。如果要使用用户提供的 CR，您必须为其内容创建另一个目录。例如：

   example/
     ├── policygentemplates
     │   ├── kustomization.yaml
     │   └── source-crs/
     └── siteconfig
           ├── extra-manifests
           └── kustomization.yaml

6. 提交目录结构和 kustomization.yaml 文件并推送到 Git 存储库。初始推送到 Git 的推送应包含 kustomization.yaml 文件。

1. 使用 ztp-done 标签标记所有现有集群。
2. 停止 ArgoCD 应用程序。
3. 安装新的 GitOps ZTP 工具。
4. 更新 Git 存储库中的所需内容和可选更改。
5. 更新并重启应用程序配置。

流程

1. 获取具有用于配置 Red Hat OpenShift GitOps 的自定义资源 (CR) 的 GitOps ZTP 容器的最新版本，以用于 GitOps ZTP。

2. 使用以下命令提取 argocd/deployment 目录：

   $ mkdir -p ./update

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./update

   /update 目录包含以下子目录：

   • update/extra-manifest: 包含 SiteConfig CR 用来生成额外清单 configMap 的源 CR 文件。
   • update/source-crs ：包含 PolicyGenTemplate CR 用于生成 Red Hat Advanced Cluster Management(RHACM)策略的源 CR 文件。
   • update/argocd/deployment: 包含要在 hub 集群上应用的补丁和 YAML 文件，以便在此过程的下一步中使用。
   • update/argocd/example 包含代表推荐的配置的 siteConfig 和 PolicyGenTemplate 文件的示例。

3. 更新 cluster-app.yaml 和 policies-app.yaml 文件，以反映应用程序的名称以及 Git 仓库的 URL、分支和路径。

   如果升级包含导致过时的策略的更改，则应该在执行升级前删除过时的策略。

4. 在 /update 文件夹和 Git 仓库（您管理团队站点 CR）中的配置和部署源 CR 之间的更改进行 diff 操作。应用所需的更改并将其推送到您的站点存储库。

   重要

   当您将 GitOps ZTP 更新至最新版本时，您必须将 update/argocd/deployment 目录中的更改应用到您的站点存储库。不要使用旧版本的 argocd/deployment/ 文件。

流程

1. 找到列出使用 GitOps Zero Touch Provisioning (ZTP) 部署的受管集群的标签选择器，如 local-cluster!=true ：

   $ oc get managedcluster -l 'local-cluster!=true'

2. 确保生成的列表中包含使用 GitOps ZTP 部署的所有受管集群，然后使用该选择器添加 ztp-done 标签：

   $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

流程

1. 在 clusters 应用程序上执行非级联删除以保留所有生成的资源：

   $ oc delete -f update/argocd/deployment/clusters-app.yaml

2. 在 policies 应用程序上执行级联删除以删除所有之前的策略：

   $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge

   $ oc delete -f update/argocd/deployment/policies-app.yaml

流程

1. 要安装 GitOps ZTP 插件，请使用之前提取到 out/argocd/deployment/ 目录中的补丁文件来修补 hub 集群中的 ArgoCD 实例。运行以下命令:

   $ oc patch argocd openshift-gitops \
   -n openshift-gitops --type=merge \
   --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json

2. 在 RHACM 2.7 及更高版本中，多集群引擎默认启用 cluster-proxy-addon 功能。应用以下补丁来禁用 cluster-proxy-addon 功能，并删除负责此附加组件的相关 hub 集群和受管 pod。运行以下命令:

   $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json

3. 运行以下命令，将管道配置应用到 hub 集群：

   $ oc apply -k out/argocd/deployment

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

流程

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

      password 和 username 的 base64 编码值

      3

      必须与相关 SiteConfig CR 中配置的命名空间匹配

      4

      Base64 编码的 pull secret

2. 将到 example-sno-secret.yaml 的相对路径添加用于安装集群的 kustomization.yaml 文件中。

流程

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 来配置基础架构环境，包括自定义内核参数。

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

   $ ssh -i /path/to/privatekey core@<host_name>

2. 使用以下命令查看系统的内核参数：

   $ cat /proc/cmdline

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]'

流程

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

流程

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

   $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'

2. 继续部署单节点 OpenShift 集群的步骤。

流程

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

   当您再次运行 GitOps ZTP 管道时，生成的 CR 会被删除。

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

流程

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

3. 将更新的 PolicyGenTemplate 文件重新添加到 Git 存储库，然后提交并推送到远程存储库。

   注意

   从 Git 仓库中删除 GitOps Zero Touch Provisioning (ZTP) 策略，因此也会从 hub 集群中删除它们，不会影响受管集群的配置。由该策略管理的策略和 CR 保留在受管集群上。

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

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

流程

1. 从 hub 集群上的 Red Hat Advanced Cluster Management (RHACM)分离所有集群。

2. 使用以下命令，删除 deployment 目录中的 kustomization.yaml 文件：

   $ oc delete -k out/argocd/deployment

3. 提交您的更改并推送到站点存储库。

流程

1. 为特定于站点的配置 CR 创建 PolicyGenTemplate CR。

   1. 从 out/argocd/example/policygentemplates 文件夹中选择适当的 CR 示例，例如 example-sno-site.yaml 或 example-multinode-site.yaml。

   2. 更改示例文件中的 bindingRules 字段，使其与 SiteConfig CR 中包含的特定于站点的标签匹配。在示例 SiteConfig 文件中，特定于站点的标签是 sites: example-sno。

      注意

      确保 PolicyGenTemplate bindingRules 字段中定义的标签对应于相关受管集群 SiteConfig CR 中定义的标签。

   3. 更改示例文件中的内容，使其与所需配置匹配。

2. 可选：为应用到集群的任何通用配置 CR 创建一个 PolicyGenTemplate CR。

   1. 从 out/argocd/example/policygentemplates 文件夹中选择适合您的 CR 示例，例如 common-ranGen.yaml。
   2. 更改示例文件中的内容，使其与所需配置匹配。

3. 可选：为应用到团队中特定集群组的任何组配置 CR 创建一个 PolicyGenTemplate CR。

   确保 overlaid spec 文件的内容与您的预期最终状态匹配。作为参考，out/source-crs 目录包含可用于包含并由您的 PolicyGenTemplate 模板提供的 source-crs 的完整列表。

   注意

   根据集群的特定要求，每个集群类型可能需要一个组策略，特别是考虑示例组策略各自有一个 PerformancePolicy.yaml 文件，如果这些集群是由相同的硬件配置，则只能在一组集群中共享。

   1. 从 out/argocd/example/policygentemplates 文件夹中选择适当的 CR 示例，例如 group-du-sno-ranGen.yaml。
   2. 更改示例文件中的内容，使其与所需配置匹配。
4. 可选。当 GitOps ZTP 安装和配置完成后，创建验证器通知策略 PolicyGenTemplate CR。如需更多信息，请参阅"创建验证器通知策略"。

5. 在 YAML 文件中定义所有策略命名空间，类似于示例 out/argocd/example/policygentemplates/ns.yaml 文件。

   重要

   不要在带有 PolicyGenTemplate CR 的同一文件中包括 Namespace CR。

6. 将 PolicyGenTemplate CR 和 Namespace CR 添加到 generators 部分中的 kustomization.yaml 文件中，类似于 out/argocd/example/policygentemplates/kustomization.yaml 所示的示例。

7. 在 Git 存储库中提交 PolicyGenTemplate CR、Namespace CR 和关联的 kustomization.yaml 文件并推送更改。

   ArgoCD 管道检测到更改并开始受管集群部署。您可以同时将更改推送到 SiteConfig CR 和 PolicyGenTemplate CR。

流程

1. Topology Aware Lifecycle Manager(TALM)应用绑定到集群的配置策略。

   集群安装完成后，集群变为 Ready，ClusterGroupUpgrade CR 对应于此集群，且由 run.openshift.io/ztp-deploy-wave annotations 定义的已排序策略列表由 TALM 自动创建。集群的策略按 ClusterGroupUpgrade CR 中列出的顺序应用。

   您可以使用以下命令监控配置策略协调的高级进度：

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

   输出示例

   {
     "lastTransitionTime": "2022-11-09T07:28:09Z",
     "message": "Remediating non-compliant policies",
     "reason": "InProgress",
     "status": "True",
     "type": "Progressing"
   }

2. 您可以使用 RHACM 仪表板或命令行监控详细的集群策略合规状态。

   1. 要使用 oc 检查策略合规性，请运行以下命令：

      $ oc get policies -n $CLUSTER

      输出示例

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

   2. 要从 RHACM Web 控制台检查策略状态，请执行以下操作：

      1. 点 Governance → Find policies。
      2. 点集群策略检查其状态。

流程

1. 要显示策略的详细信息，请运行以下命令：

   $ oc describe -n openshift-gitops application policies

2. 检查 Status: Conditions: 来显示错误日志。例如，设置无效的 sourceFile→fileName: 生成以下错误：

   Status:
     Conditions:
       Last Transition Time:  2021-11-26T17:21:39Z
       Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
       Type:  ComparisonError

3. 检查 Status: Sync:。如果 Status: Conditions: 中存在日志错误，则 Status: Sync: 显示 Unknown 或 Error:

   Status:
     Sync:
       Compared To:
         Destination:
           Namespace:  policies-sub
           Server:     https://kubernetes.default.svc
         Source:
           Path:             policies
           Repo URL:         https://git.com/ran-sites/policies/.git
           Target Revision:  master
       Status:               Error

4. 当 Red Hat Advanced Cluster Management(RHACM)识别策略应用到 ManagedCluster 对象时，策略 CR 对象应用到集群命名空间。检查策略是否已复制到集群命名空间中：

   $ oc get policy -n $CLUSTER

   输出示例：

   NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
   ztp-common.common-config-policy              inform               Compliant          13d
   ztp-common.common-subscriptions-policy       inform               Compliant          13d
   ztp-group.group-du-sno-config-policy         inform               Compliant          13d
   Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
   ztp-site.example-sno-config-policy           inform               Compliant          13d

   RHACM 将所有适用的策略复制到集群命名空间中。复制的策略名称使用以下格式：<policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName>。

5. 检查放置规则中是否有没有复制到集群命名空间中的策略。这些策略的 PlacementRule 中的 matchSelector 应与 ManagedCluster 对象上的标签匹配：

   $ oc get placementrule -n $NS

6. 使用以下命令，注意适合缺少策略、通用、组或站点的 PlacementRule 名称：

   $ oc get placementrule -n $NS <placementRuleName> -o yaml

   • status-decisions 应该包括集群名称。
   • spec 中 matchSelector 的键值对必须与受管集群上的标签匹配。

7. 使用以下命令，检查 ManagedCluster 对象上的标签：

   $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq

8. 使用以下命令查看合规策略：

   $ oc get policy -n $CLUSTER

   如果 Namespace、OperatorGroup 和 Subscription 策略兼容，但 Operator 配置策略不兼容，则 Operator 可能不会在受管集群中安装。这会导致 Operator 配置策略无法应用，因为 CRD 还没有应用到 spoke。

流程

1. 在受管集群变为 Ready 后，Topology Aware Lifecycle Manager 在命名空间 ztp-install 中生成 ClusterGroupUpgrade CR：

   $ export CLUSTER=<clusterName>

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER

2. 如果出现意外问题，且策略无法在配置超时（默认为 4 小时）内变为合规，ClusterGroupUpgrade CR 的状态会显示 UpgradeTimedOut ：

   $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

3. UpgradeTimedOut 状态的 ClusterGroupUpgrade CR 每小时自动重启其策略协调。如果更改了策略，可以通过删除现有 ClusterGroupUpgrade CR 来启动立即重试。这会触发自动创建新的 ClusterGroupUpgrade CR，以开始立即协调策略：

   $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

流程

1. 从受影响的 CR 中删除您不再需要的内容。在本例中，disableDrain: false 行已从 SriovOperatorConfig CR 中删除。

   CR 示例

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovOperatorConfig
   metadata:
     name: default
     namespace: openshift-sriov-network-operator
   spec:
     configDaemonNodeSelector:
       "node-role.kubernetes.io/$mcp": ""
     disableDrain: true
     enableInjector: true
     enableOperatorWebhook: true

2. 在 group-du-sno-ranGen.yaml 文件中，将受影响的策略的 complianceType 更改为 mustonlyhave。

   YAML 示例

   # ...
   - fileName: SriovOperatorConfig.yaml
     policyName: "config-policy"
     complianceType: mustonlyhave
   # ...

3. 创建 ClusterGroupUpdates CR，并指定必须接收 CR 更改的集群：

   ClusterGroupUpdates CR 示例

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: cgu-remove
     namespace: default
   spec:
     managedPolicies:
       - ztp-group.group-du-sno-config-policy
     enable: false
     clusters:
     - spoke1
     - spoke2
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240
     batchTimeoutAction:

4. 运行以下命令来创建 ClusterGroupUpgrade CR：

   $ oc create -f cgu-remove.yaml

5. 当您准备好应用更改时，例如在适当的维护窗口中，运行以下命令将 spec.enable 字段的值改为 true ：

   $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
   --patch '{"spec":{"enable":true}}' --type=merge

验证

1. 运行以下命令，检查策略的状态：

   $ oc get <kind> <changed_cr_name>

   输出示例

   NAMESPACE   NAME                                                   REMEDIATION ACTION   COMPLIANCE STATE   AGE
   default     cgu-ztp-group.group-du-sno-config-policy               enforce                                 17m
   default     ztp-group.group-du-sno-config-policy                   inform               NonCompliant       15h

   当策略的 COMPLIANCE STATE 为 Compliant 时，这意味着已更新 CR，并删除不需要的内容。

2. 在受管集群中运行以下命令来检查策略是否已从目标集群中移除：

   $ oc get <kind> <changed_cr_name>

   如果没有结果，则会从受管集群中删除 CR。

流程

1. 运行以下命令来创建输出文件夹：

   $ mkdir -p ./out

2. 从 ztp-site-generate 容器镜像导出 argocd 目录：

   $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 extract /home/ztp --tar | tar x -C ./out

   ./out 目录包含 out/argocd/example/ 文件夹中的参考 PolicyGenTemplate 和 SiteConfig CR。

   输出示例

   out
    └── argocd
         └── example
              ├── policygentemplates
              │     ├── common-ranGen.yaml
              │     ├── example-sno-site.yaml
              │     ├── group-du-sno-ranGen.yaml
              │     ├── group-du-sno-validator-ranGen.yaml
              │     ├── kustomization.yaml
              │     └── ns.yaml
              └── siteconfig
                     ├── example-sno.yaml
                     ├── KlusterletAddonConfigOverride.yaml
                     └── kustomization.yaml

3. 为站点安装 CR 创建输出文件夹：

   $ mkdir -p ./site-install

4. 为您要安装的集群类型修改示例 SiteConfig CR。将 example-sno.yaml 复制到 site-1-sno.yaml，并修改 CR 以匹配您要安装的站点和裸机主机的详情，例如：

   # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
   ---
   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "example-sno"
     namespace: "example-sno"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.10"
     sshPublicKey: "ssh-rsa AAAA..."
     clusters:
       - clusterName: "example-sno"
         networkType: "OVNKubernetes"
         # installConfigOverrides is a generic way of passing install-config
         # parameters through the siteConfig.  The 'capabilities' field configures
         # the composable openshift feature.  In this 'capabilities' setting, we
         # remove all but the marketplace component from the optional set of
         # components.
         # Notes:
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         installConfigOverrides: "{\"capabilities\":{\"baselineCapabilitySet\": \"None\", \"additionalEnabledCapabilities\": [ \"marketplace\", \"NodeTuning\" ] }}"
         # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
         # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
         # extraManifestPath: sno-extra-manifest
         clusterLabels:
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
           du-profile: "4.14"
           # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
           # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
           common: true
           # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
           group-du-sno: ""
           # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
           # Normally this should match or contain the cluster name so it only applies to a single cluster
           sites: "example-sno"
         clusterNetwork:
           - cidr: 1001:1::/48
             hostPrefix: 64
         machineNetwork:
           - cidr: 1111:2222:3333:4444::/64
         serviceNetwork:
           - 1001:2::/112
         additionalNTPSources:
           - 1111:2222:3333:4444::2
         # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
         # please see Workload Partitioning Feature for a complete guide.
         cpuPartitioningMode: AllNodes
         # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
         #crTemplates:
         #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
         nodes:
           - hostName: "example-node1.example.com"
             role: "master"
             # Optionally; This can be used to configure desired BIOS setting on a host:
             #biosConfigRef:
             #  filePath: "example-hw.profile"
             bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
             bmcCredentialsName:
               name: "example-node1-bmh-secret"
             bootMACAddress: "AA:BB:CC:DD:EE:11"
             # Use UEFISecureBoot to enable secure boot
             bootMode: "UEFI"
             rootDeviceHints:
               wwn: "0x11111000000asd123"
               # example of diskPartition below is used for image registry (check ImageRegistry.md for more details), but it's not limited to this use case
             #        diskPartition:
             #          - device: /dev/disk/by-id/wwn-0x11111000000asd123 # match rootDeviceHints
             #            partitions:
             #              - mount_point: /var/imageregistry
             #                size: 102500
             #                start: 344844
   
             nodeNetwork:
               interfaces:
                 - name: eno1
                   macAddress: "AA:BB:CC:DD:EE:11"
               config:
                 interfaces:
                   - name: eno1
                     type: ethernet
                     state: up
                     ipv4:
                       enabled: false
                     ipv6:
                       enabled: true
                       address:
                         # For SNO sites with static IP addresses, the node-specific,
                         # API and Ingress IPs should all be the same and configured on
                         # the interface
                         - 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

   注意

   从 ztp-site-generate 容器的 out/extra-manifest 目录中提取引用 CR 配置文件后，您可以使用 extraManifests.searchPaths 来包含包含这些文件的 git 目录的路径。这允许 GitOps ZTP 管道在集群安装过程中应用这些 CR 文件。如果您配置 searchPaths 目录，GitOps ZTP 管道不会在站点安装过程中从 ztp-site-generate 容器获取清单。

5. 运行以下命令，通过处理修改后的 SiteConfig CR site-1-sno.yaml 来生成第 0 天安装 CR：

   $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install site-1-sno.yaml /output

   输出示例

   site-install
   └── site-1-sno
       ├── site-1_agentclusterinstall_example-sno.yaml
       ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
       ├── site-1-sno_clusterdeployment_example-sno.yaml
       ├── site-1-sno_configmap_example-sno.yaml
       ├── site-1-sno_infraenv_example-sno.yaml
       ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
       ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
       ├── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml
       ├── site-1-sno_managedcluster_example-sno.yaml
       ├── site-1-sno_namespace_example-sno.yaml
       └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

6. 可选：使用 -E 选项处理参考 SiteConfig CR，只为特定集群类型生成 day-0 MachineConfig 安装 CR。例如，运行以下命令：

   1. 为 MachineConfig CR 创建输出文件夹：

      $ mkdir -p ./site-machineconfig

   2. 生成 MachineConfig 安装 CR：

      $ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator install -E site-1-sno.yaml /output

      输出示例

      site-machineconfig
      └── site-1-sno
          ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml
          ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml
          └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yaml

7. 使用上一步中的参考 PolicyGenTemplate CR 生成并导出 day-2 配置 CR。运行以下命令：

   1. 为 day-2 CR 创建输出文件夹：

      $ mkdir -p ./ref

   2. 生成并导出第 2 天配置 CR：

      $ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15 generator config -N . /output

      该命令在 ./ref 文件夹中为单节点 OpenShift、三节点集群和标准集群生成示例组和特定于站点的 PolicyGenTemplate CR。

      输出示例

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

8. 使用生成的 CR 作为安装集群的 CR 的基础。您可以将安装 CR 应用到 hub 集群，如 "Installing a single managed cluster" 所述。配置 CR 可以在集群安装后应用到集群。

流程

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

      password 和 username 的 base64 编码值

      3

      必须与相关 SiteConfig CR 中配置的命名空间匹配

      4

      Base64 编码的 pull secret

2. 将到 example-sno-secret.yaml 的相对路径添加用于安装集群的 kustomization.yaml 文件中。

流程

1. 编辑 InfraEnv CR 中的 spec.kernelArguments 规格以配置内核参数：

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

   $ ssh -i /path/to/privatekey core@<host_name>

2. 使用以下命令查看系统的内核参数：

   $ cat /proc/cmdline

流程

1. 为要部署的每个特定集群版本创建一个 ClusterImageSet，如 clusterImageSet-4.15.yaml。ClusterImageSet 具有以下格式：

   apiVersion: hive.openshift.io/v1
   kind: ClusterImageSet
   metadata:
     name: openshift-4.15.0 1
   spec:
      releaseImage: quay.io/openshift-release-dev/ocp-release:4.15.0-x86_64 2

   1

   要部署的描述性版本。

   2

   指定要部署并决定操作系统镜像的 releaseImage 版本。发现 ISO 基于由 releaseImage 设置的镜像版本，如果准确版本不可用，则为最新版本。

2. 应用 clusterImageSet CR：

   $ oc apply -f clusterImageSet-4.15.yaml

3. 在 cluster-namespace.yaml 文件中创建 Namespace CR：

   apiVersion: v1
   kind: Namespace
   metadata:
        name: <cluster_name> 1
        labels:
           name: <cluster_name> 2

   1 2

   要置备的受管集群的名称。

4. 运行以下命令来应用 Namespace CR：

   $ oc apply -f cluster-namespace.yaml

5. 应用从 ztp-site-generate 容器中提取的生成的 day-0 CR，并自定义以满足您的要求：

   $ oc apply -R ./site-install/site-sno-1

流程

1. 检查受管集群的状态：

   $ oc get managedcluster

   True 表示受管集群已就绪。

2. 检查代理状态：

   $ oc get agent -n <cluster_name>

3. 使用 describe 命令，提供代理条件的深入描述。支持的状态包括 BackendError、InputError、ValidationsFailing、InFailed 和 AgentIsConnected。这些状态与 Agent 和 AgentClusterInstall 自定义资源相关。

   $ oc describe agent -n <cluster_name>

4. 检查集群置备状态：

   $ oc get agentclusterinstall -n <cluster_name>

5. 使用 describe 命令提供集群置备状态的深入描述：

   $ oc describe agentclusterinstall -n <cluster_name>

6. 检查受管集群的附加服务的状态：

   $ oc get managedclusteraddon -n <cluster_name>

7. 检索受管集群的 kubeconfig 文件的身份验证信息：

   $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

流程

1. 检查受管集群的状态：

   $ oc get managedcluster

   输出示例

   NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
   SNO-cluster     true                                   True     True      2d19h

   如果 AVAILABLE 列中的状态为 True，受管集群由 hub 管理。

   如果 AVAILABLE 列中的状态为 Unknown，则受管集群不会由 hub 管理。使用以下步骤继续检查 以了解更多信息。

2. 检查 AgentClusterInstall 安装状态：

   $ oc get clusterdeployment -n <cluster_name>

   输出示例

   NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
   Sno0026    agent-baremetal                               false                          Initialized
   2d14h

   如果 INSTALLED 列中的状态为 false，则安装会失败。

3. 如果安装失败，请输入以下命令查看 AgentClusterInstall 资源的状态：

   $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>

4. 解决错误并重置集群：

   1. 删除集群的受管集群资源：

      $ oc delete managedcluster <cluster_name>

   2. 删除集群的命名空间：

      $ oc delete namespace <cluster_name>

      这会删除为此集群创建的所有命名空间范围自定义资源。您必须等待 ManagedCluster CR 删除完成，然后才能继续。

   3. 为受管集群重新创建自定义资源。

流程

1. 将 UEFI/BIOS Boot Mode 设置为 UEFI。
2. 在主机引导顺序中，设置 Hard drive first。

3. 为您的硬件应用特定的固件配置。下表描述了 Intel Xeon Skylake 或 Intel Cascade Lake 服务器的代表固件配置，它基于 Intel FlexRAN 4G 和 5G 基带 PHY 参考设计。

   重要

   确切的固件配置取决于您的特定硬件和网络要求。以下示例配置仅用于说明目的。

   表 7.2. Intel Xeon Skylake 或 Cascade Lake 服务器的固件配置示例

   固件设置	配置
   CPU Power 和性能策略	性能
   非核心频率扩展	Disabled
   性能限制	Disabled
   增强的 Intel SpeedStep ® Tech	Enabled
   Intel 配置的 TDP	Enabled
   可配置 TDP 级别	2 级
   Intel® Turbo Boost Technology	Enabled
   节能 Turbo	Disabled
   硬件 P-State	Disabled
   软件包 C-State	C0/C1 状态
   C1E	Disabled
   处理器 C6	Disabled

流程

1. 检查默认 OperatorHub 源是否已禁用。运行以下命令:

   $ oc get operatorhub cluster -o yaml

   输出示例

   spec:
       disableAllDefaultSources: true

2. 运行以下命令，检查所有所需的 CatalogSource 资源是否标注了工作负载分区 (PreferredDuringScheduling)：

   $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

   输出示例

   certified-operators -- {"effect": "PreferredDuringScheduling"}
   community-operators -- {"effect": "PreferredDuringScheduling"}
   ran-operators 1
   redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
   redhat-operators -- {"effect": "PreferredDuringScheduling"}

   1

   未注解的 CatalogSource 资源也会返回。在本例中，ran-operators CatalogSource 资源没有被注解，它没有 PreferredDuringScheduling 注解。

   注意

   在正确配置的 vDU 集群中，只会列出注解的一个目录源。

3. 检查是否为工作负载分区注解了所有适用的 OpenShift Container Platform Operator 命名空间。这包括 OpenShift Container Platform 核心安装的所有 Operator，以及参考 DU 调整配置中包含的附加 Operator 集合。运行以下命令:

   $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

   输出示例

   default --
   openshift-apiserver -- management
   openshift-apiserver-operator -- management
   openshift-authentication -- management
   openshift-authentication-operator -- management

   重要

   对于工作负载分区，不得为其他 Operator 进行注解。在上一命令的输出中，应当列出额外的 Operator，而无需 -- 分隔符右侧的任何值。

4. 检查 ClusterLogging 配置是否正确。运行以下命令：

   1. 验证是否配置了适当的输入和输出日志：

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      输出示例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

   2. 检查策展调度是否适合您的应用程序：

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      输出示例

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

5. 运行以下命令，检查 Web 控制台是否已禁用 (managementState: Removed)：

   $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

   输出示例

   Removed

6. 运行以下命令，检查集群节点中禁用了 chronyd ：

   $ oc debug node/<node_name>

   检查节点上的 chronyd 状态：

   sh-4.4# chroot /host

   sh-4.4# systemctl status chronyd

   输出示例

   ● chronyd.service - NTP client/server
       Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled)
       Active: inactive (dead)
         Docs: man:chronyd(8)
               man:chrony.conf(5)

7. 使用连接到 linuxptp-daemon 容器和 PTP Management Client (pmc) 工具，检查 PTP 接口是否已成功同步到主时钟：

   1. 运行以下命令，使用 linuxptp-daemon pod 的名称设置 $PTP_POD_NAME 变量：

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)

   2. 运行以下命令来检查 PTP 设备的同步状态：

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'

      输出示例

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

   3. 运行以下 pmc 命令来检查 PTP 时钟状态：

      $ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'

      输出示例

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1

      master_offset 应该介于 -100 到 100 ns 之间。

      2

      这表示 PTP 时钟被同步到 master，本地时钟不是 grandmaster 时钟。

   4. 检查在 linuxptp-daemon-container 日志中有与 /var/run/ptp4l.0.config 中的值对应的 master offset ：

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      输出示例

      phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset  -1731092 s2 freq -1546242 delay    497
      ptp4l[56020.390]: [ptp4l.1.config] master offset         -2 s2 freq   -5863 path delay       541
      ptp4l[56020.390]: [ptp4l.0.config] master offset         -8 s2 freq  -10699 path delay       533

8. 运行以下命令检查 SR-IOV 配置是否正确：

   1. 检查 SriovOperatorConfig 资源中的 disableDrain 值是否已设置为 true ：

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      输出示例

      true

   2. 运行以下命令，检查 SriovNetworkNodeState 同步状态是否为 Succeeded ：

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      输出示例

      Succeeded

   3. 验证为 SR-IOV 配置的每个接口下的虚拟功能（Vfs）预期数量和配置是否存在，并在 .status.interfaces 字段中是正确的。例如：

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      输出示例

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

9. 检查集群性能配置集是否正确。cpu 和 hugepages 部分将根据您的硬件配置而有所不同。运行以下命令:

   $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

   输出示例

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     creationTimestamp: "2022-07-19T21:51:31Z"
     finalizers:
     - foreground-deletion
     generation: 1
     name: openshift-node-performance-profile
     resourceVersion: "33558"
     uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
   spec:
     additionalKernelArgs:
     - idle=poll
     - rcupdate.rcu_normal_after_boot=0
     - efi=runtime
     cpu:
       isolated: 2-51,54-103
       reserved: 0-1,52-53
     hugepages:
       defaultHugepagesSize: 1G
       pages:
       - count: 32
         size: 1G
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/master: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/master: ""
     numa:
       topologyPolicy: restricted
     realTimeKernel:
       enabled: true
   status:
     conditions:
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Available
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "True"
       type: Upgradeable
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Progressing
     - lastHeartbeatTime: "2022-07-19T21:51:31Z"
       lastTransitionTime: "2022-07-19T21:51:31Z"
       status: "False"
       type: Degraded
     runtimeClass: performance-openshift-node-performance-profile
     tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

   注意

   CPU 设置取决于服务器上可用的内核数，应当与工作负载分区设置保持一致。巨页配置取决于服务器和应用程序。

10. 运行以下命令，检查 PerformanceProfile 是否已成功应用到集群：

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    输出示例

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

11. 运行以下命令检查 Tuned 性能补丁设置：

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    输出示例

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1

    cmdline=nohz_full= 中的 cpu 列表将根据您的硬件配置而有所不同。

12. 运行以下命令，检查是否禁用了集群网络诊断：

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    输出示例

    true

13. 检查 Kubelet housekeeping 间隔是否调整为较慢的速度。这是在 containerMountNS 机器配置中设置的。运行以下命令:

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    输出示例

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

14. 运行以下命令，检查 Grafana 和 alertManagerMain 是否已禁用，Prometheus 保留周期是否已设置为 24h：

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    输出示例

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. 使用以下命令验证集群中没有找到 Grafana 和 alertManagerMain 路由：

       $ oc get route -n openshift-monitoring alertmanager-main

       $ oc get route -n openshift-monitoring grafana

       这两个查询都应返回 Error from server(NotFound) 消息。

15. 运行以下命令，检查是否已为每个 PerformanceProfile、Tuned 性能补丁、工作负载分区和内核命令行参数分配至少 4 个保留 CPU：

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    输出示例

    0-3

    注意

    根据您的工作负载要求，您可能需要分配额外的保留 CPU。

流程

1. 创建 GitOps ZTP 管道用于自定义集群安装的一组额外清单 CR。

2. 在自定义 /siteconfig 目录中，为您的额外清单创建一个子目录 /custom-manifest。以下示例演示了一个带有 /custom-manifest 文件夹的 /siteconfig 示例：

   siteconfig
   ├── site1-sno-du.yaml
   ├── site2-standard-du.yaml
   ├── extra-manifest/
   └── custom-manifest
       └── 01-example-machine-config.yaml

   注意

   整个使用的子目录名称 /custom-manifest 和 /extra-manifest 只是示例名称。不需要使用这些名称，并且对如何命名这些子目录没有限制。在本例中，/extra-manifest 是指从 ztp-site-generate 容器存储 /extra-manifest 的内容的 Git 子目录。

3. 将自定义额外清单 CR 添加到 siteconfig/custom-manifest 目录中。

4. 在 SiteConfig CR 中，在 extraManifests.searchPaths 字段中输入目录名称，例如：

   clusters:
   - clusterName: "example-sno"
     networkType: "OVNKubernetes"
     extraManifests:
       searchPaths:
         - extra-manifest/ 1
         - custom-manifest/ 2

   1

   从 ztp-site-generate 容器复制的清单的文件夹。

   2

   自定义清单的文件夹。

5. 保存 SiteConfig、/extra-manifest 和 /custom-manifest CR，并将它们推送到站点配置存储库。

流程

1. 要防止 GitOps ZTP 管道应用 03-sctp-machine-config-worker.yaml CR 文件，请在 SiteConfig CR 中应用以下 YAML：

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "site1-sno-du"
     namespace: "site1-sno-du"
   spec:
     baseDomain: "example.com"
     pullSecretRef:
       name: "assisted-deployment-pull-secret"
     clusterImageSetNameRef: "openshift-4.15"
     sshPublicKey: "<ssh_public_key>"
     clusters:
   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         exclude:
           - 03-sctp-machine-config-worker.yaml

   GitOps ZTP 管道在安装过程中跳过 03-sctp-machine-config-worker.yaml CR。应用 /source-crs/extra-manifest 中的所有其他 CR。

2. 保存 SiteConfig CR，并将更改推送到站点配置存储库。

   GitOps ZTP 管道监控并调整根据 SiteConfig 过滤器指令所应用的 CR。

3. 可选： 要防止 GitOps ZTP 管道在集群中应用所有 /source-crs/extra-manifest CR，请在 SiteConfig CR 中应用以下 YAML：

   - clusterName: "site1-sno-du"
     extraManifests:
       filter:
         inclusionDefault: exclude

4. 可选： 要排除所有 /source-crs/extra-manifest RAN CR，并在安装过程中包括自定义 CR 文件，编辑自定义 SiteConfig CR 来设置自定义清单文件夹和 include 文件，例如：

   clusters:
   - clusterName: "site1-sno-du"
     extraManifestPath: "<custom_manifest_folder>" 1
     extraManifests:
       filter:
         inclusionDefault: exclude  2
         include:
           - custom-sctp-machine-config-worker.yaml

   1

   将 <custom_manifest_folder> 替换为包含自定义安装 CR 的文件夹名称，如 user-custom-manifest/。

   2

   将 inclusionDefault 设置为 exclude 以防止 GitOps ZTP 管道在安装过程中应用 /source-crs/extra-manifest 中的文件。

   以下示例演示了自定义文件夹结构：

   siteconfig
     ├── site1-sno-du.yaml
     └── user-custom-manifest
           └── custom-sctp-machine-config-worker.yaml

流程

1. 更新 SiteConfig CR，使其包含 bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true 注解：

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     Clusters:
       nodes:
       - hostname: node6
         role: "worker"
         crAnnotations:
           add:
             BareMetalHost:
               bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
   # ...

2. 通过更新 SiteConfig CR 使其包含 crSuppression. BareMetalHost 注解来抑制 BareMetalHost CR 的生成：

   apiVersion: ran.openshift.io/v1
   kind: SiteConfig
   metadata:
     name: "cnfdf20"
     namespace: "cnfdf20"
   spec:
     clusters:
     - nodes:
       - hostName: node6
         role: "worker"
         crSuppression:
         - BareMetalHost
   # ...

3. 将更改推送到 Git 存储库并等待取消置备启动。BareMetalHost CR 的状态应更改为 deprovisioning。等待 BareMetalHost 完成取消置备，并完全删除。

验证

1. 运行以下命令，验证 worker 节点的 BareMetalHost 和 Agent CR 已从 hub 集群中删除：

   $ oc get bmh -n <cluster-ns>

   $ oc get agent -n <cluster-ns>

2. 运行以下命令，验证节点记录是否已从 spoke 集群中删除：

   $ oc get nodes

   注意

   如果使用 secret，删除 secret 太早可能会导致问题，因为 ArgoCD 需要 secret 在删除后完成重新同步。只有在当前 ArgoCD 同步完成后，仅在节点清理后删除 secret。

流程

1. 查看基准源 CR 以查找现有内容。您可以通过从 GitOps Zero Touch Provisioning (ZTP) 容器中提取引用 PolicyGenTemplate CR 中列出的源 CR。

   1. 创建 /out 文件夹：

      $ mkdir -p ./out

   2. 提取源 CR：

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.15.1 extract /home/ztp --tar | tar x -C ./out

2. 查看 ./out/source-crs/PerformanceProfile.yaml 中的基线 PerformanceProfile CR：

   apiVersion: performance.openshift.io/v2
   kind: PerformanceProfile
   metadata:
     name: $name
     annotations:
       ran.openshift.io/ztp-deploy-wave: "10"
   spec:
     additionalKernelArgs:
     - "idle=poll"
     - "rcupdate.rcu_normal_after_boot=0"
     cpu:
       isolated: $isolated
       reserved: $reserved
     hugepages:
       defaultHugepagesSize: $defaultHugepagesSize
       pages:
         - size: $size
           count: $count
           node: $node
     machineConfigPoolSelector:
       pools.operator.machineconfiguration.openshift.io/$mcp: ""
     net:
       userLevelNetworking: true
     nodeSelector:
       node-role.kubernetes.io/$mcp: ''
     numa:
       topologyPolicy: "restricted"
     realTimeKernel:
       enabled: true

   注意

   如果 PolicyGenTemplate CR 中未提供，则包含 $…​ 的任何字段都会从生成的 CR 中删除。

3. 在 group-du-sno-ranGen.yaml 参考文件中为 PerformanceProfile 更新 PolicyGenTemplate 条目。以下示例 PolicyGenTemplate CR 小节提供了适当的 CPU 规格，设置 hugepages 配置，并添加一个新的字段，将 globallyDisableIrqLoadBalancing 设置为 false。

   - fileName: PerformanceProfile.yaml
     policyName: "config-policy"
     metadata:
       name: openshift-node-performance-profile
     spec:
       cpu:
         # These must be tailored for the specific hardware platform
         isolated: "2-19,22-39"
         reserved: "0-1,20-21"
       hugepages:
         defaultHugepagesSize: 1G
         pages:
           - size: 1G
             count: 10
       globallyDisableIrqLoadBalancing: false

4. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到由 GitOps ZTP argo CD 应用程序监控的 Git 存储库。

流程

1. 在目录中创建一个名为 source-crs 的子目录，其中包含 PolicyGenTemplate 自定义资源(CR)的 kustomization.yaml 文件。

2. 将用户提供的 CR 添加到 source-crs 子目录中，如下例所示：

   example
   └── policygentemplates
       ├── dev.yaml
       ├── kustomization.yaml
       ├── mec-edge-sno1.yaml
       ├── sno.yaml
       └── source-crs 1
           ├── PaoCatalogSource.yaml
           ├── PaoSubscription.yaml
           ├── custom-crs
           |   ├── apiserver-config.yaml
           |   └── disable-nic-lldp.yaml
           └── elasticsearch
               ├── ElasticsearchNS.yaml
               └── ElasticsearchOperatorGroup.yaml

   1

   source-crs 子目录必须与 kustomization.yaml 文件位于同一个目录中。

3. 更新所需的 PolicyGenTemplate CR，使其包含对 source-crs/custom-crs 和 source-crs/elasticsearch 目录中添加的内容的引用。例如：

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-dev"
     namespace: "ztp-clusters"
   spec:
     bindingRules:
       dev: "true"
     mcp: "master"
     sourceFiles:
       # These policies/CRs come from the internal container Image
       #Cluster Logging
       - fileName: ClusterLogNS.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-ns"
       - fileName: ClusterLogOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-operator-group"
       - fileName: ClusterLogSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-cluster-log-sub"
       #Local Storage Operator
       - fileName: StorageNS.yaml
         remediationAction: inform
         policyName: "group-dev-lso-ns"
       - fileName: StorageOperGroup.yaml
         remediationAction: inform
         policyName: "group-dev-lso-operator-group"
       - fileName: StorageSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-lso-sub"
       #These are custom local polices that come from the source-crs directory in the git repo
       # Performance Addon Operator
       - fileName: PaoSubscriptionNS.yaml
         remediationAction: inform
         policyName: "group-dev-pao-ns"
       - fileName: PaoSubscriptionCatalogSource.yaml
         remediationAction: inform
         policyName: "group-dev-pao-cat-source"
         spec:
           image: <image_URL_here>
       - fileName: PaoSubscription.yaml
         remediationAction: inform
         policyName: "group-dev-pao-sub"
       #Elasticsearch Operator
       - fileName: elasticsearch/ElasticsearchNS.yaml 1
         remediationAction: inform
         policyName: "group-dev-elasticsearch-ns"
       - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
         remediationAction: inform
         policyName: "group-dev-elasticsearch-operator-group"
       #Custom Resources
       - fileName: custom-crs/apiserver-config.yaml 2
         remediationAction: inform
         policyName: "group-dev-apiserver-config"
       - fileName: custom-crs/disable-nic-lldp.yaml
         remediationAction: inform
         policyName: "group-dev-disable-nic-lldp"

   1 2

   将 fileName 设置为包含 /source-crs 父目录中文件的相对路径。

4. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到由 GitOps ZTP Argo CD 策略应用程序监控的 Git 存储库。

5. 更新 ClusterGroupUpgrade CR，使其包含更改的 PolicyGenTemplate，并将它保存为 cgu-test.yaml。以下示例显示了生成的 cgu-test.yaml 文件。

   apiVersion: ran.openshift.io/v1alpha1
   kind: ClusterGroupUpgrade
   metadata:
     name: custom-source-cr
     namespace: ztp-clusters
   spec:
     managedPolicies:
       - group-dev-config-policy
     enable: true
     clusters:
     - cluster1
     remediationStrategy:
       maxConcurrency: 2
       timeout: 240

6. 运行以下命令来应用更新的 ClusterGroupUpgrade CR：

   $ oc apply -f cgu-test.yaml

流程

1. 要为 PolicyGenTemplate CR 中的所有策略配置评估间隔，请将 evaluationInterval 添加到 spec 字段中，然后设置适当的 compliant 和 noncompliant 的值。例如：

   spec:
     evaluationInterval:
       compliant: 30m
       noncompliant: 20s

2. 要在 PolicyGenTemplate CR 中为 spec.sourceFiles 对象配置评估间隔，请将 evaluationInterval 添加到 sourceFiles 字段中，例如：

   spec:
     sourceFiles:
      - fileName: SriovSubscription.yaml
        policyName: "sriov-sub-policy"
        evaluationInterval:
          compliant: never
          noncompliant: 10s

3. 在 Git 存储库中提交 PolicyGenTemplate CR 文件并推送您的更改。

1. 在受管集群中以具有 cluster-admin 权限的用户身份登录。

2. 获取在 open-cluster-management-agent-addon 命名空间中运行的 pod。运行以下命令:

   $ oc get pods -n open-cluster-management-agent-addon

   输出示例

   NAME                                         READY   STATUS    RESTARTS        AGE
   config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

3. 检查应用的策略是以 config-policy-controller pod 的日志中预期间隔评估：

   $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

   输出示例

   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
   2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

流程

1. 创建包含源文件 validatorCR/informDuValidator.yaml 的独立 PolicyGenTemplate 自定义资源 (CR)。每个集群类型只需要一个独立 PolicyGenTemplate CR。例如，此 CR 为单节点 OpenShift 集群应用验证器通知策略：

   Example single-node cluster validator inform policy CR (group-du-sno-validator-ranGen.yaml)

   apiVersion: ran.openshift.io/v1
   kind: PolicyGenTemplate
   metadata:
     name: "group-du-sno-validator" 1
     namespace: "ztp-group" 2
   spec:
     bindingRules:
       group-du-sno: "" 3
     bindingExcludedRules:
       ztp-done: "" 4
     mcp: "master" 5
     sourceFiles:
       - fileName: validatorCRs/informDuValidator.yaml
         remediationAction: inform 6
         policyName: "du-policy" 7

   1

   PolicyGenTemplates 对象的名称。此名称也用作在请求的 namespace 中创建的 placementBinding、placementRule 和 policy 的一部分。

   2

   这个值应该与组 PolicyGenTemplates 中使用的命名空间匹配。

   3

   bindingRules 中定义的 group-du-* 标签必须存在于 SiteConfig 文件中。

   4

   bindingExcludedRules 中定义的标签必须是'ztp-done:'。ztp-done 标签用于与 Topology Aware Lifecycle Manager 协调。

   5

   mcp 定义在源文件 validatorCR/informDuValidator.yaml 中使用的 MachineConfigPool 对象。它应该是单一节点的 master，以及用于标准集群部署的三节点集群部署和 worker。

   6

   可选。默认值是 inform。

   7

   这个值被用作生成的 RHACM 策略的名称的一部分。单一节点示例生成的验证器策略是 group-du-sno-validator-du-policy。

2. 在 Git 存储库中提交 PolicyGenTemplate CR 文件并推送更改。

流程

1. 要为新受管集群配置 LVM Storage，请在 common-ranGen.yaml 文件中的 spec.sourceFiles 中添加以下 YAML：

   - fileName: StorageLVMOSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMOSubscription.yaml
     spec:
       name: lvms-operator
       channel: stable-4.15
     policyName: subscription-policies

   注意

   Storage LVMO 订阅已弃用。在以后的 OpenShift Container Platform 版本中，存储 LVMO 订阅将不可用。反之，您必须使用 Storage LVMS 订阅。

   在 OpenShift Container Platform 4.15 中，您可以使用 Storage LVMS 订阅而不是 LVMO 订阅。LVMS 订阅不需要在 common-ranGen.yaml 文件中手动覆盖。将以下 YAML 添加到 common-ranGen.yaml 文件中的 spec.sourceFiles 中，以使用 Storage LVMS 订阅：

   - fileName: StorageLVMSubscriptionNS.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscriptionOperGroup.yaml
     policyName: subscription-policies
   - fileName: StorageLVMSubscription.yaml
     policyName: subscription-policies

2. 将 LVMCluster CR 添加到特定组或单个站点配置文件中的 spec.sourceFiles 中。例如，在 group-du-sno-ranGen.yaml 文件中添加以下内容：

   - fileName: StorageLVMCluster.yaml
     policyName: "lvms-config" 1
     spec:
       storage:
         deviceClasses:
         - name: vg1
           thinPoolConfig:
             name: thin-pool-1
             sizePercent: 90
             overprovisionRatio: 10

   1

   这个示例配置创建一个带有所有可用设备的卷组 (vg1)，但安装了 OpenShift Container Platform 的磁盘除外。也创建了一个精简池逻辑卷。

3. 将任何其他必要的更改和文件与自定义站点存储库合并。
4. 提交 Git 中的 PolicyGenTemplate 更改，然后将更改推送到站点配置存储库，以使用 GitOps ZTP 将 LVM 存储部署到新站点。

流程

1. 在 OpenShift Container Platform Web 控制台中导航至 Operators → OperatorHub。
2. 从可用的 Operator 列表中选择 Topology Aware Lifecycle Manager，然后点 Install。
3. 保持默认的选择 Installation mode ["All namespaces on the cluster (default)"] 和 Installed Namespace ("openshift-operators") 以确保 Operator 已正确安装。
4. 点 Install。

1. 进入到 Operators → Installed Operators 页面。
2. 检查 Operator 是否在 All Namespaces 命名空间中，其状态为 Succeeded。

1. 导航到 Operators → Installed Operators 页面，并检查 Status 列中是否有任何错误或故障。
2. 进入到 Workloads → Pods 页面，检查 cluster-group-upgrades-controller-manager pod 中报告问题的容器日志。

流程

1. 创建一个 Subscription CR：

   1. 定义 Subscription CR 并保存 YAML 文件，如 talm-subscription.yaml ：

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace

   2. 运行以下命令来创建 Subscription CR：

      $ oc create -f talm-subscription.yaml

验证

1. 检查 CSV 资源来验证安装是否成功：

   $ oc get csv -n openshift-operators

   输出示例

   NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
   topology-aware-lifecycle-manager.4.15.x   Topology Aware Lifecycle Manager   4.15.x                                      Succeeded

2. 验证 TALM 是否正在运行：

   $ oc get deploy -n openshift-operators

   输出示例

   NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
   openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s