OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

使用 PolicyGenTemplate 资源进行高级托管集群配置

将其他更改部署到集群

如果您需要在基础 GitOps 零接触配置 (ZTP) 管道配置之外进行集群配置更改，则有三个选项

在 GitOps ZTP 管道完成后应用其他配置

GitOps ZTP 管道部署完成后，已部署的集群已准备好用于应用程序工作负载。此时，您可以安装其他运算符并应用特定于您需求的配置。确保其他配置不会对平台的性能或分配的 CPU 预算产生负面影响。

向 GitOps ZTP 库添加内容

您可以根据需要使用 GitOps ZTP 管道部署的基础源自定义资源 (CR) 进行扩充自定义内容。

为集群安装创建额外的清单

额外的清单在安装期间应用，并使安装过程更高效。

提供其他源 CR 或修改现有源 CR 会严重影响 OpenShift Container Platform 的性能或 CPU 配置文件。

使用 PolicyGenTemplate CR 覆盖源 CR 内容

PolicyGenTemplate 自定义资源 (CR) 允许您在ztp-site-generate容器中提供的 GitOps 插件提供的基础源 CR 之上叠加其他配置详细信息。您可以将PolicyGenTemplate CR 视为对基础 CR 的逻辑合并或修补。使用PolicyGenTemplate CR 更新基础 CR 的单个字段，或覆盖基础 CR 的全部内容。您可以更新值并插入基础 CR 中不存在的字段。

以下示例过程描述了如何根据group-du-sno-ranGen.yaml文件中的PolicyGenTemplate CR 更新生成的PerformanceProfile CR 中的字段。请使用此过程作为修改其他PolicyGenTemplate 部分的基础，具体取决于您的需求。

先决条件

  • 创建一个 Git 存储库，在其中管理您的自定义站点配置数据。该存储库必须可从中心集群访问，并定义为 Argo CD 的源存储库。

步骤

  1. 查看基线源 CR 以查找现有内容。您可以通过从 GitOps 零接触配置 (ZTP) 容器中提取它们来查看参考PolicyGenTemplate CR 中列出的源 CR。

    1. 创建一个/out文件夹

      $ mkdir -p ./out

    2. 提取源 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

  2. 查看./out/source-crs/PerformanceProfile.yaml中的基线PerformanceProfile CR

    apiVersion: 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 中包含$…​的任何字段未在PolicyGenTemplate CR 中提供，则这些字段将从生成的 CR 中删除。

  3. 更新group-du-sno-ranGen.yaml参考文件中的PolicyGenTemplate条目中的PerformanceProfile。以下示例PolicyGenTemplate CR 片段提供了合适的 CPU 规格，设置了hugepages配置，并添加了一个新字段，将globallyDisableIrqLoadBalancing设置为false。

    - fileName: PerformanceProfile.yaml
  policyName: "config-policy"
  metadata:
    name: openshift-node-performance-profile
  spec:
    cpu:
      # These must be tailored for the specific hardware platform
      isolated: "2-19,22-39"
      reserved: "0-1,20-21"
    hugepages:
      defaultHugepagesSize: 1G
      pages:
        - size: 1G
          count: 10
    globallyDisableIrqLoadBalancing: false

  4. 在 Git 中提交PolicyGenTemplate更改，然后推送到 GitOps ZTP Argo CD 应用程序监视的 Git 仓库。

    示例输出

    GitOps ZTP 应用程序生成一个包含生成的PerformanceProfile CR 的 RHACM 策略。该 CR 的内容是通过将PolicyGenTemplate中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

在从ztp-site-generate容器中提取的/source-crs文件夹中，不会像语法暗示的那样使用$语法进行模板替换。相反，如果policyGen工具看到字符串的$前缀，并且您没有在相关的PolicyGenTemplate CR 中为该字段指定值，则该字段将完全从输出 CR 中省略。

一个例外是/source-crs YAML 文件中的$mcp变量，它将被PolicyGenTemplate CR 中指定的mcp值替换。例如，在example/policygentemplates/group-du-standard-ranGen.yaml中，mcp的值为worker

spec:
  bindingRules:
    group-du-standard: ""
  mcp: "worker"

