×

您可以使用 Red Hat Advanced Cluster Management (RHACM)、辅助服务和 GitOps 插件策略生成器(启用核心简化技术)大规模配置 OpenShift Container Platform 集群。GitOps 零接触配置 (ZTP) 管道执行集群安装。GitOps ZTP 可用于断开连接的环境。

在即将发布的 OpenShift Container Platform 版本中,将弃用使用 `PolicyGenTemplate` CR 来管理和部署到托管集群的策略。可以使用 Red Hat Advanced Cluster Management (RHACM) 和 `PolicyGenerator` CR 来获得等效且改进的功能。

有关 `PolicyGenerator` 资源的更多信息,请参阅 RHACM 策略生成器 文档。

GitOps ZTP 和拓扑感知生命周期管理器

GitOps 零接触配置 (ZTP) 从存储在 Git 中的清单生成安装和配置 CR。这些工件将应用于集中的中心集群,其中 Red Hat Advanced Cluster Management (RHACM)、辅助服务和拓扑感知生命周期管理器 (TALM) 使用 CR 来安装和配置托管集群。GitOps ZTP 管道的配置阶段使用 TALM 来协调将配置 CR 应用于集群。GitOps ZTP 和 TALM 之间存在几个关键集成点。

信息策略

默认情况下,GitOps ZTP 使用 `inform` 修复操作创建所有策略。这些策略使 RHACM 报告与策略相关的集群的合规性状态,但不应用所需的配置。在 GitOps ZTP 过程期间,OpenShift 安装后,TALM 将逐步执行创建的 `inform` 策略并在目标托管集群上强制执行它们。这会将配置应用于托管集群。在集群生命周期的 GitOps ZTP 阶段之外,这允许您更改策略,而无需立即将这些更改推广到受影响的托管集群。您可以使用 TALM 来控制时间和已修复集群的集合。

自动创建 ClusterGroupUpgrade CR

为了自动化新部署集群的初始配置,TALM 监控中心集群上所有ManagedCluster CR 的状态。任何未应用ztp-done标签的ManagedCluster CR(包括新创建的ManagedCluster CR)都会导致 TALM 自动创建一个具有以下特征的ClusterGroupUpgrade CR。

  • ClusterGroupUpgrade CR 在ztp-install命名空间中创建并启用。

  • ClusterGroupUpgrade CR 的名称与ManagedCluster CR 的名称相同。

  • 集群选择器仅包含与该ManagedCluster CR 关联的集群。

  • 托管策略集包括 RHACM 在创建ClusterGroupUpgrade时绑定到集群的所有策略。

  • 预缓存已禁用。

  • 超时设置为 4 小时(240 分钟)。

自动创建已启用的ClusterGroupUpgrade可确保无需用户干预即可进行集群的初始零接触部署。此外,为任何没有ztp-done标签的ManagedCluster自动创建ClusterGroupUpgrade CR,允许通过简单地删除集群的ClusterGroupUpgrade CR 来重新启动失败的 GitOps ZTP 安装。

阶段

PolicyGeneratorPolicyGentemplate CR 生成的每个策略都包含一个ztp-deploy-wave注释。此注释基于包含在该策略中的每个 CR 的相同注释。波次注释用于对自动生成的ClusterGroupUpgrade CR 中的策略进行排序。除自动生成的ClusterGroupUpgrade CR 外,波次注释不用于其他用途。

同一策略中的所有 CR 必须对ztp-deploy-wave注释具有相同的设置。可以在PolicyGeneratorPolicyGentemplate中覆盖每个 CR 的此注释的默认值。源 CR 中的波次注释用于确定和设置策略波次注释。此注释会在运行时从生成的策略中包含的每个已构建的 CR 中删除。

TALM 按波次注释指定的顺序应用配置策略。TALM 等待每个策略符合要求后才移至下一个策略。务必确保每个 CR 的波次注释考虑了将这些 CR 应用于集群的任何先决条件。例如,必须在安装操作符之前或与其同时安装操作符。同样,操作符的CatalogSource必须在操作符订阅之前或与其同时安装在一个波次中。每个 CR 的默认波次值都考虑了这些先决条件。

多个 CR 和策略可以共享相同的波次编号。策略越少,部署速度越快,CPU 使用率越低。最佳实践是将许多 CR 分组到相对较少的波次中。

要检查每个源 CR 中的默认波次值,请对从ztp-site-generate容器镜像中提取的out/source-crs目录运行以下命令。

$ grep -r "ztp-deploy-wave" out/source-crs
阶段标签

ClusterGroupUpgrade CR 会自动创建,并包含在 GitOps ZTP 过程开始和结束时使用标签注释ManagedCluster CR 的指令。

当 GitOps ZTP 配置安装后开始时,ManagedCluster将应用ztp-running标签。当所有策略都被修复到集群并且完全符合要求时,这些指令会导致 TALM 删除ztp-running标签并应用ztp-done标签。

对于使用informDuValidator策略的部署,当集群完全准备好部署应用程序时,将应用ztp-done标签。这包括所有协调以及 GitOps ZTP 应用的配置 CR 的所有结果影响。ztp-done标签会影响 TALM 自动创建的ClusterGroupUpgrade CR。在集群的初始 GitOps ZTP 安装后,请勿操作此标签。

关联的 CR

自动创建的ClusterGroupUpgrade CR 将所有者引用设置为其派生的ManagedCluster。此引用确保删除ManagedCluster CR 会导致ClusterGroupUpgrade实例及其任何支持资源一起被删除。

使用 GitOps ZTP 部署托管集群概述

