边缘计算

流程

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.16.1-x86_64-live.x86_64.iso

      1

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

      1

      OpenShift Container Platform 版本，如 4.16.1

   2. 下载所需的镜像：

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

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.16/${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.16"
       rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
       url: https://<host>/<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> 3
         url: <iso_url> 4

   1

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

   2

   设置 mirrorRegistryRef.name，以匹配相关 ConfigMap CR 中指定的定义。

   3

   将 OpenShift Container Platform 版本设置为 x.y 或 x.y.z 格式。

   4

   设置托管在 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 和 PolicyGenerator 或 PolicyGentemplate CR 的路径。

2. 要安装 GitOps ZTP 插件，使用相关多集群引擎 (MCE) 订阅镜像对 hub 集群中的 ArgoCD 实例进行补丁。自定义您解压到环境的 out/argocd/deployment/ 目录中的补丁文件。

   1. 选择与您的 RHACM 版本匹配的 multicluster-operators-subscription 镜像。

      • 对于 RHACM 2.8 和 2.9，请使用 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version> 镜像。
      • 对于 RHACM 2.10 及更高版本，请使用 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version> 镜像。
      重要

      multicluster-operators-subscription 镜像的版本必须与 RHACM 版本匹配。从 MCE 2.10 发行版本开始，RHEL 9 是 multicluster-operators-subscription 镜像的基础镜像。

      在 OpenShift Operator 生命周期中的"Platform Aligned Operators"表中点 [Expand for Operator list] 查看 OpenShift Container Platform 的完整支持的 Operator 列表。

   2. 使用与您的 RHACM 版本匹配的 multicluster-operators-subscription 镜像来修改 out/argocd/deployment/argocd-openshift-gitops-patch.json 文件：

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      可选： 对于 RHEL 9 镜像，在 ArgoCD 版本的 /policy-generator/PolicyGenerator-not-fips-compliant 文件夹中复制所需的通用可执行文件。

      2

      将 multicluster-operators-subscription 镜像与 RHACM 版本匹配。

      3

      在断开连接的环境中，将 multicluster-operators-subscription 镜像的 URL 替换为与您的环境中使用的断开连接的 registry。

   3. 对 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

5. 可选：如果您已有 ArgoCD 应用程序，请运行以下命令验证在 应用程序资源 中设置 PrunePropagationPolicy=background 策略：

   $ oc -n openshift-gitops get applications.argoproj.io  \
   clusters -o jsonpath='{.spec.syncPolicy.syncOptions}' |jq

   现有策略的输出示例

   [
     "CreateNamespace=true",
     "PrunePropagationPolicy=background",
     "RespectIgnoreDifferences=true"
   ]

   1. 如果 spec.syncPolicy.syncOption 字段不包含 PrunePropagationPolicy 参数，或 PrunePropagationPolicy 设置为 foreground 值，请在 Application 资源中将策略设置为 后台。请参见以下示例：

      kind: Application
      spec:
        syncPolicy:
          syncOptions:
          - PrunePropagationPolicy=background

   设置 后台 删除策略可确保 ManagedCluster CR 及其所有相关资源都被删除。

流程

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

   注意

   将 SiteConfig 和 PolicyGenerator，或 PolicyGentemplate CR 保留在单独的目录中。SiteConfig 和 PolicyGenerator，或 PolicyGentemplate 目录必须包含一个 kustomization.yaml 文件，该文件明确包含该目录中的文件。

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

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

   $ mkdir -p ./out

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

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

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

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

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

   1

   使用 PolicyGenTemplate CR 管理和部署策略来管理集群将在以后的 OpenShift Container Platform 发行版本中弃用。使用 Red Hat Advanced Cluster Management (RHACM) 和 PolicyGenerator CR 提供了等效和改进的功能。

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

流程

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

2. 在 PolicyGenerator 目录中，为您要提供的每个 OpenShift Container Platform 版本创建一个目录。对于每个版本，创建以下资源：

   • 明确包含该目录中文件的 kustomization.yaml 文件

   • source-crs 目录，其中包含 ztp-site-generate 容器中的引用 CR 配置文件

     如果要使用用户提供的 CR，必须为它们创建一个单独的目录。

3. 在 /siteconfig 目录中，为您要提供的每个 OpenShift Container Platform 版本创建一个子目录。对于每个版本，至少创建一个目录，用于从容器中复制引用 CR。对目录命名或引用目录数量没有限制。如果要使用自定义清单，必须为它们创建单独的目录。

   以下示例描述了对不同 OpenShift Container Platform 版本使用用户提供的清单和 CR 的结构：

   ├── acmpolicygenerator
   │   ├── kustomization.yaml 1
   │   ├── version_4.13 2
   │   │   ├── common-ranGen.yaml
   │   │   ├── group-du-sno-ranGen.yaml
   │   │   ├── group-du-sno-validator-ranGen.yaml
   │   │   ├── helix56-v413.yaml
   │   │   ├── kustomization.yaml 3
   │   │   ├── ns.yaml
   │   │   └── source-crs/ 4
   │   │      └── reference-crs/ 5
   │   │      └── custom-crs/ 6
   │   └── version_4.14 7
   │       ├── common-ranGen.yaml
   │       ├── group-du-sno-ranGen.yaml
   │       ├── group-du-sno-validator-ranGen.yaml
   │       ├── helix56-v414.yaml
   │       ├── kustomization.yaml 8
   │       ├── ns.yaml
   │       └── source-crs/ 9
   │         └── reference-crs/ 10
   │         └── custom-crs/ 11
   └── siteconfig
       ├── kustomization.yaml
       ├── version_4.13
       │   ├── helix56-v413.yaml
       │   ├── kustomization.yaml
       │   ├── extra-manifest/ 12
       │   └── custom-manifest/ 13
       └── version_4.14
           ├── helix57-v414.yaml
           ├── kustomization.yaml
           ├── extra-manifest/ 14
           └── custom-manifest/ 15

   1

   创建顶级 kustomization YAML 文件。

   2 7

   在自定义 /acmpolicygenerator 目录中创建特定于版本的目录。

   3 8

   为每个版本创建一个 kustomization.yaml 文件。

   4 9

   为每个版本创建一个 source-crs 目录，使其包含 ztp-site-generate 容器中的引用 CR。

   5 10

   为从 ZTP 容器中提取的策略 CR 创建 reference-crs 目录。

   6 11

   可选：为用户提供的 CR 创建一个 custom-crs 目录。

   12 14

   在自定义 /siteconfig 目录中创建一个目录，使其包含 ztp-site-generate 容器的额外清单。

   13 15

   创建用于存放用户提供的清单的文件夹。

   注意

   在上例中，自定义 /siteconfig 目录中的每个版本子目录包含两个进一步的子目录，一个子目录包含从容器中复制的引用清单，另一个用于您提供的自定义清单。分配给这些目录的名称是示例。如果使用用户提供的 CR，则 SiteConfig CR 中的 extraManifests.searchPaths 下列出的最后一个目录必须是包含用户提供的 CR 的目录。

4. 编辑 SiteConfig CR，使其包含您创建的任何目录的搜索路径。extraManifests.searchPaths 下列出的第一个目录必须是包含引用清单的目录。考虑列出目录的顺序。如果目录包含相同名称的文件，则最终目录中的文件将具有优先权。

   SiteConfig CR 示例

   extraManifests:
       searchPaths:
       - extra-manifest/ 1
       - custom-manifest/ 2

   1

   包含引用清单的目录必须首先列在 extraManifests.searchPaths 下。

   2

   如果您使用用户提供的 CR，则 SiteConfig CR 中的 extraManifests.searchPaths 下列出的最后一个目录必须是包含这些用户提供的 CR 的目录。

5. 编辑顶级 kustomization.yaml 文件，以控制哪些 OpenShift Container Platform 版本处于活跃状态。以下是顶层的 kustomization.yaml 文件示例：

   resources:
   - version_4.13 1
   #- version_4.14 2

   1

   激活版本 4.13。

   2

   使用注释取消激活版本。

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.16 extract /home/ztp --tar | tar x -C ./update

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

   • update/extra-manifest: 包含 SiteConfig CR 用来生成额外清单 configMap 的源 CR 文件。
   • update/source-crs ：包含 PolicyGenerator 或 PolicyGentemplate CR 用于生成 Red Hat Advanced Cluster Management (RHACM) 策略的源 CR 文件。
   • update/argocd/deployment: 包含要在 hub 集群上应用的补丁和 YAML 文件，以便在此过程的下一步中使用。
   • update/argocd/example: 包含代表推荐的配置的 SiteConfig 和 PolicyGenerator，或 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 插件，使用相关多集群引擎 (MCE) 订阅镜像对 hub 集群中的 ArgoCD 实例进行补丁。自定义您解压到环境的 out/argocd/deployment/ 目录中的补丁文件。

   1. 选择与您的 RHACM 版本匹配的 multicluster-operators-subscription 镜像。

      • 对于 RHACM 2.8 和 2.9，请使用 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v<rhacm_version> 镜像。
      • 对于 RHACM 2.10 及更高版本，请使用 registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v<rhacm_version> 镜像。
      重要

      multicluster-operators-subscription 镜像的版本必须与 RHACM 版本匹配。从 MCE 2.10 发行版本开始，RHEL 9 是 multicluster-operators-subscription 镜像的基础镜像。

      在 OpenShift Operator 生命周期中的"Platform Aligned Operators"表中点 [Expand for Operator list] 查看 OpenShift Container Platform 的完整支持的 Operator 列表。

   2. 使用与您的 RHACM 版本匹配的 multicluster-operators-subscription 镜像来修改 out/argocd/deployment/argocd-openshift-gitops-patch.json 文件：

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }

      1

      可选： 对于 RHEL 9 镜像，在 ArgoCD 版本的 /policy-generator/PolicyGenerator-not-fips-compliant 文件夹中复制所需的通用可执行文件。

      2

      将 multicluster-operators-subscription 镜像与 RHACM 版本匹配。

      3

      在断开连接的环境中，将 multicluster-operators-subscription 镜像的 URL 替换为与您的环境中使用的断开连接的 registry。

   3. 对 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 get applications.argoproj.io -n openshift-gitops clusters -o yaml

   1. 要识别受管集群的错误日志，请检查 status.operationState.syncResult.resources 字段。例如，如果为 SiteConfig CR 中的 extraManifestPath 分配了一个无效的值，则会生成类似如下的错误：

      syncResult:
        resources:
        - group: ran.openshift.io
          kind: SiteConfig
          message: The Kubernetes API could not find ran.openshift.io/SiteConfig for
            requested resource spoke-sno/spoke-sno. Make sure the "SiteConfig" CRD is
            installed on the destination cluster

   2. 要查看更详细的 SiteConfig 错误，请完成以下步骤：

      1. 在 Argo CD 仪表板中，点 Argo CD 试图同步的 SiteConfig 资源。

      2. 选中 DESIRED MANIFEST 选项卡，以查找 siteConfigError 字段。

         siteConfigError: >- Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-1081291903: stat sno-extra-manifest: no such file or directory

   3. 检查 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 或 PolicyGentemplate 文件来删除站点和相关的 CR。

