4.5. 使用 SiteConfig 和 GitOps ZTP 部署受管集群
使用以下步骤创建 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。
流程
在 hub 集群中创建所需的受管集群 secret。这些资源必须位于名称与集群名称匹配的命名空间中。例如,在
out/argocd/example/siteconfig/example-sno.yaml
中,集群名称和命名空间是example-sno
。运行以下命令来导出集群命名空间:
$ export CLUSTERNS=example-sno
创建命名空间:
$ oc create namespace $CLUSTERNS
为受管集群创建 pull secret 和 BMC
Secret
CR。pull secret 必须包含安装 OpenShift Container Platform 和其他需要安装的 Operator 所需的所有凭证。如需更多信息,请参阅"创建受管裸机主机 secret"。注意secret 根据名称从
SiteConfig
自定义资源 (CR) 引用。命名空间必须与SiteConfig
命名空间匹配。在 Git 存储库本地克隆中为集群创建一个
SiteConfig
CR:从
out/argocd/example/siteconfig/
文件夹中选择适合您的 CR 示例。文件夹中包含单一节点、三节点和标准集群的示例文件:-
example-sno.yaml
-
example-3node.yaml
-
example-standard.yaml
-
更改示例文件中的集群和主机详情,以匹配您想要的集群类型。例如:
单节点 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 installConfigOverrides: | { "capabilities": { "baselineCapabilitySet": "None", "additionalEnabledCapabilities": [ "NodeTuning", "OperatorLifecycleManager" ] } } # 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-path/pci-0000:01:00.0-scsi-0:2:0:0", "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 寻址的更多信息,请参阅"添加资源"部分。
installConfigOverrides
和ignitionConfigOverride
字段在示例中扩展,以简化可读性。-
您可以在
out/argocd/extra-manifest
中检查默认的 extra-manifestMachineConfig
CR。它在安装时会自动应用到集群。 可选: 要在置备的集群中置备额外的安装清单,请在 Git 存储库中创建一个目录,如
sno-extra-manifest/
,并将自定义清单 CR 添加到这个目录中。如果您的SiteConfig.yaml
在extraManifestPath
字段中引用这个目录,则这个引用目录中的所有 CR 都会被附加到默认的额外的清单集合中。启用 crun OCI 容器运行时为获得最佳的集群性能,请在单节点 OpenShift 中为 master 和 worker 节点启用 crun,使用额外的 worker 节点、三节点 OpenShift 和标准集群中启用单节点 OpenShift。
在
ContainerRuntimeConfig
CR 中启用 crun,作为额外的第-0 天安装时间清单,以避免集群需要重启。enable-crun-master.yaml
和enable-crun-worker.yaml
CR 文件位于您可以从ztp-site-generate
容器中提取的out/source-crs/optional-extra-manifest/
文件夹中。如需更多信息,请参阅"在 GitOps ZTP 管道中自定义额外安装清单"。
-
在
kustomization.yaml
文件中将SiteConfig
CR 添加到generators
部分中 ,类似于out/argocd/example/siteconfig/kustomization.yaml
中显示的示例。 在 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. 单节点 OpenShift SiteConfig CR 安装参考
SiteConfig CR 字段 | 描述 |
---|---|
|
通过将 注意
使用 |
|
将 |
|
为站点中的所有集群配置 hub 集群上可用的镜像集。要查看 hub 集群上支持的版本列表,请运行 |
|
将 重要
使用示例 |
|
指定用于部署单个集群的集群镜像集。如果定义,它会在站点级别覆盖 |
|
配置集群标签,使其与您定义的 |
|
可选。将 |
|
对于单节点部署,请定义一个主机。对于三节点部署,请定义三个主机。对于标准部署,使用 |
| 为受管集群中的节点指定自定义角色。这些是其他角色,不供任何 OpenShift Container Platform 组件使用,仅限用户使用。添加自定义角色时,它可以与引用该角色的特定配置的自定义机器配置池相关联。在安装过程中添加自定义标签或角色可使部署过程更高效,并防止在安装完成后进行额外的重启。 |
|
可选。取消注释并将值设置为 |
| 用于访问主机的 BMC 地址。适用于所有集群类型。GitOps ZTP 支持使用 Redfish 或 IPMI 协议进行 iPXE 和虚拟介质引导。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 寻址的更多信息,请参阅"添加资源"部分。 |
| 用于访问主机的 BMC 地址。适用于所有集群类型。GitOps ZTP 支持使用 Redfish 或 IPMI 协议进行 iPXE 和虚拟介质引导。要使用 iPXE 启动,您必须使用 RHACM 2.8 或更高版本。有关 BMC 寻址的更多信息,请参阅"添加资源"部分。 注意 在边缘 Telco 用例中,只有虚拟介质可用于 GitOps ZTP。 |
|
配置使用主机 BMC 凭证单独创建的 |
|
将主机的引导模式设置为 |
|
指定用于部署的设备。建议在重启后保持标识符稳定。例如, |
| 可选。使用此字段为持久性存储分配分区。将磁盘 ID 和大小调整为特定的硬件。 |
| 配置节点的网络设置。 |
| 为主机配置 IPv6 地址。对于带有静态 IP 地址的单节点 OpenShift 集群,特定于节点的 API 和 Ingress IP 应该相同。 |