Red Hat Advanced Cluster Management (RHACM) 使用 GitOps 零接触配置 (ZTP) 部署单节点 OpenShift Container Platform 集群、三节点集群和标准集群。您可以在 Git 存储库中将站点配置数据管理为 OpenShift Container Platform 自定义资源 (CR)。GitOps ZTP 使用声明式 GitOps 方法,采用“一次开发,随处部署”的模式来部署托管集群。

集群的部署包括:

  • 在空白服务器上安装主机操作系统 (RHCOS)

  • 部署 OpenShift Container Platform

  • 创建集群策略和站点订阅

  • 对服务器操作系统进行必要的网络配置

  • 部署配置文件操作符并执行任何必要的软件相关配置,例如性能配置文件、PTP 和 SR-IOV

托管站点安装过程概述

应用中心集群上的托管站点自定义资源 (CR) 后,以下操作将自动执行:

  1. 生成一个 Discovery 镜像 ISO 文件,并在目标主机上引导。

  2. 当 ISO 文件成功在目标主机上引导时,它会将主机硬件信息报告给 RHACM。

  3. 发现所有主机后,将安装 OpenShift Container Platform。

  4. OpenShift Container Platform 安装完成后,中心集群将在目标集群上安装klusterlet服务。

  5. 在目标集群上安装请求的附加组件服务。

当中心集群上创建托管集群的Agent CR 时,Discovery 镜像 ISO 过程完成。

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

创建托管裸机主机密钥

将托管裸机主机所需的Secret自定义资源 (CR) 添加到中心集群。GitOps 零接触配置 (ZTP) 管道需要一个密钥才能访问基板管理控制器 (BMC),并且辅助安装程序服务需要一个密钥才能从注册表中提取集群安装镜像。

密钥通过名称从SiteConfig CR 中引用。命名空间必须与SiteConfig命名空间匹配。

步骤
  1. 创建一个 YAML 密钥文件,其中包含主机基板管理控制器 (BMC) 的凭据以及安装 OpenShift 和所有附加组件集群操作符所需的拉取密钥。

    1. 将以下 YAML 保存为文件example-sno-secret.yaml

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno (1)
      data: (2)
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  (3)
      data:
        .dockerconfigjson: <pull_secret> (4)
      type: kubernetes.io/dockerconfigjson
      1 必须与相关SiteConfig CR中配置的命名空间匹配
      2 passwordusername的Base64编码值
      3 必须与相关SiteConfig CR中配置的命名空间匹配
      4 Base64编码的拉取密钥
  2. example-sno-secret.yaml的相对路径添加到用于安装集群的kustomization.yaml文件中。

配置使用GitOps ZTP安装时的Discovery ISO内核参数

GitOps零接触配置(ZTP)工作流在托管裸机主机上OpenShift Container Platform安装过程中使用Discovery ISO。您可以编辑InfraEnv资源以指定Discovery ISO的内核参数。这对于具有特定环境要求的集群安装非常有用。例如,为Discovery ISO配置rd.net.timeout.carrier内核参数,以便为集群提供静态网络或在安装期间下载根文件系统之前接收DHCP地址。

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

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有集群管理员权限的用户身份登录到Hub集群。

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

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

      此示例中的InfraEnv CR使用模板语法,例如{{ .Cluster.ClusterName }},该语法根据SiteConfig CR中的值进行填充。SiteConfig CR在部署期间会自动填充这些模板的值。请勿手动编辑模板。

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

    ~/example-ztp/install
              └── site-install
                   ├── siteconfig-example.yaml
                   ├── InfraEnv-example.yaml
                   ...
  3. 编辑SiteConfig CR中的spec.clusters.crTemplates规范,以引用Git仓库中的InfraEnv-example.yaml CR。

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

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

验证

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

  1. 开始与目标主机的SSH会话

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

    $ cat /proc/cmdline

使用SiteConfig和GitOps ZTP部署托管集群

