搜索

4.5. 使用 SiteConfig 和 GitOps ZTP 部署受管集群

download PDF

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

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 配置了 hub 集群来生成所需的安装和策略 CR。
  • 您创建了 Git 存储库,用于管理自定义站点配置数据。存储库必须可从 hub 集群访问,且必须将其配置为 ArgoCD 应用程序的源存储库。如需更多信息,请参阅"准备 GitOps ZTP 站点配置存储库"。

    注意

    在创建源存储库时,请确保使用从 ztp-site-generate 容器中提取的 argocd/deployment/argocd-openshift-gitops-patch.json patch-file 来修补 ArgoCD 应用程序。请参阅"使用 ArgoCD 配置 hub 集群"。

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

    网络连接
    您的网络需要 DNS。受管集群主机应该可从 hub 集群访问。确保 hub 集群和受管集群主机之间存在第 3 层连接。
    Baseboard Management Controller (BMC) 详情
    GitOps ZTP 使用 BMC 用户名和密码详情来在集群安装过程中连接到 BMC。GitOps ZTP 插件根据站点 Git 仓库中的 SiteConfig CR 管理 hub 集群上的 ManagedCluster CR。您可以手动为每个主机创建单独的 BMCSecret CR。

    流程

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

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

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

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

      注意

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

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

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

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

        单节点 OpenShift SiteConfig CR 示例

        # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
        ---
        apiVersion: ran.openshift.io/v1
        kind: SiteConfig
        metadata:
          name: "example-sno"
          namespace: "example-sno"
        spec:
          baseDomain: "example.com"
          pullSecretRef:
            name: "assisted-deployment-pull-secret"
          clusterImageSetNameRef: "openshift-4.10"
          sshPublicKey: "ssh-rsa AAAA..."
          clusters:
          - clusterName: "example-sno"
            networkType: "OVNKubernetes"
            # installConfigOverrides is a generic way of passing install-config
            # parameters through the siteConfig.  The 'capabilities' field configures
            # the composable openshift feature.  In this 'capabilities' setting, we
            # remove all but the marketplace component from the optional set of
            # components.
            # Notes:
            # - 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

        注意

        有关 BMC 寻址的更多信息,请参阅"添加资源"部分。installConfigOverridesignitionConfigOverride 字段在示例中扩展,以简化可读性。

      3. 您可以在 out/argocd/extra-manifest 中检查默认的 extra-manifest MachineConfig CR。它在安装时会自动应用到集群。
      4. 可选: 要在置备的集群中置备额外的安装清单,请在 Git 存储库中创建一个目录,如 sno-extra-manifest/,并将自定义清单 CR 添加到这个目录中。如果您的 SiteConfig.yamlextraManifestPath 字段中引用这个目录,则这个引用目录中的所有 CR 都会被附加到默认的额外的清单集合中。

        启用 crun OCI 容器运行时

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

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

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

    4. kustomization.yaml 文件中将 SiteConfig CR 添加到 generators 部分中 ,类似于 out/argocd/example/siteconfig/kustomization.yaml 中显示的示例。
    5. 在 Git 存储库中提交 SiteConfig CR 及关联的 kustomization.yaml 更改并推送更改。

      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
自定义标签应用到节点。

4.5.1. 加速置备 GitOps ZTP

重要

GitOps ZTP 的加速置备只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

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

您可以通过为单节点 OpenShift 使用 GitOps ZTP 的加速置备来减少集群安装所需的时间。加速 ZTP 通过在早期阶段应用从策略派生的第 2 天清单来加快安装速度。

重要

只有在使用 Assisted Installer 安装单节点 OpenShift 时,才支持加速 GitOps ZTP 置备。否则,这个安装方法将失败。

4.5.1.1. 激活加速 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: 部分,GitOps ZTP 不包括加速的作业清单,而是包括集群安装以下类型时创建的 policy-derived 对象:

  • PerformanceProfile.performance.openshift.io
  • Tuned.tuned.openshift.io
  • Namespace
  • CatalogSource.operators.coreos.com
  • ContainerRuntimeConfig.machineconfiguration.openshift.io

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

加速 ZTP 的好处会随着部署的规模而增加。使用 accelerated-ztp : 对大量集群提供了更多好处。使用较少的集群,安装时间缩短会显著减少。全加速 ZTP 在需要手动删除的 spoke 上保留一个命名空间和完成的作业。

