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.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
注意有关 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. 加速置备 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: partial
,GitOps ZTP 不包括加速的作业清单,但会包括以下 kind
类型的集群安装过程中创建的 policy-derived 对象:
-
PerformanceProfile.performance.openshift.io
-
Tuned.tuned.openshift.io
-
Namespace
-
CatalogSource.operators.coreos.com
-
ContainerRuntimeConfig.machineconfiguration.openshift.io
在应用 Performance Profile
、Tuned
和 ContainerRuntimeConfig
资源时,这个部分加速可以减少节点完成的重启数量。TALM 在 RHACM 完成导入集群后安装从策略派生的 Operator 订阅,遵循与标准 GitOps ZTP 相同的流程。
加速 ZTP 的好处会随着部署的规模而增加。对于带有大量集群的环境,使用 accelerated-ztp: full
会有更多好处。如果集群数量较少,则对减少安装时间的效果会显著减少。全加速 ZTP 会在 spoke 上保留一个命名空间和完成的作业,它们需要被手工删除。
使用 accelerated-ztp: partial
的好处之一是,如果 stock 实施出现问题,或者需要自定义功能,您可以覆盖 on-spoke 任务的功能。
4.5.1.2. 加速 ZTP 进程
加速 ZTP 使用额外的 ConfigMap
来创建从 spoke 集群上的策略派生的资源。标准 ConfigMap
包含 GitOps ZTP 工作流用来自定义集群安装的清单。
TALM 检测到设置了 accelerated-ztp
标签,然后创建了第二个 ConfigMap
。作为加速 ZTP 的一部分,SiteConfig
生成器会添加到第二个 ConfigMap
的引用,其名称的格式是 <spoke-cluster-name>-aztp
。
在 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 端点的 PKCS#12 证书,以及一个 PEM 格式的 CA 证书。
流程
-
提取
ztp-site-generate
容器源的最新版本,并将其与您管理自定义站点配置数据的存储库合并。 使用在集群中配置 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
将您的
ca.pem
和left_server.p12
证书添加到optional-extra-manifest/ipsec
文件夹中。每个主机上的网络安全服务 (NSS) 数据库都需要证书文件。这些文件在后续步骤中作为 Butane 配置的一部分导入。-
left_server.p12
:IPsec 端点的证书捆绑包 -
ca.pem
:您使用签名证书的证书颁发机构
-
-
在您维护自定义站点配置数据的 Git 存储库的
optional-extra-manifest/ipsec
文件夹下打开 shell 提示符。 运行
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
在您管理自定义站点配置数据的存储库中创建
custom-manifest/
文件夹。将enable-ipsec.yaml
和99-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
在
SiteConfig
CR 中,将custom-manifest/
目录添加到extraManifests.searchPaths
字段中。例如:clusters: - clusterName: "site1-sno-du" networkType: "OVNKubernetes" extraManifests: searchPaths: - extra-manifest/ - custom-manifest/
提交
SiteConfig
CR 更改和更新的文件,并推送更改以置备受管集群并配置 IPsec 加密。ArgoCD 管道检测到更改并开始受管集群部署。
在集群置备过程中,GitOps ZTP 管道会将
/custom-manifest
目录中的 CR 附加到存储在extra-manifest/
中的默认额外清单集合中。
验证
要验证 IPsec 加密是否在受管单节点 OpenShift 集群中成功应用,请执行以下步骤:
运行以下命令为受管集群启动 debug pod:
$ oc debug node/<node_name>
检查 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
检查 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
在外部主机子网中 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 安装参考
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 应该相同。 |