使用以下步骤创建SiteConfig自定义资源(CR)和相关文件,并启动GitOps零接触配置(ZTP)集群部署。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

  • 您已配置Hub集群以生成所需的安装和策略CR。

  • 您已创建了一个Git仓库,用于管理您的自定义站点配置数据。该仓库必须可从Hub集群访问,并且您必须将其配置为ArgoCD应用程序的源仓库。有关更多信息,请参见“准备GitOps ZTP站点配置仓库”。

    创建源仓库时,请确保使用从ztp-site-generate容器中提取的argocd/deployment/argocd-openshift-gitops-patch.json补丁文件来修补ArgoCD应用程序。请参见“使用ArgoCD配置Hub集群”。

  • 为了准备好配置托管集群,每个裸机主机都需要以下内容:

    网络连接

    您的网络需要DNS。托管集群主机应可从Hub集群访问。确保Hub集群和托管集群主机之间存在3层连接。

    底板管理控制器(BMC)详细信息

    GitOps ZTP使用BMC用户名和密码详细信息在集群安装期间连接到BMC。GitOps ZTP插件根据站点Git仓库中的SiteConfig CR管理Hub集群上的ManagedCluster CR。您需要手动为每个主机创建单独的BMCSecret CR。

    步骤
    1. 在Hub集群上创建所需的托管集群密钥。这些资源必须位于与集群名称匹配的命名空间中。例如,在out/argocd/example/siteconfig/example-sno.yaml中,集群名称和命名空间为example-sno

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

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

        $ oc create namespace $CLUSTERNS
    2. 为托管集群创建拉取密钥和BMC Secret CR。拉取密钥必须包含安装OpenShift Container Platform和所有必需Operators所需的所有凭据。有关更多信息,请参见“创建托管裸机主机密钥”。

      密钥通过名称从SiteConfig自定义资源(CR)中引用。命名空间必须与SiteConfig命名空间匹配。

    3. 在Git仓库的本地克隆中为您的集群创建SiteConfig CR

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

        • example-sno.yaml

        • example-3node.yaml

        • example-standard.yaml

      2. 更改示例文件中的集群和主机详细信息以匹配您想要的集群类型。例如:

        单节点OpenShift SiteConfig CR示例
        # 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: "UEFISecureBoot"
                  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

        有关BMC寻址的更多信息,请参见“其他资源”部分。为了便于阅读,示例中扩展了installConfigOverridesignitionConfigOverride字段。

      3. 您可以在out/argocd/extra-manifest中检查默认的额外清单MachineConfig CR集。安装集群时会自动应用它。

      4. 可选:要在已配置的集群上配置其他安装时清单,请在您的Git仓库中创建一个目录,例如sno-extra-manifest/,并将您的自定义清单CR添加到此目录。如果您的SiteConfig.yamlextraManifestPath字段中引用此目录,则此引用的目录中的任何CR都将附加到默认的额外清单集。

        启用crun OCI容器运行时

        为了获得最佳集群性能,请在单节点OpenShift、带有额外工作节点的单节点OpenShift、三节点OpenShift和标准集群中为master节点和worker节点启用crun。

        ContainerRuntimeConfig CR中启用crun作为额外的第0天安装时清单,以避免集群需要重新启动。

        enable-crun-master.yamlenable-crun-worker.yaml CR文件位于您可以从ztp-site-generate容器中提取的out/source-crs/optional-extra-manifest/文件夹中。有关更多信息,请参见“自定义GitOps ZTP管道中的额外安装清单”。

    4. SiteConfig CR添加到generators部分的kustomization.yaml文件中,类似于out/argocd/example/siteconfig/kustomization.yaml中所示的示例。

    5. 提交SiteConfig CR 和相关的kustomization.yaml更改到您的 Git 仓库,并推送更改。

      ArgoCD 管道会检测到这些更改并开始托管集群部署。

验证
  • 验证节点部署后是否应用了自定义角色和标签。

    $ oc describe node example-node.example.com
示例输出
Name:   example-node.example.com
Roles:  control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        custom-label/parameter1=true
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
        kubernetes.io/os=linux
        node-role.kubernetes.io/control-plane=
        node-role.kubernetes.io/example-label= (1)
        node-role.kubernetes.io/master=
        node-role.kubernetes.io/worker=
        node.openshift.io/os_id=rhcos
1 自定义标签已应用于节点。

GitOps ZTP 的加速配置

GitOps ZTP 的加速配置目前仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参阅 技术预览功能支持范围

您可以使用 GitOps ZTP 的加速配置来缩短单节点 OpenShift 的集群安装时间。加速 ZTP 通过在更早阶段应用从策略派生的 Day 2 清单来加快安装速度。

仅当使用 Assisted Installer 安装单节点 OpenShift 时,才支持 GitOps ZTP 的加速配置。否则,此安装方法将失败。

激活加速 ZTP

您可以使用spec.clusters.clusterLabels.accelerated-ztp标签激活加速 ZTP,如下例所示。

示例加速 ZTP SiteConfig CR。
apiVersion: ran.openshift.io/v2
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:
  # ...
    clusterLabels:
        common: true
        group-du-sno: ""
        sites : "example-sno"
        accelerated-ztp: full

您可以使用accelerated-ztp: full完全自动化加速过程。GitOps ZTP 使用对加速 GitOps ZTP ConfigMap 的引用更新AgentClusterInstall资源,并包含由 TALM 从策略中提取的资源以及加速 ZTP 作业清单。

如果您使用accelerated-ztp: partial,GitOps ZTP 不会包含加速作业清单,但会包含在集群安装过程中创建的以下kind类型的策略派生对象。

  • PerformanceProfile.performance.openshift.io

  • Tuned.tuned.openshift.io

  • Namespace

  • CatalogSource.operators.coreos.com

  • ContainerRuntimeConfig.machineconfiguration.openshift.io

这种部分加速可以减少节点在应用Performance ProfileTunedContainerRuntimeConfig类型的资源时进行的重启次数。TALM 在 RHACM 完成集群导入后,按照与标准 GitOps ZTP 相同的流程安装从策略派生的 Operator 订阅。

加速 ZTP 的好处会随着部署规模的增加而增加。在大量集群上使用accelerated-ztp: full会带来更多好处。对于少量集群,安装时间的减少并不显著。完全加速的 ZTP 会在 spoke 上留下一个命名空间和一个已完成的作业,需要手动删除。

使用accelerated-ztp: partial的一个好处是,如果标准实现出现问题或需要自定义功能,您可以覆盖 spoke 上作业的功能。

加速 ZTP 流程

加速 ZTP 使用额外的ConfigMap在 spoke 集群上创建从策略派生的资源。标准ConfigMap包含 GitOps ZTP 工作流程用于自定义集群安装的清单。

TALM 检测到accelerated-ztp标签已设置,然后创建一个第二个ConfigMap。作为加速 ZTP 的一部分,SiteConfig生成器使用命名约定<spoke-cluster-name>-aztp添加对第二个ConfigMap的引用。

TALM 创建第二个ConfigMap后,它会查找绑定到托管集群的所有策略,并提取 GitOps ZTP 配置文件信息。TALM 将 GitOps ZTP 配置文件信息添加到<spoke-cluster-name>-aztpConfigMap自定义资源 (CR) 中,并将 CR 应用于 hub 集群 API。

使用 GitOps ZTP 和 SiteConfig 资源配置单节点 OpenShift 集群的 IPsec 加密