使用 accelerated-ztp: 部分 的好处之一是,如果库存实施出现问题,或者需要自定义功能,您可以覆盖 on-spoke 任务的功能。

4.5.1.2. 加速 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>-aztp ConfigMap 自定义资源(CR)中,并将 CR 应用到 hub 集群 API。

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

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

注意

在 OpenShift Container Platform 4.16 中,使用 GitOps ZTP 和 RHACM 部署 IPsec 加密,只针对单节点 OpenShift 集群验证。

GitOps ZTP IPsec 实现假设您部署到资源受限平台。因此,您只能使用单个 MachineConfig CR 安装该功能,您不需要在单节点 OpenShift 集群上安装 NMState Operator。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 您已配置了 RHACM 和 hub 集群,为受管集群生成所需的安装和策略自定义资源(CR)。
  • 您已创建了管理自定义站点配置数据的 Git 存储库。该存储库必须可从 hub 集群访问,并定义为 Argo CD 应用程序的源仓库。
  • 已安装 butane 工具,版本 0.20.0 或更高版本。
  • 您有一个用于 IPsec 端点和 PEM 格式的 CA 证书的 PKCSautomationhub 证书。

流程

  1. 提取 ztp-site-generate 容器源的最新版本,并将其与您管理自定义站点配置数据的存储库合并。
  2. 使用在集群中配置 IPsec 所需的值来配置 optional-extra-manifest/ipsec/ipsec-endpoint-config.yaml。例如:

    interfaces:
    - name: hosta_conn
      type: ipsec
      libreswan:
        left: <cluster_node> 1
        leftid: '%fromcert'
        leftmodecfgclient: false
        leftcert: <left_cert> 2
        leftrsasigkey: '%cert'
        right: <external_host> 3
        rightid: '%fromcert'
        rightrsasigkey: '%cert'
        rightsubnet: <external_address> 4
        ikev2: insist 5
        type: tunnel
    1
    <cluster_node > 替换为 cluster-side IPsec 隧道的集群节点的 IP 地址或 DNS 主机名。
    2
    <left_cert& gt; 替换为 IPsec 证书 nickname。
    3
    使用 <external_host> 外部主机 IP 地址或 DNS 主机名替换。
    4
    在 IPsec 隧道的另一端,使用外部主机的 IP 地址或子网替换 <external_address>
    5
    只使用 IKEv2 VPN 加密协议。不要使用 IKEv1,它已弃用。
  3. 将您的 ca.pemleft_server.p12 证书添加到 optional-extra-manifest/ipsec 文件夹中。每个主机上的网络安全服务(NSS)数据库都需要证书文件。这些文件在后续步骤中作为 Butane 配置的一部分导入。

    1. left_server.p12:IPsec 端点的证书捆绑包
    2. ca.pem :您使用签名证书的证书颁发机构
  4. 在您维护自定义站点配置数据的 Git 存储库的 optional-extra-manifest/ipsec 文件夹下打开 shell 提示符。
  5. 运行 optional-extra-manifest/ipsec/build.sh 脚本来生成所需的 Butane 和 MachineConfig CR 文件。

    输出示例

    out
     └── argocd
          └── example
               └── optional-extra-manifest
                    └── ipsec
                         ├── 99-ipsec-master-endpoint-config.bu 1
                         ├── 99-ipsec-master-endpoint-config.yaml
                         ├── 99-ipsec-worker-endpoint-config.bu
                         ├── 99-ipsec-worker-endpoint-config.yaml
                         ├── build.sh
                         ├── ca.pem 2
                         ├── left_server.p12
                         ├── 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 fluentd 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 更改和更新的文件,并推送更改以置备受管集群并配置 IPsec 加密。

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

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

验证

要验证 IPsec 加密是否在受管单节点 OpenShift 集群中成功应用,请执行以下步骤:

  1. 运行以下命令为受管集群启动 debug 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

    输出示例

    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

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

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

spec.cpuPartitioningMode

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

注意

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

metadata.name

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

spec.clusterImageSetNameRef

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

installConfigOverrides

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

重要

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

spec.clusters.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.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 寻址的更多信息,请参阅"添加资源"部分。

注意

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

spec.clusters.nodes.bmcCredentialsName

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

spec.clusters.nodes.bootMode

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

spec.clusters.nodes.rootDeviceHints

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

spec.clusters.nodes.ignitionConfigOverride

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

spec.clusters.nodes.nodeNetwork

配置节点的网络设置。

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

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

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.