policyGen工具将输出 CR 中的$mcp实例替换为worker。

向 GitOps ZTP 管道添加自定义内容

执行以下步骤以向 GitOps ZTP 管道添加新内容。

步骤

  1. 在包含PolicyGenTemplate自定义资源 (CR) 的kustomization.yaml文件的目录中创建一个名为source-crs的子目录。

  2. 将您提供的用户 CR 添加到source-crs子目录，如下例所示

    example
└── policygentemplates
    ├── 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.yaml
    1 source-crs子目录必须与kustomization.yaml文件位于同一目录中。

  3. 更新所需的PolicyGenTemplate CR 以包含对您在source-crs/custom-crs和source-crs/elasticsearch目录中添加的内容的引用。例如

    apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-dev"
  namespace: "ztp-clusters"
spec:
  bindingRules:
    dev: "true"
  mcp: "master"
  sourceFiles:
    # These policies/CRs come from the internal container Image
    #Cluster Logging
    - fileName: ClusterLogNS.yaml
      remediationAction: inform
      policyName: "group-dev-cluster-log-ns"
    - fileName: ClusterLogOperGroup.yaml
      remediationAction: inform
      policyName: "group-dev-cluster-log-operator-group"
    - fileName: ClusterLogSubscription.yaml
      remediationAction: inform
      policyName: "group-dev-cluster-log-sub"
    #Local Storage Operator
    - fileName: StorageNS.yaml
      remediationAction: inform
      policyName: "group-dev-lso-ns"
    - fileName: StorageOperGroup.yaml
      remediationAction: inform
      policyName: "group-dev-lso-operator-group"
    - fileName: StorageSubscription.yaml
      remediationAction: inform
      policyName: "group-dev-lso-sub"
    #These are custom local policies that come from the source-crs directory in the git repo
    # Performance Addon Operator
    - fileName: PaoSubscriptionNS.yaml
      remediationAction: inform
      policyName: "group-dev-pao-ns"
    - fileName: PaoSubscriptionCatalogSource.yaml
      remediationAction: inform
      policyName: "group-dev-pao-cat-source"
      spec:
        image: <container_image_url>
    - fileName: PaoSubscription.yaml
      remediationAction: inform
      policyName: "group-dev-pao-sub"
    #Elasticsearch Operator
    - fileName: elasticsearch/ElasticsearchNS.yaml (1)
      remediationAction: inform
      policyName: "group-dev-elasticsearch-ns"
    - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
      remediationAction: inform
      policyName: "group-dev-elasticsearch-operator-group"
    #Custom Resources
    - fileName: custom-crs/apiserver-config.yaml (1)
      remediationAction: inform
      policyName: "group-dev-apiserver-config"
    - fileName: custom-crs/disable-nic-lldp.yaml
      remediationAction: inform
      policyName: "group-dev-disable-nic-lldp"
    1 设置fileName以包含从/source-crs父目录到文件的相对路径。

  4. 在 Git 中提交PolicyGenTemplate更改，然后推送到 GitOps ZTP Argo CD 策略应用程序监视的 Git 仓库。

  5. 更新ClusterGroupUpgrade CR 以包含更改的PolicyGenTemplate并将其保存为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

  6. 通过运行以下命令应用更新的ClusterGroupUpgrade CR

    $ 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

为 PolicyGenTemplate CR 配置策略合规性评估超时

使用安装在 hub 集群上的 Red Hat Advanced Cluster Management (RHACM) 来监控和报告您的托管集群是否符合应用的策略。RHACM 使用策略模板来应用预定义的策略控制器和策略。策略控制器是 Kubernetes 自定义资源定义 (CRD) 实例。

您可以使用PolicyGenTemplate自定义资源 (CR) 覆盖默认的策略评估间隔。您可以配置定义ConfigurationPolicy CR 在策略符合性或不符合性状态下持续多长时间，然后 RHACM 重新评估应用的集群策略的持续时间设置。

GitOps 零接触配置 (ZTP) 策略生成器生成具有预定义策略评估间隔的ConfigurationPolicy CR 策略。noncompliant状态的默认值为 10 秒。compliant状态的默认值为 10 分钟。要禁用评估间隔，请将值设置为never。