您可以在使用 GitOps ZTP 和 Red Hat Advanced Cluster Management (RHACM) 安装的托管单节点 OpenShift 集群中启用 IPsec 加密。您可以加密托管集群和托管集群外部的 IPsec 端点之间的流量。OVN-Kubernetes 集群网络上节点之间的所有网络流量都以传输模式使用 IPsec 加密。

您还可以按照此步骤为具有附加工作节点的单节点 OpenShift 集群配置 IPsec 加密。建议使用MachineConfig自定义资源 (CR) 来配置单节点 OpenShift 集群和具有附加工作节点的单节点 OpenShift 集群的 IPsec 加密,因为它们的资源可用性较低。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

  • 您已配置 RHACM 和 hub 集群以生成托管集群所需的安装和策略自定义资源 (CR)。

  • 您已创建了一个 Git 仓库,用于管理您的自定义站点配置数据。该仓库必须可从 hub 集群访问,并定义为 Argo CD 应用程序的源仓库。

  • 您已安装了butane实用程序 0.20.0 或更高版本。

  • 您拥有 IPsec 端点的 PKCS#12 证书和 PEM 格式的 CA 证书。

步骤
  1. 提取最新版本的ztp-site-generate容器源代码,并将其与您管理自定义站点配置数据的仓库合并。

  2. 使用在集群中配置 IPsec 所需的值配置optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml。例如:

    interfaces:
    - name: hosta_conn
      type: ipsec
      libreswan:
        left: '%defaultroute'
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftcert: left_server (1)
        leftrsasigkey: '%cert'
        right: <external_host> (2)
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address> (3)
        ikev2: insist (4)
        type: tunnel
    1 此字段的值必须与远程系统上使用的证书名称匹配。
    2 <external_host>替换为外部主机的 IP 地址或 DNS 主机名。
    3 <external_address>替换为 IPsec 隧道另一侧外部主机的 IP 子网。
    4 仅使用 IKEv2 VPN 加密协议。不要使用已弃用的 IKEv1。
  3. 将以下证书添加到optional-extra-manifest/ipsec文件夹

    • left_server.p12:IPsec 端点的证书捆绑包

    • ca.pem:您用来签署证书的证书颁发机构

      每个主机上的网络安全服务 (NSS) 数据库都需要证书文件。这些文件将在后面的步骤中作为 Butane 配置的一部分导入。

  4. 在您维护自定义站点配置数据的 Git 仓库的optional-extra-manifest/ipsec文件夹中打开一个 shell 提示符。

  5. 运行optional-extra-manifest/ipsec/build.sh脚本以生成所需的Butane和MachineConfig CR文件。

    如果PKCS#12证书受密码保护,请设置-W参数。

    示例输出
    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-endpoint-config.bu (1)
                         ├── 99-ipsec-master-endpoint-config.yaml (1)
                         ├── 99-ipsec-worker-endpoint-config.bu (1)
                         ├── 99-ipsec-worker-endpoint-config.yaml (1)
                         ├── build.sh
                         ├── ca.pem (2)
                         ├── left_server.p12 (2)
                         ├── enable-ipsec.yaml
                         ├── ipsec-endpoint-config.yml
                         └── README.md
    1 ipsec/build.sh脚本生成Butane和端点配置CR。
    2 您需要提供与您的网络相关的ca.pemleft_server.p12证书文件。
  6. 在您管理自定义站点配置数据的存储库中创建一个custom-manifest/文件夹。将enable-ipsec.yaml99-ipsec-* YAML文件添加到该目录。例如:

    siteconfig
      ├── site1-sno-du.yaml
      ├── extra-manifest/
      └── custom-manifest
            ├── enable-ipsec.yaml
            ├── 99-ipsec-worker-endpoint-config.yaml
            └── 99-ipsec-master-endpoint-config.yaml
  7. 在您的SiteConfig CR中,将custom-manifest/目录添加到extraManifests.searchPaths字段。例如:

    clusters:
    - clusterName: "site1-sno-du"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/
          - custom-manifest/
  8. 提交SiteConfig CR更改和您Git存储库中更新的文件,并将更改推送以配置托管集群并配置IPsec加密。

    Argo CD管道检测到更改并开始托管集群部署。

    在集群配置期间,GitOps ZTP管道将custom-manifest/目录中的CR附加到存储在extra-manifest/目录中的默认额外清单集。

验证

有关验证IPsec加密的信息,请参见“验证IPsec加密”。

使用GitOps ZTP和SiteConfig资源配置多节点集群的IPsec加密

您可以在使用GitOps ZTP和Red Hat Advanced Cluster Management (RHACM)安装的托管多节点集群中启用IPsec加密。您可以加密托管集群和托管集群外部的IPsec端点之间的流量。OVN-Kubernetes集群网络上节点之间的所有网络流量都以传输模式使用IPsec加密。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

  • 您已配置 RHACM 和 hub 集群以生成托管集群所需的安装和策略自定义资源 (CR)。

  • 您已创建了一个 Git 仓库,用于管理您的自定义站点配置数据。该仓库必须可从 hub 集群访问,并定义为 Argo CD 应用程序的源仓库。

  • 您已安装了butane实用程序 0.20.0 或更高版本。

  • 您拥有 IPsec 端点的 PKCS#12 证书和 PEM 格式的 CA 证书。

  • 您已安装NMState Operator。

