apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
name: common-latest
placementBindingDefaults:
name: common-latest-placement-binding (1)
policyDefaults:
namespace: ztp-common
placement:
labelSelector:
matchExpressions:
- key: common
operator: In
values:
- "true"
- key: du-profile
operator: In
values:
- latest
remediationAction: inform
severity: low
namespaceSelector:
exclude:
- kube-*
include:
- '*'
evaluationInterval:
compliant: 10m
noncompliant: 10s
policies:
- name: common-latest-config-policy
policyAnnotations:
ran.openshift.io/ztp-deploy-wave: "1"
manifests:
- path: source-crs/ReduceMonitoringFootprint.yaml
- path: source-crs/DefaultCatsrc.yaml (2)
patches:
- metadata:
name: redhat-operators-disconnected
spec:
displayName: disconnected-redhat-operators
image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
- path: source-crs/DisconnectedICSP.yaml
patches:
- spec:
repositoryDigestMirrors:
- mirrors:
- registry.example.com:5000
source: registry.redhat.io
- name: common-latest-subscriptions-policy
policyAnnotations:
ran.openshift.io/ztp-deploy-wave: "2"
manifests: (3)
- path: source-crs/SriovSubscriptionNS.yaml
- path: source-crs/SriovSubscriptionOperGroup.yaml
- path: source-crs/SriovSubscription.yaml
- path: source-crs/SriovOperatorStatus.yaml
- path: source-crs/PtpSubscriptionNS.yaml
- path: source-crs/PtpSubscriptionOperGroup.yaml
- path: source-crs/PtpSubscription.yaml
- path: source-crs/PtpOperatorStatus.yaml
- path: source-crs/ClusterLogNS.yaml
- path: source-crs/ClusterLogOperGroup.yaml
- path: source-crs/ClusterLogSubscription.yaml
- path: source-crs/ClusterLogOperatorStatus.yaml
- path: source-crs/StorageNS.yaml
- path: source-crs/StorageOperGroup.yaml
- path: source-crs/StorageSubscription.yaml
- path: source-crs/StorageOperatorStatus.yaml
×
使用 PolicyGenerator 资源配置托管集群策略
应用的Policy自定义资源(CR)配置您配置的托管集群。您可以自定义Red Hat高级集群管理(RHACM)如何使用PolicyGenerator CR生成应用的Policy CR。
|
将PolicyGenerator资源与GitOps ZTP一起使用仅是技术预览功能。技术预览功能不受Red Hat生产服务级别协议(SLA)的支持，并且可能功能不完整。Red Hat不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能，使客户能够在开发过程中测试功能并提供反馈。 有关Red Hat技术预览功能的支持范围的更多信息，请参见技术预览功能支持范围。 |
|
有关 |
比较 RHACM PolicyGenerator 和 PolicyGenTemplate 资源修补
PolicyGenerator 自定义资源 (CR) 和 PolicyGenTemplate CR 可用于 GitOps ZTP 为托管集群生成 RHACM 策略。
在使用 GitOps ZTP 修补 OpenShift Container Platform 资源时，使用PolicyGenerator CR 比使用PolicyGenTemplate CR 更有优势。使用 RHACM PolicyGenerator API 提供了一种通用的资源修补方法，而PolicyGenTemplate 资源无法实现。
PolicyGenerator API 是 Open Cluster Management 标准的一部分，而PolicyGenTemplate API 不是。下表描述了PolicyGenerator 和PolicyGenTemplate 资源修补和放置策略的比较。
|
使用 有关 |
| PolicyGenerator 修补 | PolicyGenTemplate 修补 |
|---|---|
使用 Kustomize 策略性合并来合并资源。有关更多信息，请参见 使用 Kustomize 声明式管理 Kubernetes 对象。 |
通过用修补程序中定义的值替换变量来工作。这不如 Kustomize 合并策略灵活。 |
支持 |
不支持 |
仅依赖于修补，不需要嵌入式变量替换。 |
覆盖修补程序中定义的变量值。 |
不支持在合并修补程序中合并列表。支持在合并修补程序中替换列表。 |
以有限的方式支持合并和替换列表 - 您只能合并列表中的一个对象。 |
当前不支持用于资源修补的 OpenAPI 规范。这意味着修补程序中需要其他指令才能合并不遵循模式的内容，例如 |
通过用修补程序中定义的值替换字段和值来工作。 |
需要其他指令，例如修补程序中的 |
用修补程序中定义的值替换源 CR 中定义的字段和值，例如 |
可以修补引用源 CR 中定义的 |
可以修补引用源 CR 中定义的 |
关于 PolicyGenerator CRD
PolicyGenerator 自定义资源定义 (CRD) 告诉PolicyGen 策略生成器要将哪些自定义资源 (CR) 包含在集群配置中，如何将 CR 组合到生成的策略中，以及需要使用覆盖内容更新这些 CR 中的哪些项目。
以下示例显示了从ztp-site-generate 参考容器中提取的PolicyGenerator CR (acm-common-du-ranGen.yaml)。acm-common-du-ranGen.yaml 文件定义了两个 Red Hat Advanced Cluster Management (RHACM) 策略。这些策略管理一系列配置 CR，每个 CR 的policyName 的唯一值对应一个。acm-common-du-ranGen.yaml 创建单个放置绑定和放置规则，以根据policyDefaults.placement.labelSelector 部分中列出的标签将策略绑定到集群。
PolicyGenerator CR 示例 - acm-common-ranGen.yaml
| 1 | 将策略应用于具有此标签的所有集群。 |
| 2 | DefaultCatsrc.yaml 文件包含断开连接的注册表和相关的注册表配置详细信息的目录源。 |
| 3 | policies.manifests 下列出的文件为已安装的集群创建 Operator 策略。 |
可以使用任意数量的包含的 CR 来构造PolicyGenerator CR。在中心集群中应用以下示例 CR 以生成包含单个 CR 的策略
apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
name: group-du-sno
placementBindingDefaults:
name: group-du-sno-placement-binding
policyDefaults:
namespace: ztp-group
placement:
labelSelector:
matchExpressions:
- key: group-du-sno
operator: Exists
remediationAction: inform
severity: low
namespaceSelector:
exclude:
- kube-*
include:
- '*'
evaluationInterval:
compliant: 10m
noncompliant: 10s
policies:
- name: group-du-sno-config-policy
policyAnnotations:
ran.openshift.io/ztp-deploy-wave: '10'
manifests:
- path: source-crs/PtpConfigSlave-MCP-master.yaml
patches:
- metadata: null
name: du-ptp-slave
namespace: openshift-ptp
annotations:
ran.openshift.io/ztp-deploy-wave: '10'
spec:
profile:
- name: slave
interface: $interface
ptp4lOpts: '-2 -s'
phc2sysOpts: '-a -r -n 24'
ptpSchedulingPolicy: SCHED_FIFO
ptpSchedulingPriority: 10
ptpSettings:
logReduce: 'true'
ptp4lConf: |
[global]
#
# Default Data Set
#
twoStepFlag 1
slaveOnly 1
priority1 128
priority2 128
domainNumber 24
#utc_offset 37
clockClass 255
clockAccuracy 0xFE
offsetScaledLogVariance 0xFFFF
free_running 0
freq_est_interval 1
dscp_event 0
dscp_general 0
dataset_comparison G.8275.x
G.8275.defaultDS.localPriority 128
#
# Port Data Set
#
logAnnounceInterval -3
logSyncInterval -4
logMinDelayReqInterval -4
logMinPdelayReqInterval -4
announceReceiptTimeout 3
syncReceiptTimeout 0
delayAsymmetry 0
fault_reset_interval -4
neighborPropDelayThresh 20000000
masterOnly 0
G.8275.portDS.localPriority 128
#
# Run time options
#
assume_two_step 0
logging_level 6
path_trace_enabled 0
follow_up_info 0
hybrid_e2e 0
inhibit_multicast_service 0
net_sync_monitor 0
tc_spanning_tree 0
tx_timestamp_timeout 50
unicast_listen 0
unicast_master_table 0
unicast_req_duration 3600
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0
clock_class_threshold 7
#
# Servo Options
#
pi_proportional_const 0.0
pi_integral_const 0.0
pi_proportional_scale 0.0
pi_proportional_exponent -0.3
pi_proportional_norm_max 0.7
pi_integral_scale 0.0
pi_integral_exponent 0.4
pi_integral_norm_max 0.3
step_threshold 2.0
first_step_threshold 0.00002
max_frequency 900000000
clock_servo pi
sanity_freq_limit 200000000
ntpshm_segment 0
#
# Transport options
#
transportSpecific 0x0
ptp_dst_mac 01:1B:19:00:00:00
p2p_dst_mac 01:80:C2:00:00:0E
udp_ttl 1
udp6_scope 0x0E
uds_address /var/run/ptp4l
#
# Default interface options
#
clock_type OC
network_transport L2
delay_mechanism E2E
time_stamping hardware
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0
#
# Clock description
#
productDescription ;;
revisionData ;;
manufacturerIdentity 00:00:00
userDescription ;
timeSource 0xA0
recommend:
- profile: slave
priority: 4
match:
- nodeLabel: node-role.kubernetes.io/master以源文件PtpConfigSlave.yaml 为例，该文件定义了PtpConfig CR。生成的PtpConfigSlave 示例策略名为group-du-sno-config-policy。在生成的group-du-sno-config-policy 中定义的PtpConfig CR 名为du-ptp-slave。PtpConfigSlave.yaml 中定义的spec 与源文件中定义的其他spec 项目一起放在du-ptp-slave 下。
以下示例显示了group-du-sno-config-policy CR
---
apiVersion: policy.open-cluster-management.io/v1
kind: PolicyGenerator
metadata:
name: du-upgrade
placementBindingDefaults:
name: du-upgrade-placement-binding
policyDefaults:
namespace: ztp-group-du-sno
placement:
labelSelector:
matchExpressions:
- key: group-du-sno
operator: Exists
remediationAction: inform
severity: low
namespaceSelector:
exclude:
- kube-*
include:
- '*'
evaluationInterval:
compliant: 10m
noncompliant: 10s
policies:
- name: du-upgrade-operator-catsrc-policy
policyAnnotations:
ran.openshift.io/ztp-deploy-wave: "1"
manifests:
- path: source-crs/DefaultCatsrc.yaml
patches:
- metadata:
name: redhat-operators
spec:
displayName: Red Hat Operators Catalog
image: registry.example.com:5000/olm/redhat-operators:v4.14
updateStrategy:
registryPoll:
interval: 1h
status:
connectionState:
lastObservedState: READY自定义 PolicyGenerator CR 时的建议
自定义站点配置PolicyGenerator 自定义资源 (CR) 时，请考虑以下最佳实践
-
仅使用必要的策略。使用较少的策略需要较少的资源。每个额外的策略都会增加中心集群和已部署的托管集群的 CPU 负载。基于
PolicyGeneratorCR 中的policyName字段将 CR 组合到策略中。在同一个PolicyGenerator中具有相同policyName值的 CR 在单个策略下进行管理。 -
在断开连接的环境中，通过将注册表配置为包含所有 Operator 的单个索引，为所有 Operator 使用单个目录源。托管集群上的每个额外的
CatalogSourceCR 都会增加 CPU 使用率。 -
应在
SiteConfigCR 中将MachineConfigCR 包含为extraManifests，以便在安装期间应用它们。这可以减少集群准备好部署应用程序所需的时间。 -
PolicyGeneratorCR 应覆盖 channel 字段以明确标识所需版本。这确保了升级期间源 CR 的更改不会更新生成的订阅。
其他资源
-
有关使用 RHACM 扩展集群的建议，请参见 性能和可扩展性。
|
在中心集群上管理大量 spoke 集群时，请尽量减少策略数量以减少资源消耗。 将多个配置 CR 分组到一个或少量策略中是减少中心集群上策略总数的一种方法。当使用策略的公共、组和站点层次结构来管理站点配置时，将站点特定配置组合到单个策略中尤其重要。 |
用于 RAN 部署的 PolicyGenerator CR
使用PolicyGenerator 自定义资源 (CR) 通过使用 GitOps 零接触配置 (ZTP) 管道来自定义应用于集群的配置。PolicyGenerator CR 允许您生成一个或多个策略来管理集群集群上的一组配置 CR。PolicyGenerator CR 识别已管理的 CR 集，将它们捆绑到策略中，构建围绕这些 CR 的策略包装，并通过使用标签绑定规则将策略与集群关联。
从 GitOps ZTP 容器获得的参考配置旨在提供一组关键功能和节点调整设置，以确保集群能够支持 RAN（无线接入网络）分布式单元 (DU) 应用程序通常严格的性能和资源利用率约束。与基线配置相比的更改或遗漏可能会影响功能可用性、性能和资源利用率。使用参考PolicyGenerator CR 作为创建针对特定站点要求定制的配置文件层次结构的基础。
为 RAN DU 集群配置定义的基线PolicyGenerator CR 可以从 GitOps ZTP ztp-site-generate 容器中提取。更多详情请参见“准备 GitOps ZTP 站点配置仓库”。
PolicyGenerator CR 位于./out/argocd/example/acmpolicygenerator/文件夹中。参考架构包含通用、组和特定于站点的配置 CR。每个PolicyGenerator CR 都引用其他 CR，这些 CR 位于./out/source-crs文件夹中。
下面描述了与 RAN 集群配置相关的PolicyGenerator CR。针对单节点、三节点紧凑型和标准集群配置的差异，提供了组PolicyGenerator CR 的变体。类似地，针对单节点集群和多节点（紧凑型或标准型）集群，也提供了特定于站点的配置变体。请使用与您的部署相关的组和特定于站点的配置变体。
| PolicyGenerator CR | 描述 |
|---|---|
|
包含应用于多节点集群的一组 CR。这些 CR 配置 RAN 安装中常见的 SR-IOV 功能。 |
|
包含应用于单节点 OpenShift 集群的一组 CR。这些 CR 配置 RAN 安装中常见的 SR-IOV 功能。 |
|
包含应用于多节点集群的一组通用的 RAN 策略配置。 |
|
包含应用于所有集群的一组通用的 RAN CR。这些 CR 订阅一组提供 RAN 典型集群功能以及基线集群调优的 operators。 |
|
仅包含三节点集群的 RAN 策略。 |
|
仅包含单节点集群的 RAN 策略。 |
|
包含标准三控制平面集群的 RAN 策略。 |
|
用于生成三节点集群所需各种策略的 |
|
用于生成标准集群所需各种策略的 |
|
用于生成单节点 OpenShift 集群所需各种策略的 |
其他资源
使用 PolicyGenerator CR 自定义托管集群
使用以下步骤自定义应用于使用 GitOps 零接触配置 (ZTP) 管道配置的托管集群的策略。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录到 hub 集群。 -
您已配置 hub 集群以生成所需的安装和策略 CR。
-
您已创建了一个 Git 仓库，用于管理您的自定义站点配置数据。该仓库必须可从 hub 集群访问，并被定义为 Argo CD 应用的源仓库。
步骤
-
为特定于站点的配置 CR 创建
PolicyGeneratorCR。-
从
out/argocd/example/acmpolicygenerator/文件夹中选择适合您 CR 的示例，例如acm-example-sno-site.yaml或acm-example-multinode-site.yaml。 -
更改示例文件中的
policyDefaults.placement.labelSelector字段以匹配SiteConfigCR 中包含的特定于站点的标签。在示例SiteConfig文件中，特定于站点的标签为sites: example-sno。确保在您的
PolicyGeneratorpolicyDefaults.placement.labelSelector字段中定义的标签与相关托管集群SiteConfigCR 中定义的标签相对应。 -
更改示例文件中的内容以匹配所需的配置。
-
-
可选：为应用于整个集群群的任何通用配置 CR 创建
PolicyGeneratorCR。-
从
out/argocd/example/acmpolicygenerator/文件夹中选择适合您 CR 的示例，例如acm-common-ranGen.yaml。 -
更改示例文件中的内容以匹配所需的配置。
-
-
可选：为应用于集群群中某些集群组的任何组配置 CR 创建
PolicyGeneratorCR。确保覆盖的 spec 文件的内容与您所需的最终状态匹配。作为参考，
out/source-crs目录包含可由您的 PolicyGenerator 模板包含和覆盖的完整源 cr 列表。根据集群的具体需求，您可能需要每个集群类型多个组策略，尤其考虑到示例组策略每个都只有一个
PerformancePolicy.yaml文件，只有当这些集群具有相同的硬件配置时，才能在这些集群之间共享。-
从
out/argocd/example/acmpolicygenerator/文件夹中选择适合您 CR 的示例，例如acm-group-du-sno-ranGen.yaml。 -
更改示例文件中的内容以匹配所需的配置。
-
-
可选。创建一个验证器信息策略
PolicyGeneratorCR 以在已部署集群的 GitOps ZTP 安装和配置完成后发出信号。更多信息，请参见“创建验证器信息策略”。 -
在类似于示例
out/argocd/example/acmpolicygenerator//ns.yaml文件的 YAML 文件中定义所有策略命名空间。不要在与
PolicyGeneratorCR 相同的文件中包含NamespaceCR。 -
将
PolicyGeneratorCR 和NamespaceCR 添加到 generators 部分的kustomization.yaml文件中，类似于out/argocd/example/acmpolicygenerator/kustomization.yaml中显示的示例。 -
在您的 Git 仓库中提交
PolicyGeneratorCR、NamespaceCR 和相关的kustomization.yaml文件，然后推送更改。ArgoCD 管道会检测这些更改并开始托管集群部署。您可以同时将更改推送到
SiteConfigCR 和PolicyGeneratorCR。
监控托管集群策略部署进度
ArgoCD 管道使用 Git 中的PolicyGenerator CR 生成 RHACM 策略，然后将其同步到 hub 集群。辅助服务在托管集群上安装 OpenShift Container Platform 后，您可以监控托管集群策略同步的进度。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录到 hub 集群。
步骤
-
拓扑感知生命周期管理器 (TALM) 应用绑定到集群的配置策略。
集群安装完成后且集群状态变为
Ready后，TALM 会自动创建一个与该集群对应的ClusterGroupUpgradeCR，其中包含由ran.openshift.io/ztp-deploy-wave注释定义的已排序策略列表。集群的策略将按照ClusterGroupUpgradeCR 中列出的顺序应用。您可以使用以下命令监控配置策略协调的高级进度
$ export CLUSTER=<clusterName>$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq示例输出{ "lastTransitionTime": "2022-11-09T07:28:09Z", "message": "Remediating non-compliant policies", "reason": "InProgress", "status": "True", "type": "Progressing" } -
您可以使用 RHACM 仪表板或命令行监控详细的集群策略合规性状态。
-
要使用
oc检查策略合规性，请运行以下命令$ oc get policies -n $CLUSTER示例输出NAME REMEDIATION ACTION COMPLIANCE STATE AGE ztp-common.common-config-policy inform Compliant 3h42m ztp-common.common-subscriptions-policy inform NonCompliant 3h42m ztp-group.group-du-sno-config-policy inform NonCompliant 3h42m ztp-group.group-du-sno-validator-du-policy inform NonCompliant 3h42m ztp-install.example1-common-config-policy-pjz9s enforce Compliant 167m ztp-install.example1-common-subscriptions-policy-zzd9k enforce NonCompliant 164m ztp-site.example1-config-policy inform NonCompliant 3h42m ztp-site.example1-perf-policy inform NonCompliant 3h42m -
要从 RHACM Web 控制台检查策略状态，请执行以下操作
-
单击**治理** → **查找策略**。
-
单击集群策略以检查其状态。
-
-
当所有集群策略都符合要求时，集群的 GitOps ZTP 安装和配置完成。ztp-done 标签将添加到集群。
在参考配置中，最终符合要求的策略是在*-du-validator-policy 策略中定义的策略。此策略在集群上符合要求时，可确保所有集群配置、Operator 安装和 Operator 配置均已完成。
验证配置策略 CR 的生成
Policy 自定义资源 (CR) 在与创建它们的PolicyGenerator相同的命名空间中生成。无论策略是基于ztp-common、ztp-group 还是ztp-site，所有从PolicyGenerator 生成的策略 CR 都适用相同的故障排除流程，如下面的命令所示
$ export NS=<namespace>$ oc get policy -n $NS应显示预期的策略包装 CR 集。
如果策略同步失败，请使用以下故障排除步骤。
步骤
-
要显示有关策略的详细信息，请运行以下命令
$ oc describe -n openshift-gitops application policies -
检查
Status: Conditions:以显示错误日志。例如，将无效的sourceFile条目设置为fileName:会生成如下所示的错误Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonError -
检查
Status: Sync:。如果Status: Conditions:中存在日志错误，则Status: Sync:显示Unknown或ErrorStatus: Sync: Compared To: Destination: Namespace: policies-sub Server: https://kubernetes.default.svc Source: Path: policies Repo URL: https://git.com/ran-sites/policies/.git Target Revision: master Status: Error -
当 Red Hat Advanced Cluster Management (RHACM) 识别出策略适用于
ManagedCluster对象时，策略 CR 对象将应用于集群命名空间。检查策略是否已复制到集群命名空间$ oc get policy -n $CLUSTER示例输出NAME REMEDIATION ACTION COMPLIANCE STATE AGE ztp-common.common-config-policy inform Compliant 13d ztp-common.common-subscriptions-policy inform Compliant 13d ztp-group.group-du-sno-config-policy inform Compliant 13d ztp-group.group-du-sno-validator-du-policy inform Compliant 13d ztp-site.example-sno-config-policy inform Compliant 13dRHACM 将所有适用的策略复制到集群命名空间。复制的策略名称格式为：
<PolicyGenerator.Namespace>.<PolicyGenerator.Name>-<policyName>。 -
检查任何未复制到集群命名空间的策略的放置规则。这些策略的
Placement中的matchSelector应与ManagedCluster对象上的标签匹配$ oc get Placement -n $NS -
使用以下命令记下适用于缺少的策略（common、group 或 site）的
Placement名称$ oc get Placement -n $NS <placement_rule_name> -o yaml-
状态决策应包含您的集群名称。
-
spec中matchSelector的键值对必须与托管集群上的标签匹配。
-
-
使用以下命令检查
ManagedCluster对象上的标签$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq -
使用以下命令检查哪些策略符合要求
$ oc get policy -n $CLUSTER如果
Namespace、OperatorGroup和Subscription策略符合要求，但 Operator 配置策略不符合要求，则可能是 Operator 未安装在托管集群上。这会导致 Operator 配置策略无法应用，因为 CRD 尚未应用到 spoke。
重新启动策略协调
当出现意外的合规性问题时，例如ClusterGroupUpgrade自定义资源 (CR) 超时时，您可以重新启动策略协调。
步骤
-
托管集群变为
Ready后，拓扑感知生命周期管理器会在ztp-install命名空间中生成一个ClusterGroupUpgradeCR$ export CLUSTER=<clusterName>$ oc get clustergroupupgrades -n ztp-install $CLUSTER -
如果出现意外问题并且策略在配置的超时时间内（默认为 4 小时）未能符合要求，则
ClusterGroupUpgradeCR 的状态将显示为UpgradeTimedOut$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}' -
处于
UpgradeTimedOut状态的ClusterGroupUpgradeCR 会每小时自动重新启动其策略协调。如果您已更改策略，则可以通过删除现有的ClusterGroupUpgradeCR 来立即启动重试。这将触发自动创建新的ClusterGroupUpgradeCR，该 CR 将立即开始协调策略$ oc delete clustergroupupgrades -n ztp-install $CLUSTER
请注意，当ClusterGroupUpgrade CR 完成并状态为UpgradeCompleted且托管集群已应用标签ztp-done时，您可以使用PolicyGenerator进行其他配置更改。删除现有的ClusterGroupUpgrade CR 不会使 TALM 生成新的 CR。
此时，GitOps ZTP 已完成与集群的交互，任何进一步的交互都应视为更新，并为策略修复创建新的ClusterGroupUpgrade CR。
其他资源
-
有关使用拓扑感知生命周期管理器 (TALM) 构造您自己的
ClusterGroupUpgradeCR 的信息，请参见关于 ClusterGroupUpgrade CR。
使用策略更改应用的托管集群 CR
您可以从通过策略部署在托管集群中的自定义资源 (CR) 中删除内容。
默认情况下，从PolicyGenerator CR 创建的所有Policy CR 的complianceType字段都设置为musthave。没有删除内容的musthave策略仍然符合要求，因为托管集群上的 CR 具有所有指定的内容。在此配置下，当您从 CR 中删除内容时，TALM 会从策略中删除内容，但不会从托管集群上的 CR 中删除内容。
使用complianceType字段设置为mustonlyhave，策略确保集群上的 CR 与策略中指定的 CR 完全匹配。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录到 hub 集群。 -
您已从运行 RHACM 的 hub 集群部署了托管集群。
-
您已在 hub 集群上安装了拓扑感知生命周期管理器。
步骤
-
从受影响的 CR 中删除不再需要的內容。在此示例中，
disableDrain: false行已从SriovOperatorConfigCR 中删除。示例 CRapiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: configDaemonNodeSelector: "node-role.kubernetes.io/$mcp": "" disableDrain: true enableInjector: true enableOperatorWebhook: true -
在
acm-group-du-sno-ranGen.yaml文件中将受影响策略的complianceType更改为mustonlyhave。示例 YAML# ... policyDefaults: complianceType: "mustonlyhave" # ... policies: - name: config-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "" manifests: - path: source-crs/SriovOperatorConfig.yaml -
创建一个
ClusterGroupUpdatesCR 并指定必须接收 CR 更改的集群：示例 ClusterGroupUpdates CRapiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-remove namespace: default spec: managedPolicies: - ztp-group.group-du-sno-config-policy enable: false clusters: - spoke1 - spoke2 remediationStrategy: maxConcurrency: 2 timeout: 240 batchTimeoutAction: -
运行以下命令创建
ClusterGroupUpgradeCR$ oc create -f cgu-remove.yaml -
准备好应用更改时（例如，在适当的维护窗口期间），通过运行以下命令将
spec.enable字段的值更改为true$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
验证
-
运行以下命令检查策略的状态
$ oc get <kind> <changed_cr_name>示例输出NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h当策略的
合规性状态为符合要求时，表示 CR 已更新且已删除不需要的内容。 -
通过在托管集群上运行以下命令，检查策略是否已从目标集群中删除
$ oc get <kind> <changed_cr_name>如果没有结果，则表示 CR 已从托管集群中删除。
GitOps ZTP 安装完成的指示
GitOps 零接触配置 (ZTP) 简化了检查集群 GitOps ZTP 安装状态的过程。GitOps ZTP 状态会经历三个阶段：集群安装、集群配置和 GitOps ZTP 完成。
- 集群安装阶段
-
集群安装阶段由
ManagedClusterCR 中的ManagedClusterJoined和ManagedClusterAvailable条件指示。如果ManagedClusterCR 不包含这些条件，或者条件设置为False，则集群仍处于安装阶段。有关安装的更多详细信息，请参阅AgentClusterInstall和ClusterDeploymentCR。更多信息，请参见“GitOps ZTP 故障排除”。 - 集群配置阶段
-
集群配置阶段由应用于集群
ManagedClusterCR 的ztp-running标签指示。 - GitOps ZTP 完成
-
在 GitOps ZTP 完成阶段，集群安装和配置完成。这通过删除
ztp-running标签并向ManagedClusterCR 添加ztp-done标签来指示。ztp-done标签表示配置已应用，并且基线 DU 配置已完成集群调整。GitOps ZTP 完成状态的更改取决于 Red Hat Advanced Cluster Management (RHACM) 验证器信息策略的合规状态。此策略捕获已完成安装的现有标准，并且仅在托管集群的 GitOps ZTP 配置完成时才将其验证为合规状态。
验证器信息策略确保集群配置已完全应用，并且 Operators 已完成其初始化。该策略验证以下内容：
-
目标
MachineConfigPool包含预期条目并已完成更新。所有节点都可用且未降级。 -
SR-IOV Operator 已完成初始化，至少一个
SriovNetworkNodeState的syncStatus: Succeeded指示了这一点。 -
PTP Operator 守护程序集存在。
-