先决条件

  • 您已安装 OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到 hub 集群。

  • 您已创建了一个 Git 仓库，用于管理您的自定义站点配置数据。

步骤

  1. 要配置PolicyGenTemplate CR 中所有策略的评估间隔，请为evaluationInterval字段设置适当的compliant和noncompliant值。例如

    spec:
  evaluationInterval:
    compliant: 30m
    noncompliant: 20s

    您还可以将compliant和noncompliant字段设置为never，以停止在策略达到特定合规性状态后对其进行评估。

  2. 要配置PolicyGenTemplate CR 中单个策略对象的评估间隔，请添加evaluationInterval字段并设置适当的值。例如

    spec:
  sourceFiles:
    - fileName: SriovSubscription.yaml
      policyName: "sriov-sub-policy"
      evaluationInterval:
        compliant: never
        noncompliant: 10s

  3. 提交 Git 仓库中的PolicyGenTemplate CR 文件并推送您的更改。

验证

检查托管 spoke 集群策略是否以预期的时间间隔进行监控。

  1. 以具有cluster-admin权限的用户身份登录到托管集群。

  2. 获取在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

  3. 检查应用的策略是否在config-policy-controller pod 的日志中以预期的间隔进行评估

    $ 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 集群、三节点集群和标准集群的部署。

步骤

  1. 创建一个独立的PolicyGenTemplate自定义资源 (CR)，其中包含源文件validatorCRs/informDuValidator.yaml。每种集群类型只需要一个独立的PolicyGenTemplate CR。例如，此 CR 为单节点 OpenShift 集群应用验证器信息策略

    示例单节点集群验证器信息策略 CR (group-du-sno-validator-ranGen.yaml)
    apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno-validator" (1)
  namespace: "ztp-group" (2)
spec:
  bindingRules:
    group-du-sno: "" (3)
  bindingExcludedRules:
    ztp-done: "" (4)
  mcp: "master" (5)
  sourceFiles:
    - fileName: validatorCRs/informDuValidator.yaml
      remediationAction: inform (6)
      policyName: "du-policy" (7)
    1 {policy-gen-crs}对象的名称。此名称也用作在请求的namespace中创建的placementBinding、placementRule和policy名称的一部分。
    2 此值应与组policy-gen-crs中使用的namespace匹配。
    3 bindingRules中定义的group-du-*标签必须存在于SiteConfig文件中。
    4 bindingExcludedRules中定义的标签必须为`ztp-done:`。ztp-done标签与拓扑感知生命周期管理器协调使用。
    5 mcp定义了源文件validatorCRs/informDuValidator.yaml中使用的MachineConfigPool对象。对于单节点和三节点集群部署，它应该是master；对于标准集群部署，它应该是worker。
    6 可选。默认值为inform。
    7 此值用作生成的 RHACM 策略名称的一部分。单节点示例的生成的验证器策略为group-du-sno-validator-du-policy。

  2. 提交 Git 仓库中的PolicyGenTemplate CR 文件并推送更改。

其他资源

使用 PolicyGenTemplate CR 配置电源状态

对于低延迟和高性能边缘部署，需要禁用或限制 C 状态和 P 状态。通过此配置，CPU 以恒定频率运行，通常是最大 turbo 频率。这确保 CPU 始终以最大速度运行，从而实现高性能和低延迟。这将带来最佳的工作负载延迟。但是，这也导致功耗最高，这对于所有工作负载而言可能并非必要。

工作负载可分为关键型和非关键型两种。关键型工作负载需要禁用 C 状态和 P 状态设置以实现高性能和低延迟，而非关键型工作负载则使用 C 状态和 P 状态设置以节省功耗，但会牺牲一定的延迟和性能。您可以使用 GitOps 零接触配置 (ZTP) 配置以下三种电源状态。

  • 高性能模式提供超低延迟，但功耗最高。

  • 性能模式提供低延迟，功耗相对较高。

  • 省电模式在降低功耗的同时会增加延迟。

默认配置为低延迟的性能模式。