步骤
  1. 提取最新版本的ztp-site-generate容器源代码,并将其与您管理自定义站点配置数据的仓库合并。

  2. 使用所需的值配置optional-extra-manifest/ipsec/ipsec-config-policy.yaml文件,以在集群中配置IPsec。

    用于创建IPsec配置的ConfigurationPolicy对象
    apiVersion: policy.open-cluster-management.io/v1
    kind: ConfigurationPolicy
    metadata:
      name: policy-config
    spec:
      namespaceSelector:
        include: ["default"]
        exclude: []
        matchExpressions: []
        matchLabels: {}
      remediationAction: inform
      severity: low
      evaluationInterval:
        compliant:
        noncompliant:
      object-templates-raw: |
        {{- range (lookup "v1" "Node" "" "").items }}
        - complianceType: musthave
          objectDefinition:
            kind: NodeNetworkConfigurationPolicy
            apiVersion: nmstate.io/v1
            metadata:
              name: {{ .metadata.name }}-ipsec-policy
            spec:
              nodeSelector:
                kubernetes.io/hostname: {{ .metadata.name }}
              desiredState:
                interfaces:
                - name: hosta_conn
                  type: ipsec
                  libreswan:
                    left: '%defaultroute'
                    leftid: '%fromcert'
                    leftmodecfgclient: false
                    leftcert: left_server (1)
                    leftrsasigkey: '%cert'
                    right: <external_host> (2)
                    rightid: '%fromcert'
                    rightrsasigkey: '%cert'
                    rightsubnet: <external_address> (3)
                    ikev2: insist (4)
                    type: tunnel
    1 此字段的值必须与远程系统上使用的证书名称匹配。
    2 <external_host>替换为外部主机的 IP 地址或 DNS 主机名。
    3 <external_address>替换为 IPsec 隧道另一侧外部主机的 IP 子网。
    4 仅使用 IKEv2 VPN 加密协议。不要使用已弃用的 IKEv1。
  3. 将以下证书添加到optional-extra-manifest/ipsec文件夹

    • left_server.p12:IPsec 端点的证书捆绑包

    • ca.pem:您用来签署证书的证书颁发机构

      每个主机上的网络安全服务 (NSS) 数据库都需要证书文件。这些文件将在后面的步骤中作为 Butane 配置的一部分导入。

  4. 在您维护自定义站点配置数据的 Git 仓库的optional-extra-manifest/ipsec文件夹中打开一个 shell 提示符。

  5. 运行optional-extra-manifest/ipsec/import-certs.sh脚本以生成导入外部证书所需的Butane和MachineConfig CR。

    如果PKCS#12证书受密码保护,请设置-W参数。

    示例输出
    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-import-certs.bu (1)
                         ├── 99-ipsec-master-import-certs.yaml (1)
                         ├── 99-ipsec-worker-import-certs.bu (1)
                         ├── 99-ipsec-worker-import-certs.yaml (1)
                         ├── import-certs.sh
                         ├── ca.pem (2)
                         ├── left_server.p12 (2)
                         ├── enable-ipsec.yaml
                         ├── ipsec-config-policy.yaml
                         └── README.md
    1 ipsec/import-certs.sh脚本生成Butane和端点配置CR。
    2 添加与您的网络相关的ca.pemleft_server.p12证书文件。
  6. 在您管理自定义站点配置数据的存储库中创建一个custom-manifest/文件夹,并将enable-ipsec.yaml99-ipsec-* YAML文件添加到该目录。

    示例siteconfig目录
    siteconfig
      ├── site1-mno-du.yaml
      ├── extra-manifest/
      └── custom-manifest
            ├── enable-ipsec.yaml
            ├── 99-ipsec-master-import-certs.yaml
            └── 99-ipsec-worker-import-certs.yaml
  7. 在您的SiteConfig CR中,将custom-manifest/目录添加到extraManifests.searchPaths字段,如下例所示:

    clusters:
    - clusterName: "site1-mno-du"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/
          - custom-manifest/
  8. ipsec-config-policy.yaml配置策略文件包含在GitOps中的source-crs目录中,并在其中一个PolicyGenerator CR中引用该文件。

  9. 提交SiteConfig CR更改和您Git存储库中更新的文件,并将更改推送以配置托管集群并配置IPsec加密。

    Argo CD管道检测到更改并开始托管集群部署。

    在集群配置期间,GitOps ZTP管道将custom-manifest/目录中的CR附加到存储在extra-manifest/目录中的默认额外清单集。

验证

有关验证IPsec加密的信息,请参见“验证IPsec加密”。

验证IPsec加密

您可以验证IPsec加密是否已成功应用于托管的OpenShift Container Platform集群中。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

  • 您已配置IPsec加密。

步骤
  1. 通过运行以下命令启动托管集群的调试Pod:

    $ oc debug node/<node_name>
  2. 通过运行以下命令检查IPsec策略是否已应用于集群节点:

    sh-5.1# ip xfrm policy
    示例输出
    src 172.16.123.0/24 dst 10.1.232.10/32
      dir out priority 1757377 ptype main
      tmpl src 10.1.28.190 dst 10.1.232.10
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir fwd priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel
    src 10.1.232.10/32 dst 172.16.123.0/24
      dir in priority 1757377 ptype main
      tmpl src 10.1.232.10 dst 10.1.28.190
        proto esp reqid 16393 mode tunnel
  3. 通过运行以下命令检查IPsec隧道是否已启动并连接:

    sh-5.1# ip xfrm state
    示例输出
    src 10.1.232.10 dst 10.1.28.190
      proto esp spi 0xa62a05aa reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0x8c59f680c8ea1e667b665d8424e2ab749cec12dc 96
      enc cbc(aes) 0x2818a489fe84929c8ab72907e9ce2f0eac6f16f2258bd22240f4087e0326badb
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000
    src 10.1.28.190 dst 10.1.232.10
      proto esp spi 0x8e96e9f9 reqid 16393 mode tunnel
      replay-window 0 flag af-unspec esn
      auth-trunc hmac(sha1) 0xd960ddc0a6baaccb343396a51295e08cfd8aaddd 96
      enc cbc(aes) 0x0273c02e05b4216d5e652de3fc9b3528fea94648bc2b88fa01139fdf0beb27ab
      anti-replay esn context:
       seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x0
       replay_window 128, bitmap-length 4
       00000000 00000000 00000000 00000000
  4. 通过运行以下命令 ping 外部主机子网中的已知IP:例如,ping您在ipsec/ipsec-endpoint-config.yaml文件中设置的rightsubnet范围内的IP地址。

    sh-5.1# ping 172.16.110.8
    示例输出
    PING 172.16.110.8 (172.16.110.8) 56(84) bytes of data.
    64 bytes from 172.16.110.8: icmp_seq=1 ttl=64 time=153 ms
    64 bytes from 172.16.110.8: icmp_seq=2 ttl=64 time=155 ms