2. 在您的 SiteConfig 应用程序中添加以下 syncOptions 字段。

   kind: Application
   spec:
     syncPolicy:
       syncOptions:
       - PrunePropagationPolicy=background

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

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

流程

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

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

   注意

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

4. 可选：作为替代方案，在更改生成过时策略的 PolicyGenerator 或 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. 运行以下命令来创建输出文件夹：

   $ mkdir -p ./out

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

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

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

   输出示例

   out
    └── argocd
         └── example
              ├── acmpolicygenerator
              │     ├── {policy-prefix}common-ranGen.yaml
              │     ├── {policy-prefix}example-sno-site.yaml
              │     ├── {policy-prefix}group-du-sno-ranGen.yaml
              │     ├── {policy-prefix}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.16"
     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 the optional set of components.
         # Notes:
         # - OperatorLifecycleManager is needed for 4.15 and later
         # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
         # - Ingress is needed for 4.16 and later
         installConfigOverrides: |
           {
             "capabilities": {
               "baselineCapabilitySet": "None",
               "additionalEnabledCapabilities": [
                 "NodeTuning",
                 "OperatorLifecycleManager",
                 "Ingress"
               ]
             }
           }
         # 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: "latest"
           # 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:
               deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
             # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
             ignitionConfigOverride: |
               {
                 "ignition": {
                   "version": "3.2.0"
                 },
                 "storage": {
                   "disks": [
                     {
                       "device": "/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62",
                       "partitions": [
                         {
                           "label": "var-lib-containers",
                           "sizeMiB": 0,
                           "startMiB": 250000
                         }
                       ],
                       "wipeTable": false
                     }
                   ],
                   "filesystems": [
                     {
                       "device": "/dev/disk/by-partlabel/var-lib-containers",
                       "format": "xfs",
                       "mountOptions": [
                         "defaults",
                         "prjquota"
                       ],
                       "path": "/var/lib/containers",
                       "wipeFilesystem": true
                     }
                   ]
                 },
                 "systemd": {
                   "units": [
                     {
                       "contents": "# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target",
                       "enabled": true,
                       "name": "var-lib-containers.mount"
                     }
                   ]
                 }
               }
             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.16 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.16 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. 使用上一步中的参考 PolicyGenerator CR 生成并导出 day-2 配置 CR。运行以下命令：

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

      $ mkdir -p ./ref

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

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

      该命令在 ./ref 文件夹中为单节点 OpenShift、三节点集群和标准集群生成示例组和特定于站点的 PolicyGenerator 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.16.yaml。ClusterImageSet 具有以下格式：

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

   1

   要部署的描述性版本。

   2

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

2. 应用 clusterImageSet CR：

   $ oc apply -f clusterImageSet-4.16.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 FlexRAN 4G 和 5G 基带 PHY 参考设计。

   重要

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

   表 6.2. 固件配置示例

   固件设置	配置
   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.16"
     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 注解，并将更改推送到 Git 存储库：

   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. 运行以下命令验证 BareMetalHost 对象是否已注解：

   oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'

   输出示例

   true

3. 通过更新 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
   # ...

4. 将更改推送到 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。