PolicyGenTemplate 自定义资源 (CR) 允许您将其他配置详细信息叠加到 GitOps 插件的 ztp-site-generate 容器中提供的基本源 CR 上。

根据 group-du-sno-ranGen.yaml 中的 PolicyGenTemplate CR，通过更新生成的参考配置的 PerformanceProfile CR 中的 workloadHints 字段来配置电源状态。

配置所有三种电源状态都需要满足以下常见前提条件。

先决条件

  • 您已创建一个 Git 仓库来管理您的自定义站点配置数据。该仓库必须可以从 hub 集群访问，并被定义为 Argo CD 的源仓库。

  • 您已按照“准备 GitOps ZTP 站点配置仓库”中描述的步骤进行操作。

其他资源

使用 PolicyGenTemplate CR 配置性能模式

按照此示例，通过更新生成的参考配置的 PerformanceProfile CR 中的 workloadHints 字段（基于 group-du-sno-ranGen.yaml 中的 PolicyGenTemplate CR）来设置性能模式。

性能模式提供低延迟，功耗相对较高。

先决条件

  • 您已按照“为低延迟和高性能配置主机固件”中的指导配置了与性能相关的 BIOS 设置。

步骤

  1. 按如下所示更新 out/argocd/example/policygentemplates// 中 group-du-sno-ranGen.yaml 参考文件中 PerformanceProfile 的 PolicyGenTemplate 条目以设置性能模式。

    - fileName: PerformanceProfile.yaml
  policyName: "config-policy"
  metadata:
  # ...
  spec:
    # ...
    workloadHints:
         realTime: true
         highPowerConsumption: false
         perPodPowerManagement: false

  2. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。

使用 PolicyGenTemplate CR 配置高性能模式

按照此示例，通过更新生成的参考配置的 PerformanceProfile CR 中的 workloadHints 字段（基于 group-du-sno-ranGen.yaml 中的 PolicyGenTemplate CR）来设置高性能模式。

高性能模式提供超低延迟，但功耗最高。

先决条件

  • 您已按照“为低延迟和高性能配置主机固件”中的指导配置了与性能相关的 BIOS 设置。

步骤

  1. 按如下所示更新 out/argocd/example/policygentemplates/ 中 group-du-sno-ranGen.yaml 参考文件中 PerformanceProfile 的 PolicyGenTemplate 条目以设置高性能模式。

    - fileName: PerformanceProfile.yaml
  policyName: "config-policy"
  metadata:
  #  ...
  spec:
  #  ...
    workloadHints:
         realTime: true
         highPowerConsumption: true
         perPodPowerManagement: false

  2. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。

使用 PolicyGenTemplate CR 配置省电模式

按照此示例，通过更新生成的参考配置的 PerformanceProfile CR 中的 workloadHints 字段（基于 group-du-sno-ranGen.yaml 中的 PolicyGenTemplate CR）来设置省电模式。

省电模式在降低功耗的同时会增加延迟。

先决条件

  • 您已在 BIOS 中启用 C 状态和操作系统控制的 P 状态。

步骤

  1. 按如下所示更新 out/argocd/example/policygentemplates/ 中 group-du-sno-ranGen.yaml 参考文件中 PerformanceProfile 的 PolicyGenTemplate 条目以配置省电模式。建议通过附加的内核参数对象配置省电模式的 CPU 调度器。

    - fileName: PerformanceProfile.yaml
  policyName: "config-policy"
  metadata:
  # ...
  spec:
    # ...
    workloadHints:
      realTime: true
      highPowerConsumption: false
      perPodPowerManagement: true
    # ...
    additionalKernelArgs:
      - # ...
      - "cpufreq.default_governor=schedutil" (1)
    1 推荐使用 schedutil 调度器，但也可以使用其他调度器，例如 ondemand 和 powersave。

  2. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。

验证

  1. 使用以下命令标识的节点列表中选择已部署集群中的一个工作节点

    $ oc get nodes

  2. 使用以下命令登录到节点

    $ oc debug node/<node-name>

    将 <node-name> 替换为您想要验证其电源状态的节点的名称。

  3. 在调试 shell 中将 /host 设置为根目录。调试 pod 将主机的根文件系统挂载到 pod 内的 /host 中。通过将根目录更改为 /host，您可以运行主机可执行路径中包含的二进制文件，如下例所示

    # chroot /host

  4. 运行以下命令以验证应用的电源状态

    # cat /proc/cmdline