单节点OpenShift SiteConfig CR安装参考

表1. 单节点OpenShift集群的SiteConfig CR安装选项
SiteConfig CR字段 描述

spec.cpuPartitioningMode

通过将cpuPartitioningMode的值设置为AllNodes来配置工作负载分区。要完成配置,请在PerformanceProfile CR中指定isolatedreserved CPU。

在OpenShift Container Platform 4.13中,使用SiteConfig CR中的cpuPartitioningMode字段配置工作负载分区是一项技术预览功能。

metadata.name

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

spec.clusterImageSetNameRef

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

installConfigOverrides

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

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

spec.clusters.clusterImageSetNameRef

指定用于部署单个集群的集群镜像集。如果已定义,它将覆盖站点级别的spec.clusterImageSetNameRef

spec.clusters.clusterLabels

配置集群标签以与您定义的PolicyGeneratorPolicyGentemplate CR中的绑定规则相对应。PolicyGenerator CR使用policyDefaults.placement.labelSelector字段。PolicyGentemplate CR使用spec.bindingRules字段。

例如,acmpolicygenerator/acm-common-ranGen.yaml适用于所有已设置common: true的集群,acmpolicygenerator/acm-group-du-sno-ranGen.yaml适用于所有已设置group-du-sno: ""的集群。

spec.clusters.crTemplates.KlusterletAddonConfig

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

spec.clusters.diskEncryption

配置此字段以使用可信平台模块 (TPM) 和平台配置寄存器 (PCR) 保护启用磁盘加密。有关更多信息,请参见“关于使用TPM和PCR保护的磁盘加密”。

在OpenShift Container Platform 4.17中,使用SiteConfig CR中的diskEncryption字段配置磁盘加密是一项技术预览功能。

spec.clusters.diskEncryption.type

将磁盘加密类型设置为tpm2

spec.clusters.diskEncryption.tpm2

配置平台配置寄存器 (PCR) 对磁盘加密的保护。

spec.clusters.diskEncryption.tpm2.pcrList

配置要用于磁盘加密的平台配置寄存器 (PCR) 列表。您必须使用PCR寄存器1和7。

spec.clusters.nodes.hostName

对于单节点部署,请定义单个主机。对于三节点部署,请定义三个主机。对于标准部署,请定义三个具有role: master的主机和两个或更多个具有role: worker的主机。

spec.clusters.nodes.nodeLabels

为托管集群中的节点指定自定义角色。这些是任何OpenShift Container Platform组件都不使用的附加角色,仅供用户使用。添加自定义角色后,它可以与引用该角色的特定配置的自定义机器配置池相关联。在安装期间添加自定义标签或角色可以使部署过程更有效,并避免安装完成后需要额外重新启动。

spec.clusters.nodes.automatedCleaningMode

可选。取消注释并将值设置为metadata以仅启用删除磁盘的分区表,而无需完全擦除磁盘。默认值为disabled

spec.clusters.nodes.bmcAddress

您用于访问主机的 BMC 地址。适用于所有集群类型。GitOps ZTP 使用 Redfish 或 IPMI 协议支持 iPXE 和虚拟介质启动。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 地址的更多信息,请参见“附加资源”部分。

spec.clusters.nodes.bmcAddress

您用于访问主机的 BMC 地址。适用于所有集群类型。GitOps ZTP 使用 Redfish 或 IPMI 协议支持 iPXE 和虚拟介质启动。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 地址的更多信息,请参见“附加资源”部分。

在远端电信用例中,仅支持虚拟介质与 GitOps ZTP 一起使用。

spec.clusters.nodes.bmcCredentialsName

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

spec.clusters.nodes.bootMode

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

spec.clusters.nodes.rootDeviceHints

指定部署的设备。建议使用在重新引导后保持稳定的标识符。例如,wwn: <disk_wwn>deviceName: /dev/disk/by-path/<device_path><by-path> 值更佳。有关稳定标识符的详细列表,请参见“关于根设备提示”部分。

spec.clusters.nodes.ignitionConfigOverride

可选。使用此字段为持久存储分配分区。将磁盘 ID 和大小调整为特定的硬件。

spec.clusters.nodes.nodeNetwork

配置节点的网络设置。

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

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

使用 GitOps ZTP 管理主机固件设置

主机需要正确的固件配置才能确保高性能和最佳效率。您可以为使用 GitOps ZTP 管理的集群部署自定义主机固件配置。

使用您实验室中的特定硬件配置文件调整主机,并确保它们针对您的要求进行了优化。当您满意地完成了主机调整后,您可以提取主机配置文件并将其保存在您的 GitOps ZTP 存储库中。然后,您可以使用主机配置文件来配置使用 GitOps ZTP 部署的托管集群主机中的固件设置。

