$ grep -r "ztp-deploy-wave" out/source-crs
您可以使用 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) 从存储在 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 来控制时间和已修复集群的集合。
为了自动化新部署集群的初始配置,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 安装。
从PolicyGenerator
或PolicyGentemplate
CR 生成的每个策略都包含一个ztp-deploy-wave
注释。此注释基于包含在该策略中的每个 CR 的相同注释。波次注释用于对自动生成的ClusterGroupUpgrade
CR 中的策略进行排序。除自动生成的ClusterGroupUpgrade
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 安装后,请勿操作此标签。
自动创建的ClusterGroupUpgrade
CR 将所有者引用设置为其派生的ManagedCluster
。此引用确保删除ManagedCluster
CR 会导致ClusterGroupUpgrade
实例及其任何支持资源一起被删除。
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) 后,以下操作将自动执行:
生成一个 Discovery 镜像 ISO 文件,并在目标主机上引导。
当 ISO 文件成功在目标主机上引导时,它会将主机硬件信息报告给 RHACM。
发现所有主机后,将安装 OpenShift Container Platform。
OpenShift Container Platform 安装完成后,中心集群将在目标集群上安装klusterlet
服务。
在目标集群上安装请求的附加组件服务。
当中心集群上创建托管集群的Agent
CR 时,Discovery 镜像 ISO 过程完成。
目标裸机主机必须满足推荐的用于 vDU 应用程序工作负载的单节点 OpenShift 集群配置中列出的网络、固件和硬件要求。 |
将托管裸机主机所需的Secret
自定义资源 (CR) 添加到中心集群。GitOps 零接触配置 (ZTP) 管道需要一个密钥才能访问基板管理控制器 (BMC),并且辅助安装程序服务需要一个密钥才能从注册表中提取集群安装镜像。
密钥通过名称从 |
创建一个 YAML 密钥文件,其中包含主机基板管理控制器 (BMC) 的凭据以及安装 OpenShift 和所有附加组件集群操作符所需的拉取密钥。
将以下 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编码的拉取密钥 |
将example-sno-secret.yaml
的相对路径添加到用于安装集群的kustomization.yaml
文件中。
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集群。
创建InfraEnv
CR并编辑spec.kernelArguments
规范以配置内核参数。
将以下YAML保存到InfraEnv-example.yaml
文件中
此示例中的 |
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内核参数。 |
将InfraEnv-example.yaml
CR提交到Git仓库中与SiteConfig
CR相同的目录,并推送更改。以下示例显示了一个样本Git仓库结构
~/example-ztp/install
└── site-install
├── siteconfig-example.yaml
├── InfraEnv-example.yaml
...
编辑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的内核参数。
开始与目标主机的SSH会话
$ ssh -i /path/to/privatekey core@<host_name>
使用以下命令查看系统的内核参数
$ cat /proc/cmdline
使用以下步骤创建SiteConfig
自定义资源(CR)和相关文件,并启动GitOps零接触配置(ZTP)集群部署。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
您已配置Hub集群以生成所需的安装和策略CR。
您已创建了一个Git仓库,用于管理您的自定义站点配置数据。该仓库必须可从Hub集群访问,并且您必须将其配置为ArgoCD应用程序的源仓库。有关更多信息,请参见“准备GitOps ZTP站点配置仓库”。
创建源仓库时,请确保使用从 |
为了准备好配置托管集群,每个裸机主机都需要以下内容:
您的网络需要DNS。托管集群主机应可从Hub集群访问。确保Hub集群和托管集群主机之间存在3层连接。
GitOps ZTP使用BMC用户名和密码详细信息在集群安装期间连接到BMC。GitOps ZTP插件根据站点Git仓库中的SiteConfig
CR管理Hub集群上的ManagedCluster
CR。您需要手动为每个主机创建单独的BMCSecret
CR。
在Hub集群上创建所需的托管集群密钥。这些资源必须位于与集群名称匹配的命名空间中。例如,在out/argocd/example/siteconfig/example-sno.yaml
中,集群名称和命名空间为example-sno
。
运行以下命令导出集群命名空间
$ export CLUSTERNS=example-sno
创建命名空间
$ oc create namespace $CLUSTERNS
为托管集群创建拉取密钥和BMC Secret
CR。拉取密钥必须包含安装OpenShift Container Platform和所有必需Operators所需的所有凭据。有关更多信息,请参见“创建托管裸机主机密钥”。
密钥通过名称从 |
在Git仓库的本地克隆中为您的集群创建SiteConfig
CR
从out/argocd/example/siteconfig/
文件夹中选择适合您的CR的示例。该文件夹包含单节点、三节点和标准集群的示例文件
example-sno.yaml
example-3node.yaml
example-standard.yaml
更改示例文件中的集群和主机详细信息以匹配您想要的集群类型。例如:
# 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寻址的更多信息,请参见“其他资源”部分。为了便于阅读,示例中扩展了 |
您可以在out/argocd/extra-manifest
中检查默认的额外清单MachineConfig
CR集。安装集群时会自动应用它。
可选:要在已配置的集群上配置其他安装时清单,请在您的Git仓库中创建一个目录,例如sno-extra-manifest/
,并将您的自定义清单CR添加到此目录。如果您的SiteConfig.yaml
在extraManifestPath
字段中引用此目录,则此引用的目录中的任何CR都将附加到默认的额外清单集。
启用crun OCI容器运行时
为了获得最佳集群性能,请在单节点OpenShift、带有额外工作节点的单节点OpenShift、三节点OpenShift和标准集群中为master节点和worker节点启用crun。 在
|
将SiteConfig
CR添加到generators
部分的kustomization.yaml
文件中,类似于out/argocd/example/siteconfig/kustomization.yaml
中所示的示例。
提交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 的加速配置目前仅为技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,从而能够在开发过程中测试功能并提供反馈。 有关 Red Hat 技术预览功能的支持范围的更多信息,请参阅 技术预览功能支持范围。 |
您可以使用 GitOps ZTP 的加速配置来缩短单节点 OpenShift 的集群安装时间。加速 ZTP 通过在更早阶段应用从策略派生的 Day 2 清单来加快安装速度。
仅当使用 Assisted Installer 安装单节点 OpenShift 时,才支持 GitOps ZTP 的加速配置。否则,此安装方法将失败。 |
您可以使用spec.clusters.clusterLabels.accelerated-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 Profile
、Tuned
和ContainerRuntimeConfig
类型的资源时进行的重启次数。TALM 在 RHACM 完成集群导入后,按照与标准 GitOps ZTP 相同的流程安装从策略派生的 Operator 订阅。
加速 ZTP 的好处会随着部署规模的增加而增加。在大量集群上使用accelerated-ztp: full
会带来更多好处。对于少量集群,安装时间的减少并不显著。完全加速的 ZTP 会在 spoke 上留下一个命名空间和一个已完成的作业,需要手动删除。
使用accelerated-ztp: partial
的一个好处是,如果标准实现出现问题或需要自定义功能,您可以覆盖 spoke 上作业的功能。
加速 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。
您可以在使用 GitOps ZTP 和 Red Hat Advanced Cluster Management (RHACM) 安装的托管单节点 OpenShift 集群中启用 IPsec 加密。您可以加密托管集群和托管集群外部的 IPsec 端点之间的流量。OVN-Kubernetes 集群网络上节点之间的所有网络流量都以传输模式使用 IPsec 加密。
您还可以按照此步骤为具有附加工作节点的单节点 OpenShift 集群配置 IPsec 加密。建议使用 |
您已安装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: '%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。 |
将以下证书添加到optional-extra-manifest/ipsec
文件夹
left_server.p12
:IPsec 端点的证书捆绑包
ca.pem
:您用来签署证书的证书颁发机构
每个主机上的网络安全服务 (NSS) 数据库都需要证书文件。这些文件将在后面的步骤中作为 Butane 配置的一部分导入。
在您维护自定义站点配置数据的 Git 仓库的optional-extra-manifest/ipsec
文件夹中打开一个 shell 提示符。
运行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.pem 和left_server.p12 证书文件。 |
在您管理自定义站点配置数据的存储库中创建一个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更改和您Git存储库中更新的文件,并将更改推送以配置托管集群并配置IPsec加密。
Argo CD管道检测到更改并开始托管集群部署。
在集群配置期间,GitOps ZTP管道将custom-manifest/
目录中的CR附加到存储在extra-manifest/
目录中的默认额外清单集。
有关验证IPsec加密的信息,请参见“验证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。
提取最新版本的ztp-site-generate
容器源代码,并将其与您管理自定义站点配置数据的仓库合并。
使用所需的值配置optional-extra-manifest/ipsec/ipsec-config-policy.yaml
文件,以在集群中配置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。 |
将以下证书添加到optional-extra-manifest/ipsec
文件夹
left_server.p12
:IPsec 端点的证书捆绑包
ca.pem
:您用来签署证书的证书颁发机构
每个主机上的网络安全服务 (NSS) 数据库都需要证书文件。这些文件将在后面的步骤中作为 Butane 配置的一部分导入。
在您维护自定义站点配置数据的 Git 仓库的optional-extra-manifest/ipsec
文件夹中打开一个 shell 提示符。
运行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.pem 和left_server.p12 证书文件。 |
在您管理自定义站点配置数据的存储库中创建一个custom-manifest/
文件夹,并将enable-ipsec.yaml
和99-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
在您的SiteConfig
CR中,将custom-manifest/
目录添加到extraManifests.searchPaths
字段,如下例所示:
clusters:
- clusterName: "site1-mno-du"
networkType: "OVNKubernetes"
extraManifests:
searchPaths:
- extra-manifest/
- custom-manifest/
将ipsec-config-policy.yaml
配置策略文件包含在GitOps中的source-crs
目录中,并在其中一个PolicyGenerator
CR中引用该文件。
提交SiteConfig
CR更改和您Git存储库中更新的文件,并将更改推送以配置托管集群并配置IPsec加密。
Argo CD管道检测到更改并开始托管集群部署。
在集群配置期间,GitOps ZTP管道将custom-manifest/
目录中的CR附加到存储在extra-manifest/
目录中的默认额外清单集。
有关验证IPsec加密的信息,请参见“验证IPsec加密”。
您可以验证IPsec加密是否已成功应用于托管的OpenShift Container Platform集群中。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
您已配置IPsec加密。
通过运行以下命令启动托管集群的调试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
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
SiteConfig CR字段 | 描述 | ||
---|---|---|---|
|
通过将
|
||
|
将 |
||
|
配置中心集群上可用于站点中所有集群的镜像集。要查看中心集群上受支持版本的列表,请运行 |
||
|
设置
|
||
|
指定用于部署单个集群的集群镜像集。如果已定义,它将覆盖站点级别的 |
||
|
配置集群标签以与您定义的 例如, |
||
|
可选。将 |
||
|
配置此字段以使用可信平台模块 (TPM) 和平台配置寄存器 (PCR) 保护启用磁盘加密。有关更多信息,请参见“关于使用TPM和PCR保护的磁盘加密”。
|
||
|
将磁盘加密类型设置为 |
||
|
配置平台配置寄存器 (PCR) 对磁盘加密的保护。 |
||
|
配置要用于磁盘加密的平台配置寄存器 (PCR) 列表。您必须使用PCR寄存器1和7。 |
||
|
对于单节点部署,请定义单个主机。对于三节点部署,请定义三个主机。对于标准部署,请定义三个具有 |
||
|
为托管集群中的节点指定自定义角色。这些是任何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 地址的更多信息,请参见“附加资源”部分。
|
||
|
配置您使用主机 BMC 凭据单独创建的 |
||
|
将主机的启动模式设置为 |
||
|
指定部署的设备。建议使用在重新引导后保持稳定的标识符。例如, |
||
|
可选。使用此字段为持久存储分配分区。将磁盘 ID 和大小调整为特定的硬件。 |
||
|
配置节点的网络设置。 |
||
|
配置主机的 IPv6 地址。对于具有静态 IP 地址的单节点 OpenShift 集群,节点特定的 API 和 Ingress IP 应该相同。 |
主机需要正确的固件配置才能确保高性能和最佳效率。您可以为使用 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 管理的集群。
检索托管集群的主机固件设置。运行以下命令
$ 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 字段下返回 |
可选:检查集群中HostFirmwareSettings
(hfs
) 自定义资源的状态
$ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="ChangeDetected")].status}'
True
可选:检查集群主机中无效的固件设置。运行以下命令
$ oc get hfs -n <managed_cluster_namespace> <managed_cluster_name> -o jsonpath='{.status.conditions[?(@.type=="Valid")].status}'
False
您可以通过配置SiteConfig
自定义资源 (CR) 以包含您想要在集群主机配置期间应用的硬件配置文件,将用户定义的固件设置部署到集群主机。您可以配置硬件配置文件以应用于以下场景中的主机
所有站点范围内的主机
仅满足特定条件的集群主机
单个集群主机
您可以配置以层次结构应用的主机硬件配置文件。集群级别设置会覆盖站点范围内的设置。节点级别配置文件会覆盖集群和站点范围内的设置。 |
您已安装OpenShift CLI (oc
)。
您已安装 Red Hat Advanced Cluster Management (RHACM) 并以具有cluster-admin
权限的用户身份登录到中心集群。
您已配置一个由 RHACM 管理的集群。
您创建了一个 Git 存储库,您可以在其中管理自定义站点配置数据。该存储库必须可以从中心集群访问,并被定义为 Argo CD 应用程序的源存储库。
创建包含您要应用的固件设置的主机固件配置文件。例如,创建以下 YAML 文件
BootMode: Uefi
LogicalProc: Enabled
ProcVirtualization: Enabled
保存相对于用于定义如何配置集群的kustomization.yaml
文件的硬件配置文件 YAML 文件,例如
example-ztp/install
└── site-install
├── siteconfig-example.yaml
├── kustomization.yaml
└── host-firmware.profile
编辑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 | 将硬件配置文件应用于所有站点范围内的集群主机 |
尽可能每个集群使用单个 |
可选。要将硬件配置文件应用于特定集群中的主机,请使用要应用的硬件配置文件更新clusters.biosConfigRef.filePath
。例如
clusters:
- clusterName: "cluster-1"
# ...
biosConfigRef:
filePath: "./host-firmware.profile" (1)
1 | 应用于cluster-1 集群中的所有主机 |
可选。要将硬件配置文件应用于集群中的特定主机,请使用要应用的硬件配置文件更新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 主机 |
提交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集群。
同步完成后,安装通常按如下方式进行
Assisted Service Operator 在集群上安装 OpenShift Container Platform。您可以通过运行以下命令从 RHACM 仪表板或命令行监控集群安装进度
导出集群名称
$ export CLUSTER=<clusterName>
查询AgentClusterInstall
CR 以获取托管集群
$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
获取集群的安装事件
$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'
ArgoCD 管道使用SiteConfig
和PolicyGenerator
或PolicyGentemplate
自定义资源 (CR) 来生成集群配置 CR 和 Red Hat Advanced Cluster Management (RHACM) 策略。请使用以下步骤来排查在此过程中可能发生的错误。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
使用以下命令检查是否已创建安装 CR
$ oc get AgentClusterInstall -n <cluster_name>
如果没有返回任何对象,请使用以下步骤来排查从SiteConfig
文件到安装 CR 的 ArgoCD 管道流程。
验证是否已使用中心集群上的SiteConfig
CR 生成ManagedCluster
CR
$ oc get managedcluster
如果缺少ManagedCluster
,请检查clusters
应用程序是否未能将文件从 Git 仓库同步到中心集群。
$ oc describe -n openshift-gitops application clusters
检查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
检查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
当使用https
协议提供镜像时,SuperMicro X11 服务器不支持虚拟介质安装。因此,此环境的单节点 OpenShift 部署无法在目标节点上启动。为避免此问题,请登录中心集群并在Provisioning
资源中禁用传输层安全性 (TLS)。这确保即使镜像地址使用https
方案,镜像也不会使用 TLS 提供。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
通过运行以下命令禁用Provisioning
资源中的 TLS
$ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
继续部署单节点 OpenShift 集群的步骤。
您可以从 GitOps 零接触配置 (ZTP) 管道中移除托管站点以及相关的安装和配置策略 CR。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
通过从kustomization.yaml
文件中移除相关的SiteConfig
和PolicyGenerator
或PolicyGentemplate
文件来移除站点和相关的 CR。
将以下syncOptions
字段添加到您的SiteConfig
应用程序。
kind: Application
spec:
syncPolicy:
syncOptions:
- PrunePropagationPolicy=background
再次运行 GitOps ZTP 管道时,生成的 CR 将被移除。
可选:如果您想永久移除站点,还应从 Git 仓库中移除SiteConfig
和特定站点的PolicyGenerator
或PolicyGentemplate
文件。
可选:如果您想暂时移除站点,例如在重新部署站点时,您可以将SiteConfig
和特定站点的PolicyGenerator
或PolicyGentemplate
CR 保留在 Git 仓库中。
有关移除集群的信息,请参阅从管理中移除集群。
如果对PolicyGenerator
或PolicyGentemplate
配置的更改导致策略过时,例如,如果重命名策略,请使用以下步骤移除过时的策略。
您已安装OpenShift CLI (oc
)。
您已以具有cluster-admin
权限的用户身份登录到Hub集群。
从 Git 仓库中移除受影响的PolicyGenerator
或PolicyGentemplate
文件,提交并推送到远程仓库。
等待更改通过应用程序同步,并从中心集群中移除受影响的策略。
将更新的PolicyGenerator
或PolicyGentemplate
文件添加回 Git 仓库,然后提交并推送到远程仓库。
从 Git 仓库中移除 GitOps 零接触配置 (ZTP) 策略,从而也从中心集群中移除它们,不会影响托管集群的配置。该策略管理的策略和 CR 保留在托管集群上。 |
可选:作为替代方案,在对导致策略过时的PolicyGenerator
或PolicyGentemplate
CR 进行更改后,您可以手动从中心集群中移除这些策略。您可以使用**治理**选项卡或运行以下命令从 RHACM 控制台中删除策略
$ oc delete policy -n <namespace> <policy_name>