预期输出

  • 对于省电模式，intel_pstate=passive。

其他资源

最大限度地节省电力

建议限制最大 CPU 频率以最大限度地节省电力。在非关键型工作负载 CPU 上启用 C 状态而不限制最大 CPU 频率会通过提高关键型 CPU 的频率而抵消大部分节电效果。

通过更新 sysfs 插件字段，在参考配置的 TunedPerformancePatch CR 中设置 max_perf_pct 的适当值来最大限度地节省电力。此基于 group-du-sno-ranGen.yaml 的示例描述了限制最大 CPU 频率的步骤。

先决条件

  • 您已按照“使用 PolicyGenTemplate CR 配置省电模式”中的说明配置了省电模式。

步骤

  1. 更新 out/argocd/example/policygentemplates/ 中 group-du-sno-ranGen.yaml 参考文件中 TunedPerformancePatch 的 PolicyGenTemplate 条目。为了最大限度地节省电力，请添加 max_perf_pct，如下例所示

    - fileName: TunedPerformancePatch.yaml
  policyName: "config-policy"
  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 频率，从而降低功耗，但也可能会影响性能。尝试不同的值并监控系统的性能和功耗，以找到适合您用例的最佳设置。

  2. 提交 Git 中的 PolicyGenTemplate 更改，然后推送到 GitOps ZTP Argo CD 应用程序正在监视的 Git 仓库。

使用 PolicyGenTemplate CR 配置 LVM 存储

您可以为使用 GitOps 零接触配置 (ZTP) 部署的托管集群配置逻辑卷管理器 (LVM) 存储。

当您使用 PTP 事件或带有 HTTP 传输的裸机硬件事件时，您可以使用 LVM 存储来持久保存事件订阅。

对使用分布式单元中的本地卷的持久性存储使用本地存储运算符。
先决条件

  • 安装 OpenShift CLI (oc)。

  • 以具有 cluster-admin 权限的用户身份登录。

  • 创建一个 Git 仓库来管理您的自定义站点配置数据。

步骤

  1. 要为新的托管集群配置 LVM 存储，请将以下 YAML 添加到 common-ranGen.yaml 文件中的 spec.sourceFiles 中

    - fileName: StorageLVMOSubscriptionNS.yaml
  policyName: subscription-policies
- fileName: StorageLVMOSubscriptionOperGroup.yaml
  policyName: subscription-policies
- fileName: StorageLVMOSubscription.yaml
  spec:
    name: lvms-operator
    channel: stable-4.17
  policyName: subscription-policies

    存储 LVMO 订阅已弃用。在 OpenShift Container Platform 的未来版本中，存储 LVMO 订阅将不可用。相反，您必须使用存储 LVMS 订阅。

    在 OpenShift Container Platform 4.17 中，您可以使用存储 LVMS 订阅代替 LVMO 订阅。LVMS 订阅不需要在 common-ranGen.yaml 文件中进行手动覆盖。将以下 YAML 添加到 common-ranGen.yaml 文件中的 spec.sourceFiles 中以使用存储 LVMS 订阅

    - fileName: StorageLVMSubscriptionNS.yaml
  policyName: subscription-policies
- fileName: StorageLVMSubscriptionOperGroup.yaml
  policyName: subscription-policies
- fileName: StorageLVMSubscription.yaml
  policyName: subscription-policies

  2. 在您的特定组或单个站点配置文件中，将LVMCluster CR 添加到spec.sourceFiles中。例如，在group-du-sno-ranGen.yaml文件中，添加以下内容

    - fileName: StorageLVMCluster.yaml
  policyName: "lvms-config"
  spec:
    storage:
      deviceClasses:
      - name: vg1
        thinPoolConfig:
          name: thin-pool-1
          sizePercent: 90
          overprovisionRatio: 10

    此示例配置创建一个卷组 (vg1)，其中包含所有可用设备，但不包括安装 OpenShift Container Platform 的磁盘。还会创建一个 thin-pool 逻辑卷。

  3. 将任何其他必需的更改和文件与您的自定义站点存储库合并。

  4. 提交 Git 中的PolicyGenTemplate更改，然后将更改推送到您的站点配置存储库，以便使用 GitOps ZTP 将 LVM 存储部署到新站点。