您在用于部署托管集群的SiteConfig 自定义资源 (CR) 中指定所需的硬件配置文件。GitOps ZTP 管道会生成应用于中心集群的必需HostFirmwareSettings (HFS) 和BareMetalHost (BMH) CR。

使用以下最佳实践来管理您的主机固件配置文件。

与硬件供应商一起确定关键固件设置

与硬件供应商合作,识别和记录部署的主机平台所需的、确保最佳性能和兼容性的关键主机固件设置。

在类似的硬件平台上使用通用的固件配置

尽可能在类似的硬件平台上使用标准化的主机固件配置,以减少部署过程中的复杂性和潜在错误。

在实验室环境中测试固件配置

在生产环境中部署之前,在受控的实验室环境中测试主机固件配置,以确保设置与硬件、固件和软件兼容。

在源代码控制中管理固件配置文件

在 Git 存储库中管理主机固件配置文件,以跟踪更改、确保一致性并促进与供应商的协作。

检索托管集群的主机固件模式

您可以发现托管集群的主机固件模式。裸机主机的固件模式填充了 Ironic API 返回的信息。API 返回有关主机固件接口的信息,包括固件设置类型、允许的值、范围和标志。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已安装 Red Hat Advanced Cluster Management (RHACM) 并以具有cluster-admin权限的用户身份登录到中心集群。

  • 您已配置一个由 RHACM 管理的集群。

步骤
  • 发现托管集群的主机固件模式。运行以下命令

    $ oc get firmwareschema -n <managed_cluster_namespace> -o yaml
    示例输出
    apiVersion: v1
    items:
    - apiVersion: metal3.io/v1alpha1
      kind: FirmwareSchema
      metadata:
        creationTimestamp: "2024-09-11T10:29:43Z"
        generation: 1
        name: schema-40562318
        namespace: compute-1
        ownerReferences:
        - apiVersion: metal3.io/v1alpha1
          kind: HostFirmwareSettings
          name: compute-1.example.com
          uid: 65d0e89b-1cd8-4317-966d-2fbbbe033fe9
        resourceVersion: "280057624"
        uid: 511ad25d-f1c9-457b-9a96-776605c7b887
      spec:
        schema:
          AccessControlService:
            allowable_values:
            - Enabled
            - Disabled
            attribute_type: Enumeration
            read_only: false
          # ...

检索托管集群的主机固件设置

您可以检索托管集群的主机固件设置。当您已将更改部署到主机固件并且您想要监控更改并确保它们已成功应用时,这很有用。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已安装 Red Hat Advanced Cluster Management (RHACM) 并以具有cluster-admin权限的用户身份登录到中心集群。

  • 您已配置一个由 RHACM 管理的集群。

步骤
  1. 检索托管集群的主机固件设置。运行以下命令

    $ oc get hostfirmwaresettings -n <cluster_namespace> <node_name> -o yaml
    示例输出
    apiVersion: v1
    items:
    - apiVersion: metal3.io/v1alpha1
      kind: HostFirmwareSettings
      metadata:
        creationTimestamp: "2024-09-11T10:29:43Z"
        generation: 1
        name: compute-1.example.com
        namespace: kni-qe-24
        ownerReferences:
        - apiVersion: metal3.io/v1alpha1
          blockOwnerDeletion: true
          controller: true
          kind: BareMetalHost
          name: compute-1.example.com
          uid: 0baddbb7-bb34-4224-8427-3d01d91c9287
        resourceVersion: "280057626"
        uid: 65d0e89b-1cd8-4317-966d-2fbbbe033fe9
      spec:
        settings: {}
      status:
        conditions:
        - lastTransitionTime: "2024-09-11T10:29:43Z"
          message: ""
          observedGeneration: 1
          reason: Success
          status: "True" (1)
          type: ChangeDetected
        - lastTransitionTime: "2024-09-11T10:29:43Z"
          message: Invalid BIOS setting
          observedGeneration: 1
          reason: ConfigurationError
          status: "False" (2)
          type: Valid
        lastUpdated: "2024-09-11T10:29:43Z"
        schema:
          name: schema-40562318
          namespace: compute-1
        settings: (3)
          AccessControlService: Enabled
          AcpiHpet: Enabled
          AcpiRootBridgePxm: Enabled
          # ...
    1 表示已检测到主机固件设置的更改
    2 表示主机具有无效的固件设置
    3 配置的主机固件设置的完整列表在status.settings字段下返回
  2. 可选:检查集群中HostFirmwareSettings (hfs) 自定义资源的状态

    $ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="ChangeDetected")].status}'
    示例输出
    True
  3. 可选:检查集群主机中无效的固件设置。运行以下命令

    $ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
    示例输出
    False

使用 GitOps ZTP 将用户定义的固件部署到集群主机

您可以通过配置SiteConfig自定义资源 (CR) 以包含您想要在集群主机配置期间应用的硬件配置文件,将用户定义的固件设置部署到集群主机。您可以配置硬件配置文件以应用于以下场景中的主机

  • 所有站点范围内的主机

  • 仅满足特定条件的集群主机

  • 单个集群主机

您可以配置以层次结构应用的主机硬件配置文件。集群级别设置会覆盖站点范围内的设置。节点级别配置文件会覆盖集群和站点范围内的设置。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已安装 Red Hat Advanced Cluster Management (RHACM) 并以具有cluster-admin权限的用户身份登录到中心集群。

  • 您已配置一个由 RHACM 管理的集群。

  • 您创建了一个 Git 存储库,您可以在其中管理自定义站点配置数据。该存储库必须可以从中心集群访问,并被定义为 Argo CD 应用程序的源存储库。

