$ mkdir -p ./out
×
使用 PolicyGenerator 资源进行高级托管集群配置
您可以使用PolicyGenerator CR 在托管集群中部署自定义功能。
|
使用 PolicyGenerator 资源与 GitOps ZTP 只是一个技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持，并且功能可能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能，从而能够在开发过程中测试功能并提供反馈。 有关 Red Hat 技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。 |
|
有关 |
将其他更改部署到集群
如果您需要对基本 GitOps 零接触配置 (ZTP) 管道配置之外的集群配置进行更改，则有三个选项：
- 在 GitOps ZTP 管道完成后应用其他配置
-
GitOps ZTP 管道部署完成后，已部署的集群已准备好用于应用程序工作负载。此时，您可以安装其他运算符并应用特定于您需求的配置。确保其他配置不会对平台的性能或分配的 CPU 预算产生负面影响。
- 向 GitOps ZTP 库添加内容
-
您可以根据需要使用 GitOps ZTP 管道部署的基本源自定义资源 (CR) 进行扩充。
- 为集群安装创建额外的清单
-
额外的清单在安装期间应用，并使安装过程更高效。
|
提供额外的源 CR 或修改现有的源 CR 会显著影响 OpenShift Container Platform 的性能或 CPU 配置文件。 |
使用 PolicyGenerator CR 覆盖源 CR 内容
PolicyGenerator 自定义资源 (CR) 允许您在 ztp-site-generate 容器中 GitOps 插件提供的基础源 CR 之上叠加额外的配置详细信息。您可以将 PolicyGenerator CR 视为基础 CR 的逻辑合并或补丁。使用 PolicyGenerator CR 更新基础 CR 的单个字段，或覆盖基础 CR 的全部内容。您可以更新值并插入基础 CR 中不存在的字段。
以下示例过程描述了如何根据 acm-group-du-sno-ranGen.yaml 文件中的 PolicyGenerator CR，更新为参考配置生成的 PerformanceProfile CR 中的字段。请将此过程作为修改其他 PolicyGenerator 部分的基础，具体取决于您的需求。
先决条件
-
创建一个 Git 仓库来管理您的自定义站点配置数据。该仓库必须可以从 hub 集群访问，并被定义为 Argo CD 的源仓库。
步骤
-
查看基线源 CR 的现有内容。您可以通过从 GitOps 零接触配置 (ZTP) 容器中提取它们来查看参考
PolicyGeneratorCR 中列出的源 CR。-
创建一个
/out文件夹 -
提取源 CR
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.17.1 extract /home/ztp --tar | tar x -C ./out
-
-
查看
./out/source-crs/PerformanceProfile.yaml中的基线PerformanceProfileCRapiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: $name annotations: ran.openshift.io/ztp-deploy-wave: "10" spec: additionalKernelArgs: - "idle=poll" - "rcupdate.rcu_normal_after_boot=0" cpu: isolated: $isolated reserved: $reserved hugepages: defaultHugepagesSize: $defaultHugepagesSize pages: - size: $size count: $count node: $node machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/$mcp: "" net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/$mcp: '' numa: topologyPolicy: "restricted" realTimeKernel: enabled: true如果源 CR 中的任何包含
$…的字段未在PolicyGeneratorCR 中提供，则这些字段将从生成的 CR 中删除。 -
更新
acm-group-du-sno-ranGen.yaml参考文件中的PerformanceProfile的PolicyGenerator条目。以下示例PolicyGeneratorCR 节提供了合适的 CPU 规格，设置了hugepages配置，并添加了一个新字段，将globallyDisableIrqLoadBalancing设置为 false。- path: source-crs/PerformanceProfile.yaml patches: - spec: # These must be tailored for the specific hardware platform cpu: isolated: "2-19,22-39" reserved: "0-1,20-21" hugepages: defaultHugepagesSize: 1G pages: - size: 1G count: 10 globallyDisableIrqLoadBalancing: false -
提交 Git 中的
PolicyGenerator更改，然后推送到 GitOps ZTP Argo CD 应用程序监控的 Git 仓库。示例输出GitOps ZTP 应用程序生成一个包含生成的
PerformanceProfileCR 的 RHACM 策略。该 CR 的内容是通过将PolicyGenerator中PerformanceProfile条目的metadata和spec内容合并到源 CR 中得出的。生成的 CR 具有以下内容--- apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: openshift-node-performance-profile spec: additionalKernelArgs: - idle=poll - rcupdate.rcu_normal_after_boot=0 cpu: isolated: 2-19,22-39 reserved: 0-1,20-21 globallyDisableIrqLoadBalancing: false hugepages: defaultHugepagesSize: 1G pages: - count: 10 size: 1G machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/master: "" net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/master: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true
|
在您从 一个例外是
|
向 GitOps ZTP 管道添加自定义内容
执行以下步骤以向 GitOps ZTP 管道添加新内容。
步骤
-
在包含
PolicyGenerator自定义资源 (CR) 的kustomization.yaml文件的目录中创建一个名为source-crs的子目录。 -
将您提供的用户 CR 添加到
source-crs子目录，如下例所示example └── acmpolicygenerator ├── dev.yaml ├── kustomization.yaml ├── mec-edge-sno1.yaml ├── sno.yaml └── source-crs (1) ├── PaoCatalogSource.yaml ├── PaoSubscription.yaml ├── custom-crs | ├── apiserver-config.yaml | └── disable-nic-lldp.yaml └── elasticsearch ├── ElasticsearchNS.yaml └── ElasticsearchOperatorGroup.yaml1 source-crs子目录必须与kustomization.yaml文件位于同一目录。 -
更新所需的
PolicyGeneratorCR 以包含对您在source-crs/custom-crs和source-crs/elasticsearch目录中添加的内容的引用。例如apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: group-dev placementBindingDefaults: name: group-dev-placement-binding policyDefaults: namespace: ztp-clusters placement: labelSelector: matchExpressions: - key: dev operator: In values: - "true" remediationAction: inform severity: low namespaceSelector: exclude: - kube-* include: - '*' evaluationInterval: compliant: 10m noncompliant: 10s policies: - name: group-dev-group-dev-cluster-log-ns policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/ClusterLogNS.yaml - name: group-dev-group-dev-cluster-log-operator-group policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/ClusterLogOperGroup.yaml - name: group-dev-group-dev-cluster-log-sub policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/ClusterLogSubscription.yaml - name: group-dev-group-dev-lso-ns policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/StorageNS.yaml - name: group-dev-group-dev-lso-operator-group policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/StorageOperGroup.yaml - name: group-dev-group-dev-lso-sub policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/StorageSubscription.yaml - name: group-dev-group-dev-pao-cat-source policyAnnotations: ran.openshift.io/ztp-deploy-wave: "1" manifests: - path: source-crs/PaoSubscriptionCatalogSource.yaml patches: - spec: image: <container_image_url> - name: group-dev-group-dev-pao-ns policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/PaoSubscriptionNS.yaml - name: group-dev-group-dev-pao-sub policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/PaoSubscription.yaml - name: group-dev-group-dev-elasticsearch-ns policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: elasticsearch/ElasticsearchNS.yaml (1) - name: group-dev-group-dev-elasticsearch-operator-group policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: elasticsearch/ElasticsearchOperatorGroup.yaml - name: group-dev-group-dev-apiserver-config policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: custom-crs/apiserver-config.yaml (1) - name: group-dev-group-dev-disable-nic-lldp policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: custom-crs/disable-nic-lldp.yaml1 设置 policies.manifests.path以包含从/source-crs父目录到文件的相对路径。 -
提交 Git 中的
PolicyGenerator更改，然后推送到 GitOps ZTP Argo CD 策略应用程序监控的 Git 仓库。 -
更新
ClusterGroupUpgradeCR 以包含更改的PolicyGenerator并将其保存为cgu-test.yaml。以下示例显示了一个生成的cgu-test.yaml文件。apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: custom-source-cr namespace: ztp-clusters spec: managedPolicies: - group-dev-config-policy enable: true clusters: - cluster1 remediationStrategy: maxConcurrency: 2 timeout: 240 -
通过运行以下命令应用更新的
ClusterGroupUpgradeCR$ oc apply -f cgu-test.yaml
验证
-
通过运行以下命令检查更新是否成功
$ oc get cgu -A示例输出NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
为 PolicyGenerator CR 配置策略合规性评估超时
使用安装在 hub 集群上的 Red Hat Advanced Cluster Management (RHACM) 来监控和报告您的托管集群是否符合应用的策略。RHACM 使用策略模板来应用预定义的策略控制器和策略。策略控制器是 Kubernetes 自定义资源定义 (CRD) 实例。
您可以使用 PolicyGenerator 自定义资源 (CR) 覆盖默认的策略评估间隔。您可以配置定义 ConfigurationPolicy CR 在达到策略合规或不合规状态之前 RHACM 重新评估应用的集群策略的时间长度的持续时间设置。
GitOps 零接触配置 (ZTP) 策略生成器会生成具有预定义策略评估间隔的 ConfigurationPolicy CR 策略。noncompliant 状态的默认值为 10 秒。compliant 状态的默认值为 10 分钟。要禁用评估间隔，请将值设置为 never。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录到 hub 集群。 -
您已创建一个 Git 仓库来管理您的自定义站点配置数据。
步骤
-
要配置
PolicyGeneratorCR 中所有策略的评估间隔，请为evaluationInterval字段设置适当的compliant和noncompliant值。例如policyDefaults: evaluationInterval: compliant: 30m noncompliant: 45s您还可以将
compliant和noncompliant字段设置为never，以在策略达到特定合规性状态后停止评估策略。 -
要配置
PolicyGeneratorCR 中单个策略对象的评估间隔，请添加evaluationInterval字段并设置适当的值。例如policies: - name: "sriov-sub-policy" manifests: - path: "SriovSubscription.yaml" evaluationInterval: compliant: never noncompliant: 10s -
提交 Git 仓库中的
PolicyGeneratorCR 文件并推送您的更改。
验证
检查托管 spoke 集群策略是否以预期的时间间隔进行监控。
-
以具有
cluster-admin权限的用户身份登录到托管集群。 -
获取在
open-cluster-management-agent-addon命名空间中运行的 pod。运行以下命令$ oc get pods -n open-cluster-management-agent-addon示例输出NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d -
检查
config-policy-controllerpod 的日志中应用的策略是否以预期的时间间隔进行评估$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb示例输出2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}
使用验证器信息策略发出 GitOps ZTP 集群部署完成信号
创建一个验证器信息策略，用于在已部署集群的 GitOps 零接触配置 (ZTP) 安装和配置完成后发出信号。此策略可用于单节点 OpenShift 集群、三节点集群和标准集群的部署。
步骤
-
创建一个独立的
PolicyGenerator自定义资源 (CR)，其中包含源文件validatorCRs/informDuValidator.yaml。每个集群类型只需要一个独立的PolicyGeneratorCR。例如，此 CR 为单节点 OpenShift 集群应用验证器信息策略。单节点集群验证器信息策略 CR 示例 (acm-group-du-sno-validator-ranGen.yaml)apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: group-du-sno-validator-latest placementBindingDefaults: name: group-du-sno-validator-latest-placement-binding policyDefaults: namespace: ztp-group placement: labelSelector: matchExpressions: - key: du-profile operator: In values: - latest - key: group-du-sno operator: Exists - key: ztp-done operator: DoesNotExist remediationAction: inform severity: low namespaceSelector: exclude: - kube-* include: - '*' evaluationInterval: compliant: 10m noncompliant: 10s policies: - name: group-du-sno-validator-latest-du-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "10000" evaluationInterval: compliant: 5s manifests: - path: source-crs/validatorCRs/informDuValidator-MCP-master.yaml -
将
PolicyGeneratorCR 文件提交到您的 Git 仓库并推送更改。
额外资源
使用 PolicyGenerator CR 配置电源状态
对于低延迟和高性能的边缘部署，需要禁用或限制 C 状态和 P 状态。通过此配置，CPU 以恒定频率运行，通常是最大 Turbo 频率。这确保 CPU 始终以最大速度运行，从而实现高性能和低延迟。这将为工作负载带来最佳延迟。但是，这也导致功耗最高，这对于并非所有工作负载都是必要的。
工作负载可以分为关键型和非关键型，关键型工作负载需要禁用 C 状态和 P 状态设置以实现高性能和低延迟，而非关键型工作负载使用 C 状态和 P 状态设置以节省功耗，但会牺牲一些延迟和性能。您可以使用 GitOps 零接触配置 (ZTP) 配置以下三种电源状态
-
高性能模式提供超低延迟，功耗最高。
-
性能模式提供低延迟，功耗相对较高。
-
省电模式在降低功耗和增加延迟之间取得平衡。
默认配置为低延迟、性能模式。
PolicyGenerator 自定义资源 (CR) 允许您将其他配置详细信息叠加到ztp-site-generate容器中 GitOps 插件提供的基本源 CR 上。
根据acm-group-du-sno-ranGen.yaml中的PolicyGenerator CR，通过更新生成的参考配置的PerformanceProfile CR 中的workloadHints字段来配置电源状态。
配置所有三种电源状态都适用以下常见前提条件。
先决条件
-
您已创建一个 Git 仓库，用于管理您的自定义站点配置数据。该仓库必须可从 hub 集群访问，并定义为 Argo CD 的源仓库。
-
您已按照“准备 GitOps ZTP 站点配置仓库”中描述的步骤操作。
额外资源
使用 PolicyGenerator CR 配置性能模式
按照此示例，通过更新生成的参考配置的PerformanceProfile CR 中的workloadHints字段来设置性能模式，该字段基于acm-group-du-sno-ranGen.yaml中的PolicyGenerator CR。
性能模式提供低延迟，功耗相对较高。
先决条件
-
您已按照“为低延迟和高性能配置主机固件”中的指南配置了与性能相关的 BIOS 设置。
步骤
-
更新
out/argocd/example/acmpolicygenerator/中acm-group-du-sno-ranGen.yaml参考文件中PerformanceProfile的PolicyGenerator条目，如下所示以设置性能模式。- path: source-crs/PerformanceProfile.yaml patches: - spec: workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: false -
将
PolicyGenerator更改提交到 Git，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。
使用 PolicyGenerator CR 配置高性能模式
按照此示例，通过更新生成的参考配置的PerformanceProfile CR 中的workloadHints字段来设置高性能模式，该字段基于acm-group-du-sno-ranGen.yaml中的PolicyGenerator CR。
高性能模式提供超低延迟，功耗最高。
先决条件
-
您已按照“为低延迟和高性能配置主机固件”中的指南配置了与性能相关的 BIOS 设置。
步骤
-
更新
out/argocd/example/acmpolicygenerator/中acm-group-du-sno-ranGen.yaml参考文件中PerformanceProfile的PolicyGenerator条目，如下所示以设置高性能模式。- path: source-crs/PerformanceProfile.yaml patches: - spec: workloadHints: realTime: true highPowerConsumption: true perPodPowerManagement: false -
将
PolicyGenerator更改提交到 Git，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。
使用 PolicyGenerator CR 配置省电模式
按照此示例，通过更新生成的参考配置的PerformanceProfile CR 中的workloadHints字段来设置省电模式，该字段基于acm-group-du-sno-ranGen.yaml中的PolicyGenerator CR。
省电模式在降低功耗和增加延迟之间取得平衡。
先决条件
-
您已在 BIOS 中启用 C 状态和操作系统控制的 P 状态。
步骤
-
更新
out/argocd/example/acmpolicygenerator/中acm-group-du-sno-ranGen.yaml参考文件中PerformanceProfile的PolicyGenerator条目，如下所示以配置省电模式。建议通过附加的内核参数对象为省电模式配置 CPU 调度器。- path: source-crs/PerformanceProfile.yaml patches: - spec: # ... workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true # ... additionalKernelArgs: - # ... - "cpufreq.default_governor=schedutil" (1)1 推荐使用 schedutil调度器，但是您也可以使用其他调度器，包括ondemand和powersave。 -
将
PolicyGenerator更改提交到 Git，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。
验证
-
从使用以下命令识别的节点列表中选择已部署集群中的工作节点
$ oc get nodes -
使用以下命令登录到节点
$ oc debug node/<node-name>将
<node-name>替换为您想要验证其电源状态的节点的名称。 -
将
/host设置为调试 shell 中的根目录。调试 pod 在 pod 内的/host中挂载主机的根文件系统。通过将根目录更改为/host，您可以运行包含在主机可执行路径中的二进制文件，如下例所示# chroot /host -
运行以下命令以验证应用的电源状态
# cat /proc/cmdline
预期输出
-
对于省电模式，
intel_pstate=passive。
最大限度地节省电力
建议限制最大 CPU 频率以实现最大限度的节电。在不限制最大 CPU 频率的情况下，在非关键工作负载 CPU 上启用 C 状态会通过提高关键 CPU 的频率来抵消大部分节电效果。
通过更新sysfs插件字段，在参考配置的TunedPerformancePatch CR 中设置max_perf_pct的适当值来最大限度地节省电力。此基于acm-group-du-sno-ranGen.yaml的示例描述了限制最大 CPU 频率的步骤。
先决条件
-
您已按照“使用 PolicyGenerator CR 配置省电模式”中的说明配置了省电模式。
步骤
-
更新
out/argocd/example/acmpolicygenerator/中acm-group-du-sno-ranGen.yaml参考文件中TunedPerformancePatch的PolicyGenerator条目。为了最大限度地节省电力，请添加max_perf_pct，如下例所示- path: source-crs/TunedPerformancePatch.yaml patches: - spec: profile: - name: performance-patch data: | # ... [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct=<x> (1)1 max_perf_pct控制cpufreq驱动程序允许设置的最大频率（作为最大支持 CPU 频率的百分比）。此值适用于所有 CPU。您可以在/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq中检查最大支持频率。作为起点，您可以使用一个百分比，将所有 CPU 的频率限制在“所有核心 Turbo”频率。 “所有核心 Turbo”频率是在所有核心都完全占用时所有核心运行的频率。为最大限度地节省电量，请设置较低的值。将
max_perf_pct设置为较低的值会限制最大 CPU 频率，从而降低功耗，但也可能会影响性能。尝试不同的值并监控系统的性能和功耗，以找到适合您用例的最佳设置。 -
将
PolicyGenerator更改提交到 Git，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。
使用 PolicyGenerator CR 配置 LVM 存储
您可以为使用 GitOps 零接触配置 (ZTP) 部署的托管集群配置逻辑卷管理器 (LVM) 存储。
|
当您使用 PTP 事件或带有 HTTP 传输的裸机硬件事件时，您可以使用 LVM 存储来持久化事件订阅。 对于使用分布式单元中本地卷的持久性存储，请使用本地存储运算符。 |
先决条件
-
安装 OpenShift CLI (
oc)。 -
以具有
cluster-admin权限的用户身份登录。 -
创建一个 Git 仓库，在其中管理您的自定义站点配置数据。
步骤
-
要为新的托管集群配置 LVM 存储，请将以下 YAML 添加到
acm-common-ranGen.yaml文件中的policies.manifests中- name: subscription-policies policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: - path: source-crs/StorageLVMOSubscriptionNS.yaml - path: source-crs/StorageLVMOSubscriptionOperGroup.yaml - path: source-crs/StorageLVMOSubscription.yaml spec: name: lvms-operator channel: stable-4.17存储 LVMO 订阅已弃用。在未来版本的 OpenShift Container Platform 中，存储 LVMO 订阅将不可用。您必须改用存储 LVMS 订阅。
在 OpenShift Container Platform 4.17 中，您可以使用存储 LVMS 订阅代替 LVMO 订阅。LVMS 订阅不需要在
acm-common-ranGen.yaml文件中进行手动覆盖。将以下 YAML 添加到acm-common-ranGen.yaml文件中的policies.manifests中以使用存储 LVMS 订阅- path: source-crs/StorageLVMSubscriptionNS.yaml - path: source-crs/StorageLVMSubscriptionOperGroup.yaml - path: source-crs/StorageLVMSubscription.yaml -
将
LVMClusterCR 添加到您特定组或单个站点配置文件中的policies.manifests中。例如，在acm-group-du-sno-ranGen.yaml文件中，添加以下内容- fileName: StorageLVMCluster.yaml policyName: "lvms-config" metadata: name: "lvms-storage-cluster-config" spec: storage: deviceClasses: - name: vg1 thinPoolConfig: name: thin-pool-1 sizePercent: 90 overprovisionRatio: 10此示例配置创建一个卷组 (
vg1)，其中包含所有可用设备，但安装 OpenShift Container Platform 的磁盘除外。还会创建一个 thin-pool 逻辑卷。 -
将任何其他必需的更改和文件与您的自定义站点仓库合并。
-
提交 Git 中的
PolicyGenerator更改，然后将更改推送到您的站点配置仓库，以使用 GitOps ZTP 将 LVM 存储部署到新站点。
使用 PolicyGenerator CR 配置 PTP 事件
您可以使用 GitOps ZTP 管道配置使用 HTTP 传输的 PTP 事件。
配置使用 HTTP 传输的 PTP 事件
您可以为使用 GitOps 零接触配置 (ZTP) 管道部署的托管集群配置使用 HTTP 传输的 PTP 事件。
先决条件
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录。 -
您已创建一个 Git 仓库来管理您的自定义站点配置数据。
步骤
-
根据您的需求，将以下
PolicyGenerator更改应用于acm-group-du-3node-ranGen.yaml、acm-group-du-sno-ranGen.yaml或acm-group-du-standard-ranGen.yaml文件-
在
policies.manifests中，添加配置传输主机的PtpOperatorConfigCR 文件- path: source-crs/PtpOperatorConfigForEvent.yaml patches: - metadata: name: default namespace: openshift-ptp annotations: ran.openshift.io/ztp-deploy-wave: "10" spec: daemonNodeSelector: node-role.kubernetes.io/$mcp: "" ptpEventConfig: enableEventPublisher: true transportHost: "http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"在 OpenShift Container Platform 4.13 或更高版本中，当您将 HTTP 传输与 PTP 事件一起使用时，无需在
PtpOperatorConfig资源中设置transportHost字段。 -
配置 PTP 时钟类型和接口的
linuxptp和phc2sys。例如，将以下 YAML 添加到policies.manifests中- path: source-crs/PtpConfigSlave.yaml (1) patches: - metadata: name: "du-ptp-slave" spec: recommend: - match: - nodeLabel: node-role.kubernetes.io/master priority: 4 profile: slave profile: - name: "slave" # This interface must match the hardware in this group interface: "ens5f0" (2) ptp4lOpts: "-2 -s --summary_interval -4" (3) phc2sysOpts: "-a -r -n 24" (4) 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 ptpClockThreshold: (5) holdOverTimeout: 30 # seconds maxOffsetThreshold: 100 # nano seconds minOffsetThreshold: -1001 可以是 PtpConfigMaster.yaml或PtpConfigSlave.yaml，具体取决于您的需求。对于基于acm-group-du-sno-ranGen.yaml或acm-group-du-3node-ranGen.yaml的配置，请使用PtpConfigSlave.yaml。2 设备特定的接口名称。 3 您必须将 --summary_interval -4值附加到.spec.sourceFiles.spec.profile中的ptp4lOpts以启用 PTP 快速事件。4 必需的 phc2sysOpts值。-m将消息打印到stdout。linuxptp-daemonDaemonSet解析日志并生成 Prometheus 指标。5 可选。如果不存在 ptpClockThreshold节，则使用默认值设置ptpClockThreshold字段。该节显示默认的ptpClockThreshold值。ptpClockThreshold值配置在 PTP 主时钟断开连接后触发 PTP 事件之前的时间长度。holdOverTimeout是在 PTP 主时钟断开连接后 PTP 时钟事件状态更改为FREERUN之前的时间值（以秒为单位）。maxOffsetThreshold和minOffsetThreshold设置配置以纳秒为单位的偏移值，这些值与CLOCK_REALTIME（phc2sys）或主偏移值（ptp4l）的值进行比较。当ptp4l或phc2sys偏移值超出此范围时，PTP 时钟状态设置为FREERUN。当偏移值在此范围内时，PTP 时钟状态设置为LOCKED。
-
-
将任何其他必需的更改和文件与您的自定义站点仓库合并。
-
将更改推送到您的站点配置仓库，以使用 GitOps ZTP 将 PTP 快速事件部署到新站点。
额外资源
配置镜像仓库操作符以进行镜像本地缓存
OpenShift Container Platform 使用本地仓库管理镜像缓存。在边缘计算用例中，集群在与集中式镜像仓库通信时经常受到带宽限制，这可能会导致镜像下载时间过长。
在初始部署期间，漫长的下载时间是不可避免的。随着时间的推移，在意外关机的情况下，CRI-O 可能会擦除/var/lib/containers/storage目录。为了解决漫长的镜像下载时间问题，您可以使用 GitOps 零接触配置 (ZTP) 在远程托管集群上创建本地镜像仓库。这在集群部署在网络最远端的边缘计算场景中非常有用。
在使用 GitOps ZTP 设置本地镜像仓库之前，您需要在用于安装远程托管集群的SiteConfig CR 中配置磁盘分区。安装后，您可以使用PolicyGenerator CR 配置本地镜像仓库。然后，GitOps ZTP 管道创建持久卷 (PV) 和持久卷声明 (PVC) CR 并修补imageregistry配置。
|
本地镜像仓库只能用于用户应用程序镜像，不能用于 OpenShift Container Platform 或 Operator Lifecycle Manager 运算符镜像。 |
使用 SiteConfig 配置磁盘分区
使用SiteConfig CR 和 GitOps 零接触配置 (ZTP) 为托管集群配置磁盘分区。SiteConfig CR 中的磁盘分区详细信息必须与底层磁盘匹配。
|
您必须在安装时完成此过程。 |
先决条件
-
安装 Butane。
步骤
-
创建
storage.bu文件。variant: fcos version: 1.3.0 storage: disks: - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 (1) wipe_table: false partitions: - label: var-lib-containers start_mib: <start_of_partition> (2) size_mib: <partition_size> (3) filesystems: - path: /var/lib/containers device: /dev/disk/by-partlabel/var-lib-containers format: xfs wipe_filesystem: true with_mount_unit: true mount_options: - defaults - prjquota1 指定根磁盘。 2 指定分区起始位置（以 MiB 为单位）。如果值过小，安装将失败。 3 指定分区大小。如果值过小，部署将失败。 -
运行以下命令将
storage.bu转换为Ignition文件$ butane storage.bu示例输出{"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"}]}} -
使用诸如JSON Pretty Print之类的工具将输出转换为JSON格式。
-
将输出复制到
SiteConfigCR中的.spec.clusters.nodes.ignitionConfigOverride字段。示例[...] spec: clusters: - nodes: - 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" } ] } } [...]如果
.spec.clusters.nodes.ignitionConfigOverride字段不存在，请创建它。
验证
-
在安装期间或之后，在 Hub 集群上验证
BareMetalHost对象是否显示注释，运行以下命令$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]示例输出"{\"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\"}]}}" -
安装后，检查单节点 OpenShift 磁盘状态。
-
运行以下命令，进入单节点 OpenShift 节点的调试会话。此步骤会实例化一个名为
<node_name>-debug的调试 Pod。$ oc debug node/my-sno-node -
在调试 shell 中将
/host设置为根目录，运行以下命令。调试 Pod 将宿主机根文件系统挂载到 Pod 内的/host。通过将根目录更改为/host，您可以运行包含在主机可执行路径中的二进制文件。# chroot /host -
运行以下命令列出所有可用块设备的信息。
# lsblk示例输出NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 446.6G 0 disk ├─sda1 8:1 0 1M 0 part ├─sda2 8:2 0 127M 0 part ├─sda3 8:3 0 384M 0 part /boot ├─sda4 8:4 0 243.6G 0 part /var │ /sysroot/ostree/deploy/rhcos/var │ /usr │ /etc │ / │ /sysroot └─sda5 8:5 0 202.5G 0 part /var/lib/containers -
运行以下命令显示文件系统磁盘空间使用情况的信息。
# df -h示例输出Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 126G 84K 126G 1% /dev/shm tmpfs 51G 93M 51G 1% /run /dev/sda4 244G 5.2G 239G 3% /sysroot tmpfs 126G 4.0K 126G 1% /tmp /dev/sda5 203G 119G 85G 59% /var/lib/containers /dev/sda3 350M 110M 218M 34% /boot tmpfs 26G 0 26G 0% /run/user/1000
-
使用 PolicyGenerator CR 配置镜像仓库
使用PolicyGenerator (PGT) CR 应用配置镜像仓库和修补imageregistry配置所需的 CR。
先决条件
-
您已在托管集群中配置了一个磁盘分区。
-
您已安装 OpenShift CLI (
oc)。 -
您已以具有
cluster-admin权限的用户身份登录到 hub 集群。 -
您已创建一个 Git 仓库，用于管理您用于 GitOps 零接触配置 (ZTP) 的自定义站点配置数据。
步骤
-
在相应的
PolicyGeneratorCR 中配置存储类、持久卷声明、持久卷和镜像仓库配置。例如，要配置单个站点，请将以下 YAML 添加到文件acm-example-sno-site.yaml中。sourceFiles: # storage class - fileName: StorageClass.yaml policyName: "sc-for-image-registry" metadata: name: image-registry-sc annotations: ran.openshift.io/ztp-deploy-wave: "100" (1) # persistent volume claim - fileName: StoragePVC.yaml policyName: "pvc-for-image-registry" metadata: name: image-registry-pvc namespace: openshift-image-registry annotations: ran.openshift.io/ztp-deploy-wave: "100" spec: accessModes: - ReadWriteMany resources: requests: storage: 100Gi storageClassName: image-registry-sc volumeMode: Filesystem # persistent volume - fileName: ImageRegistryPV.yaml (2) policyName: "pv-for-image-registry" metadata: annotations: ran.openshift.io/ztp-deploy-wave: "100" - fileName: ImageRegistryConfig.yaml policyName: "config-for-image-registry" complianceType: musthave metadata: annotations: ran.openshift.io/ztp-deploy-wave: "100" spec: storage: pvc: claim: "image-registry-pvc"1 根据您是在站点、公共还是组级别配置镜像仓库，设置 ztp-deploy-wave的适当值。ztp-deploy-wave: "100"适用于开发或测试，因为它允许您将引用的源文件组合在一起。2 在 ImageRegistryPV.yaml中，确保spec.local.path字段设置为/var/imageregistry，以匹配SiteConfigCR中mount_point字段设置的值。不要为
- fileName: ImageRegistryConfig.yaml配置设置complianceType: mustonlyhave。这可能会导致注册表 Pod 部署失败。 -
在 Git 中提交
PolicyGenerator更改，然后推送到 GitOps ZTP ArgoCD 应用程序正在监视的 Git 仓库。
验证
使用以下步骤对托管集群上的本地镜像仓库错误进行故障排除。
-
登录到托管集群后，验证是否成功登录到注册表。运行以下命令。
-
导出托管集群名称。
$ cluster=<managed_cluster_name> -
获取托管集群
kubeconfig详细信息。$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster -
下载并导出集群
kubeconfig。$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster -
验证从托管集群访问镜像仓库。请参见“访问注册表”。
-
-
检查
imageregistry.operator.openshift.io组实例中的ConfigCRD 是否未报告错误。登录到托管集群后运行以下命令。$ oc get image.config.openshift.io cluster -o yaml示例输出apiVersion: config.openshift.io/v1 kind: Image metadata: annotations: include.release.openshift.io/ibm-cloud-managed: "true" include.release.openshift.io/self-managed-high-availability: "true" include.release.openshift.io/single-node-developer: "true" release.openshift.io/create-only: "true" creationTimestamp: "2021-10-08T19:02:39Z" generation: 5 name: cluster resourceVersion: "688678648" uid: 0406521b-39c0-4cda-ba75-873697da75a4 spec: additionalTrustedCA: name: acm-ice -
检查托管集群上的
PersistentVolumeClaim是否已填充数据。登录到托管集群后运行以下命令。$ oc get pv image-registry-sc -
检查
registry*Pod 是否正在运行，并且位于openshift-image-registry命名空间下。$ oc get pods -n openshift-image-registry | grep registry*示例输出cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d -
检查托管集群上的磁盘分区是否正确。
-
打开托管集群的调试 shell。
$ oc debug node/sno-1.example.com -
运行
lsblk以检查主机磁盘分区。sh-4.4# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 446.6G 0 disk |-sda1 8:1 0 1M 0 part |-sda2 8:2 0 127M 0 part |-sda3 8:3 0 384M 0 part /boot |-sda4 8:4 0 336.3G 0 part /sysroot `-sda5 8:5 0 100.1G 0 part /var/imageregistry (1) sdb 8:16 0 446.6G 0 disk sr0 11:0 1 104M 0 rom1 /var/imageregistry表示磁盘已正确分区。
-
额外资源