使用 PolicyGenTemplate CR 配置 PTP 事件

您可以使用 GitOps ZTP 管道配置使用 HTTP 传输的 PTP 事件。

配置使用 HTTP 传输的 PTP 事件

您可以为使用 GitOps 零接触配置 (ZTP) 管道部署的托管集群配置使用 HTTP 传输的 PTP 事件。

先决条件

  • 您已安装 OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录。

  • 您已创建了一个 Git 仓库，用于管理您的自定义站点配置数据。

步骤

  1. 根据您的需求，将以下PolicyGenTemplate更改应用于group-du-3node-ranGen.yaml、group-du-sno-ranGen.yaml或group-du-standard-ranGen.yaml文件

    1. 在spec.sourceFiles中，添加配置传输主机的PtpOperatorConfig CR 文件

      - fileName: PtpOperatorConfigForEvent.yaml
  policyName: "config-policy"
  spec:
    daemonNodeSelector: {}
    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字段。

    2. 为 PTP 时钟类型和接口配置linuxptp和phc2sys。例如，将以下 YAML 添加到spec.sourceFiles

      - fileName: PtpConfigSlave.yaml (1)
  policyName: "config-policy"
  metadata:
    name: "du-ptp-slave"
  spec:
    profile:
    - name: "slave"
      interface: "ens5f1" (2)
      ptp4lOpts: "-2 -s --summary_interval -4" (3)
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" (4)
    ptpClockThreshold: (5)
      holdOverTimeout: 30 # seconds
      maxOffsetThreshold: 100  # nano seconds
      minOffsetThreshold: -100
      1 可以是PtpConfigMaster.yaml或PtpConfigSlave.yaml，具体取决于您的需求。对于基于group-du-sno-ranGen.yaml或group-du-3node-ranGen.yaml的配置，请使用PtpConfigSlave.yaml。
      2 设备特定的接口名称。
      3 您必须将--summary_interval -4值附加到.spec.sourceFiles.spec.profile中的ptp4lOpts以启用 PTP 快速事件。
      4 必需的phc2sysOpts值。-m将消息打印到stdout。linuxptp-daemon DaemonSet解析日志并生成 Prometheus 指标。
      5 可选。如果不存在ptpClockThreshold部分，则使用默认值作为ptpClockThreshold字段的值。此部分显示默认的ptpClockThreshold值。ptpClockThreshold值配置在 PTP 主时钟断开连接后触发 PTP 事件之前的持续时间。holdOverTimeout是在 PTP 主时钟断开连接后 PTP 时钟事件状态更改为FREERUN之前的秒数。maxOffsetThreshold和minOffsetThreshold设置配置以纳秒为单位的偏移值，这些值将与CLOCK_REALTIME (phc2sys) 或主偏移量 (ptp4l) 的值进行比较。当ptp4l或phc2sys偏移值超出此范围时，PTP 时钟状态将设置为FREERUN。当偏移值在此范围内时，PTP 时钟状态将设置为LOCKED。

  2. 将任何其他必需的更改和文件与您的自定义站点存储库合并。

  3. 将更改推送到您的站点配置存储库，以便使用 GitOps ZTP 将 PTP 快速事件部署到新站点。

其他资源
其他资源

配置镜像注册表操作符以进行镜像本地缓存

OpenShift Container Platform 使用本地注册表管理镜像缓存。在边缘计算用例中，集群在与集中式镜像注册表通信时经常受到带宽限制，这可能会导致镜像下载时间过长。

在初始部署期间，漫长的下载时间是不可避免的。随着时间的推移，如果意外关机，CRI-O 可能会擦除/var/lib/containers/storage目录。为了解决镜像下载时间过长的问题，您可以使用 GitOps 零接触配置 (ZTP) 在远程托管集群上创建本地镜像注册表。这在集群部署在网络最边缘的边缘计算场景中非常有用。