步骤
  1. 创建包含您要应用的固件设置的主机固件配置文件。例如,创建以下 YAML 文件

    host-firmware.profile
    BootMode: Uefi
    LogicalProc: Enabled
    ProcVirtualization: Enabled
  2. 保存相对于用于定义如何配置集群的kustomization.yaml文件的硬件配置文件 YAML 文件,例如

    example-ztp/install
        └── site-install
              ├── siteconfig-example.yaml
              ├── kustomization.yaml
              └── host-firmware.profile
  3. 编辑SiteConfig CR 以包含您想要在集群中应用的固件配置文件。例如

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    metadata:
      name: "site-plan-cluster"
      namespace: "example-cluster-namespace"
    spec:
      baseDomain: "example.com"
      # ...
      biosConfigRef:
        filePath: "./host-firmware.profile" (1)
    1 将硬件配置文件应用于所有站点范围内的集群主机

    尽可能每个集群使用单个SiteConfig CR。

  4. 可选。要将硬件配置文件应用于特定集群中的主机,请使用要应用的硬件配置文件更新clusters.biosConfigRef.filePath。例如

    clusters:
      - clusterName: "cluster-1"
        # ...
        biosConfigRef:
          filePath: "./host-firmware.profile" (1)
    1 应用于cluster-1集群中的所有主机
  5. 可选。要将硬件配置文件应用于集群中的特定主机,请使用要应用的硬件配置文件更新clusters.nodes.biosConfigRef.filePath。例如

    clusters:
      - clusterName: "cluster-1"
        # ...
        nodes:
          - hostName: "compute-1.example.com"
            # ...
            bootMode: "UEFI"
            biosConfigRef:
              filePath: "./host-firmware.profile" (1)
    1 将固件配置文件应用于集群中的compute-1.example.com主机
  6. 提交SiteConfig CR 和相关的kustomization.yaml更改到您的 Git 仓库,并推送更改。

    ArgoCD 管道会检测到这些更改并开始托管集群部署。

    即使检测到无效的固件设置,集群部署也会继续进行。要使用 GitOps ZTP 应用更正,请使用更正后的硬件配置文件重新部署集群。

验证
  • 检查托管集群主机中是否已应用固件设置。例如,运行以下命令

    $ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
    示例输出
    True

监控托管集群安装进度

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

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

步骤

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

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

    1. 导出集群名称

      $ export CLUSTER=<clusterName>
    2. 查询AgentClusterInstall CR 以获取托管集群

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

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

通过验证安装 CR 来排查 GitOps ZTP 问题

ArgoCD 管道使用SiteConfigPolicyGeneratorPolicyGentemplate自定义资源 (CR) 来生成集群配置 CR 和 Red Hat Advanced Cluster Management (RHACM) 策略。请使用以下步骤来排查在此过程中可能发生的错误。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

步骤
  1. 使用以下命令检查是否已创建安装 CR

    $ oc get AgentClusterInstall -n <cluster_name>

    如果没有返回任何对象,请使用以下步骤来排查从SiteConfig文件到安装 CR 的 ArgoCD 管道流程。

  2. 验证是否已使用中心集群上的SiteConfig CR 生成ManagedCluster CR

    $ oc get managedcluster
  3. 如果缺少ManagedCluster,请检查clusters应用程序是否未能将文件从 Git 仓库同步到中心集群。

    $ 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

排查 SuperMicro 服务器上 GitOps ZTP 虚拟介质引导问题

当使用https协议提供镜像时,SuperMicro X11 服务器不支持虚拟介质安装。因此,此环境的单节点 OpenShift 部署无法在目标节点上启动。为避免此问题,请登录中心集群并在Provisioning资源中禁用传输层安全性 (TLS)。这确保即使镜像地址使用https方案,镜像也不会使用 TLS 提供。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

步骤
  1. 通过运行以下命令禁用Provisioning资源中的 TLS

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

从 GitOps ZTP 管道中移除托管集群站点

您可以从 GitOps 零接触配置 (ZTP) 管道中移除托管站点以及相关的安装和配置策略 CR。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

步骤
  1. 通过从kustomization.yaml文件中移除相关的SiteConfigPolicyGeneratorPolicyGentemplate文件来移除站点和相关的 CR。

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

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

    再次运行 GitOps ZTP 管道时,生成的 CR 将被移除。

  3. 可选:如果您想永久移除站点,还应从 Git 仓库中移除SiteConfig和特定站点的PolicyGeneratorPolicyGentemplate文件。

  4. 可选:如果您想暂时移除站点,例如在重新部署站点时,您可以将SiteConfig和特定站点的PolicyGeneratorPolicyGentemplate CR 保留在 Git 仓库中。

其他资源

从 GitOps ZTP 管道中移除过时的内容

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

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

步骤
  1. 从 Git 仓库中移除受影响的PolicyGeneratorPolicyGentemplate文件,提交并推送到远程仓库。

  2. 等待更改通过应用程序同步,并从中心集群中移除受影响的策略。

  3. 将更新的PolicyGeneratorPolicyGentemplate文件添加回 Git 仓库,然后提交并推送到远程仓库。

    从 Git 仓库中移除 GitOps 零接触配置 (ZTP) 策略,从而也从中心集群中移除它们,不会影响托管集群的配置。该策略管理的策略和 CR 保留在托管集群上。

  4. 可选:作为替代方案,在对导致策略过时的PolicyGeneratorPolicyGentemplate CR 进行更改后,您可以手动从中心集群中移除这些策略。您可以使用**治理**选项卡或运行以下命令从 RHACM 控制台中删除策略

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

拆除 GitOps ZTP 管道

您可以移除 ArgoCD 管道和所有生成的 GitOps 零接触配置 (ZTP) 工件。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到Hub集群。

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

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

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