在使用 GitOps ZTP 设置本地镜像注册表之前，您需要在用于安装远程托管集群的SiteConfig CR 中配置磁盘分区。安装后，您可以使用PolicyGenTemplate CR 配置本地镜像注册表。然后，GitOps ZTP 管道创建持久卷 (PV) 和持久卷声明 (PVC) CR，并修补imageregistry配置。

本地镜像注册表只能用于用户应用程序镜像，不能用于 OpenShift Container Platform 或 Operator Lifecycle Manager 运营商镜像。
其他资源

使用 SiteConfig 配置磁盘分区

使用SiteConfig CR 和 GitOps 零接触配置 (ZTP) 为托管集群配置磁盘分区。SiteConfig CR 中的磁盘分区详细信息必须与底层磁盘匹配。

您必须在安装时完成此过程。
先决条件

  • 安装 Butane。

步骤

  1. 创建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
        - prjquota
    1 指定根磁盘。
    2 以 MiB 为单位指定分区的起始位置。如果值太小，则安装会失败。
    3 指定分区的 size。如果值太小，则部署会失败。

  2. 通过运行以下命令将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"}]}}

  3. 使用诸如JSON Pretty Print之类的工具将输出转换为 JSON 格式。

  4. 将输出复制到SiteConfig CR 中的.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字段不存在，请创建它。
验证

  1. 在安装期间或之后，在 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\"}]}}"

  2. 安装后，检查单节点 OpenShift 磁盘状态。

    1. 通过运行以下命令进入单节点 OpenShift 节点的调试会话。此步骤会实例化一个名为<node_name>-debug的调试 pod

      $ oc debug node/my-sno-node

    2. 将/host设置为调试 shell 中的根目录，方法是运行以下命令。调试 pod 将主机的根文件系统安装在 pod 内的/host中。通过将根目录更改为/host，您可以运行主机可执行路径中包含的二进制文件

      # chroot /host

    3. 通过运行以下命令列出所有可用块设备的信息

      # 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

    4. 通过运行以下命令显示有关文件系统磁盘空间使用情况的信息

      # 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

使用 PolicyGenTemplate CR 配置镜像注册表

使用PolicyGenTemplate (PGT) CR 应用配置镜像注册表和修补imageregistry配置所需的 CR。

先决条件

  • 您已在托管集群中配置了磁盘分区。

  • 您已安装 OpenShift CLI (oc)。

  • 您已以具有cluster-admin权限的用户身份登录到 hub 集群。

  • 您已创建了一个 Git 存储库，您可以在其中管理自定义站点配置数据以与 GitOps 零接触配置 (ZTP) 一起使用。

步骤

  1. 在相应的PolicyGenTemplate CR 中配置存储类、持久卷声明、持久卷和镜像注册表配置。例如，要配置单个站点，请将以下 YAML 添加到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`，以匹配`SiteConfig` CR中`mount_point`字段的值。

    不要为`- fileName: ImageRegistryConfig.yaml`配置设置`complianceType: mustonlyhave`。这可能会导致注册表 Pod 部署失败。

  2. 提交 Git 中的`PolicyGenTemplate`更改，然后推送到 GitOps ZTP ArgoCD 应用程序监控的 Git 仓库。

验证

请按照以下步骤排查托管集群上本地镜像注册表的错误

  • 验证登录到托管集群后是否成功登录到注册表。运行以下命令

    1. 导出托管集群名称

      $ cluster=<managed_cluster_name>

    2. 获取托管集群的`kubeconfig`详细信息

      $ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster

    3. 下载并导出集群`kubeconfig`

      $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster

    4. 验证从托管集群访问镜像注册表。请参见“访问注册表”。

  • 检查`imageregistry.operator.openshift.io`组实例中的`Config` CRD 是否没有报告错误。登录到托管集群后运行以下命令

    $ 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

  • 检查托管集群上的磁盘分区是否正确

    1. 打开到托管集群的调试 shell

      $ oc debug node/sno-1.example.com

    2. 运行`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 rom
      1 `/var/imageregistry`表示磁盘已正确分区。
其他资源