9.2. 带有 PolicyGenerator 资源的高级受管集群配置


您可以使用 PolicyGenerator CR 在受管集群中部署自定义功能。

重要

在 GitOps ZTP 中使用 PolicyGenerator 资源只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

注意

有关 PolicyGenerator 资源的更多信息,请参阅 RHACM 策略生成器 文档。

9.2.1. 为集群部署额外的更改

如果您需要在基本 GitOps Zero Touch Provisioning (ZTP) 管道配置之外更改集群配置,则有三个选项:

在 GitOps ZTP 管道完成后应用额外的配置
当 GitOps ZTP 管道部署完成后,部署的集群就可以用于应用程序工作负载。此时,您可以安装其他 Operator 并应用具体具体要求的配置。确保额外的配置不会影响平台或分配的 CPU 预算的性能。
在 GitOps ZTP 库中添加内容
使用 GitOps ZTP 管道部署的基本源自定义资源 (CR) 可以根据需要使用自定义内容增强。
为集群安装创建额外的清单
在安装过程中应用额外的清单,并使安装过程更高效。
重要

提供额外的源 CR 或修改现有源 CR 可能会影响 OpenShift Container Platform 的性能或 CPU 配置集。

9.2.2. 使用 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 中的字段。根据您的要求,使用流程作为一个基础来修改 PolicyGenTemplate 的其他部分。

先决条件

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

流程

  1. 查看基准源 CR 以查找现有内容。您可以通过从 GitOps Zero Touch Provisioning (ZTP) 容器中提取引用 PolicyGenerator 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
    注意

    如果没有在 PolicyGenerator CR 中提供,则任何在源 CR 中包含 $…​ 的字段都会从生成的 CR 中删除。

  3. acm-group-du-sno-ranGen.yaml 参考文件中为 PerformanceProfile 更新 PolicyGenerator 条目。以下示例 PolicyGenerator CR 小节提供了适当的 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
  4. 提交 Git 中的 PolicyGenerator 更改,然后推送到由 GitOps ZTP argo CD 应用程序监控的 Git 存储库。

    输出示例

    GitOps ZTP 应用程序生成包含生成的 PerformanceProfile CR 的 RHACM 策略。该 CR 的内容通过将 PolicyGenerator 中的 PerformanceProfile 条目的 metadataspec 内容合并到源 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 工具看到字符串的 $ 前缀,并且您没有在相关 PolicyGenerator CR 中为该字段指定值,则会完全从输出 CR 省略该字段。

一个例外是 /source-crs YAML 文件中的 $mcp 变量,该文件被替换为来自 PolicyGenerator CR 的 mcp 的指定的值。例如,在 example/policygentemplates/acm-group-du-standard-ranGen.yaml 中,mcp 的值为 worker

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

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

9.2.3. 在 GitOps ZTP 管道中添加自定义内容

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

流程

  1. 在目录中创建一个名为 source-crs 的子目录,其中包含 PolicyGenerator 自定义资源 (CR) 的 kustomization.yaml 文件。
  2. 将用户提供的 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.yaml
    1
    source-crs 子目录必须与 kustomization.yaml 文件位于同一个目录中。
  3. 更新所需的 PolicyGenerator CR,使其包含对 source-crs/custom-crssource-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 2
        - name: group-dev-group-dev-disable-nic-lldp
          policyAnnotations:
            ran.openshift.io/ztp-deploy-wave: "2"
          manifests:
            - path: custom-crs/disable-nic-lldp.yaml
    1 2
    设置 policies.manifests.path,使其包含 /source-crs 父目录中文件的相对路径。
  4. 提交 Git 中的 PolicyGenerator 更改,然后推送到由 GitOps ZTP Argo CD 策略应用程序监控的 Git 存储库。
  5. 更新 ClusterGroupUpgrade CR,使其包含更改后的 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
  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

9.2.4. 为 PolicyGenerator CR 配置策略合规性评估超时

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

您可以使用 PolicyGenerator 自定义资源 (CR) 覆盖默认策略评估间隔。您可以配置持续时间设置,以定义 ConfigurationPolicy CR 在 RHACM 重新评估集群策略前处于策略合规或不合规的时长。

GitOps Zero Touch Provisioning (ZTP) 策略生成器使用预定义的策略评估间隔生成 ConfigurationPolicy CR 策略。noncompliant 状态的默认值为 10 秒。compliant 状态的默认值为 10 分钟。要禁用评估间隔,将值设为 never

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 您已创建了管理自定义站点配置数据的 Git 存储库。

流程

  1. 要为 PolicyGenerator CR 中的所有策略配置评估间隔,请为 evaluationInterval 字段设置适当的 compliantnoncompliant 值。例如:

    policyDefaults:
      evaluationInterval:
        compliant: 30m
        noncompliant: 45s
    注意

    您还可以将 compliantnoncompliant 字段设置为 never 在达到特定合规状态后停止评估策略。

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

    policies:
      - name: "sriov-sub-policy"
        manifests:
          - path: "SriovSubscription.yaml"
            evaluationInterval:
              compliant: never
              noncompliant: 10s
  3. 在 Git 存储库中提交 PolicyGenerator 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"}

9.2.5. 使用验证器通知策略信号 GitOps ZTP 集群部署完成

创建一个验证器通知策略,在 GitOps Zero Touch Provisioning (ZTP) 安装和配置完成部署集群时信号。此策略可用于部署单节点 OpenShift 集群、三节点集群和标准集群。

流程

  1. 创建包含源文件 validatorCR/informDuValidator.yaml 的独立 PolicyGenerator 自定义资源 (CR)。每个集群类型只需要一个独立 PolicyGenerator CR。例如,此 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

  2. 在 Git 存储库中提交 PolicyGenerator CR 文件并推送更改。

其他资源

9.2.6. 使用 PolicyGenerator CR 配置电源状态

对于低延迟和高性能部署,需要禁用或限制 C-states 和 P-states。使用这个配置,CPU 以恒定的频率运行,通常是最大 turbo 频率。这样可确保 CPU 始终以最大速度运行,这会导致高性能和低延迟。这会导致工作负载的最佳延迟。但是,这也会导致最高的功耗,这可能并不适用于所有工作负载。

工作负载可以归类为关键或非关键状态,需要为高性能和低延迟禁用 C-state 和 P-state 设置,而非关键工作负载在某些延迟和性能方面使用 C-state 和 P-state 设置。您可以使用 GitOps Zero Touch Provisioning (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 站点配置存储库"中所述的步骤。

9.2.6.1. 使用 PolicyGenerator CR 配置性能模式

按照以下示例,根据 acm-group-du-sno-ranGen.yaml 中的 PolicyGenerator CR 更新生成的 PerformanceProfile CR 中的 workloadHints 字段来设置性能模式。

性能模式在相对高功耗时提供低延迟。

先决条件

  • 您已按照"配置主机固件以实现低延迟和高性能"中的指导配置了与性能相关的 BIOS。

流程

  1. out/argocd/example/acmpolicygenerator// 中更新 acm-group-du-sno-ranGen.yaml 参考文件中的 PerformanceProfilePolicyGenerator 条目,以设置性能模式。

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            workloadHints:
                 realTime: true
                 highPowerConsumption: false
                 perPodPowerManagement: false
  2. 在 Git 中提交 PolicyGenerator 的更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。

9.2.6.2. 使用 PolicyGenerator CR 配置高性能模式

按照以下示例,根据 acm-group-du-sno-ranGen.yaml 中的 PolicyGenerator CR 更新生成的 PerformanceProfile CR 中的 workloadHints 字段来设置高性能模式。

高性能模式以最高的功耗提供大量低延迟。

先决条件

  • 您已按照"配置主机固件以实现低延迟和高性能"中的指导配置了与性能相关的 BIOS。

流程

  1. out/argocd/example/acmpolicygenerator/ 中更新 acm-group-du-sno-ranGen.yaml 参考文件中的 PerformanceProfilePolicyGenerator 条目,以设置高性能模式。

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            workloadHints:
                 realTime: true
                 highPowerConsumption: true
                 perPodPowerManagement: false
  2. 在 Git 中提交 PolicyGenerator 的更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。

9.2.6.3. 使用 PolicyGenerator CR 配置节能模式

按照以下示例,根据 acm-group-du-sno-ranGen.yaml 中的 PolicyGenerator CR 更新生成的 PerformanceProfile CR 中的 workloadHints 字段来设置节能模式。

节能模式会在增加延迟的情况下平衡功耗。

先决条件

  • 您在 BIOS 中启用了 C-states 和 OS 控制的 P-states。

流程

  1. out/argocd/example/acmpolicygenerator/ 中更新 acm-group-du-sno-ranGen.yaml 参考文件中的 PerformanceProfilePolicyGenerator 条目,以配置节能模式。建议您通过额外的内核参数对象为节能模式配置 CPU 调控器。

    - path: source-crs/PerformanceProfile.yaml
      patches:
        - spec:
            # ...
            workloadHints:
              realTime: true
              highPowerConsumption: false
              perPodPowerManagement: true
            # ...
            additionalKernelArgs:
              - # ...
              - "cpufreq.default_governor=schedutil" 1
    1
    建议使用 schedutil governor,但您也可以使用其他 governor,包括 ondemandpowersave
  2. 在 Git 中提交 PolicyGenerator 的更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。

验证

  1. 使用以下命令,从标识的节点列表中选择部署的集群中的 worker 节点:

    $ oc get nodes
  2. 使用以下命令登录到节点:

    $ oc debug node/<node-name>

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

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

    # chroot /host
  4. 运行以下命令验证应用的电源状态:

    # cat /proc/cmdline

预期输出

  • 对于节能模式,intel_pstate=passive

9.2.6.4. 最大化节能

建议限制最大 CPU 频率,以实现最大节能。在非关键工作负载 CPU 中启用 C-states,而不会限制最大 CPU 频率,从而提高了关键 CPU 的频率。

通过更新 sysfs 插件字段来最大化节能,为参考配置的 Tuned PerformancePatch CR 中的 max_perf_pct 设置适当的值。这个示例基于 acm-group-du-sno-ranGen.yaml 描述了限制最大 CPU 频率的步骤。

先决条件

  • 您已配置了节能模式,如"使用 PolicyGenerator CR 来配置节能模式"中所述。

流程

  1. 更新 out/argocd/example/acmpolicygenerator/ 中的 acm-group-du-sno-ranGen.yaml 参考文件中的 Tuned PerformancePatchPolicyGenerator 条目。要最大化节能,请添加 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 中的最大支持频率。作为起点,您可以使用以 All Cores Turbo 频率封装所有 CPU 的百分比。All Cores Turbo 频率是所有内核在运行的频率,当内核完全占用时。
    注意

    要最大化节能,请设置一个较低的值。为 max_perf_pct 设置较低值会限制最大 CPU 频率,从而减少功耗,但可能会影响性能。试验不同的值并监控系统性能和功耗,以查找您的用例的最佳设置。

  2. 在 Git 中提交 PolicyGenerator 的更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。

9.2.7. 使用 PolicyGenerator CR 配置 LVM 存储

您可以使用 GitOps Zero Touch Provisioning (ZTP)为部署的受管集群配置逻辑卷管理器(LVM)存储。

注意

当使用 PTP 事件或带有 HTTP 传输的裸机硬件事件时,您可以使用 LVM Storage 来保留事件订阅。

将 Local Storage Operator 用于在分布式单元中使用本地卷的持久性存储。

先决条件

  • 安装 OpenShift CLI(oc)。
  • 以具有 cluster-admin 特权的用户身份登录。
  • 创建一个 Git 存储库,在其中管理自定义站点配置数据。

流程

  1. 要为新的受管集群配置 LVM 存储,请在 acm-common-ranGen.yaml 文件中的 policies.manifests 中添加以下 YAML:

    - 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
    注意

    Storage LVMO 订阅已弃用。在以后的 OpenShift Container Platform 版本中,存储 LVMO 订阅将不可用。反之,您必须使用 Storage LVMS 订阅。

    在 OpenShift Container Platform 4.17 中,您可以使用 Storage LVMS 订阅而不是 LVMO 订阅。LVMS 订阅不需要在 acm-common-ranGen.yaml 文件中手动覆盖。将以下 YAML 添加到 acm-common-ranGen.yaml 文件中的 policies.manifests 以使用 Storage LVMS 订阅:

    - path: source-crs/StorageLVMSubscriptionNS.yaml
    - path: source-crs/StorageLVMSubscriptionOperGroup.yaml
    - path: source-crs/StorageLVMSubscription.yaml
  2. LVMCluster CR 添加到特定组或单个站点配置文件中的 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 的磁盘除外。也创建了一个精简池逻辑卷。

  3. 将任何其他必要的更改和文件与自定义站点存储库合并。
  4. 提交 Git 中的 PolicyGenerator 更改,然后将更改推送到站点配置存储库,以使用 GitOps ZTP 将 LVM 存储部署到新站点。

9.2.8. 使用 PolicyGenerator CR 配置 PTP 事件

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

9.2.8.1. 配置使用 HTTP 传输的 PTP 事件

您可以配置使用 GitOps Zero Touch Provisioning (ZTP)管道部署的受管集群中使用 HTTP 传输的 PTP 事件。

先决条件

  • 已安装 OpenShift CLI(oc)。
  • 您已以具有 cluster-admin 权限的用户身份登录。
  • 您已创建了管理自定义站点配置数据的 Git 存储库。

流程

  1. 根据您的要求,将以下 PolicyGenerator 应用到 acm-group-du-3node-ranGen.yaml,acm-group-du-sno-ranGen.yaml, 或 acm-group-du-standard-ranGen.yaml 文件:

    1. policies.manifests 中,添加 PtpOperatorConfig CR 文件来配置传输主机:

      - 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 或更高版本中,在使用带有 PTP 事件的 HTTP 传输时,您不需要在 PtpOperatorConfig 资源中设置 transportHost 字段。

    2. 为 PTP 时钟类型和接口配置 linuxptpphc2sys。例如,将以下 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: -100
      1
      可以是 PtpConfigMaster.yamlPtpConfigSlave.yamlPtpConfigSlaveCvl.yaml 之一,具体取决于您的要求。PtpConfigSlaveCvl.yaml 为 Intel E810 Columbiaville NIC 配置 linuxptp 服务。对于基于 acm-group-du-sno-ranGen.yamlacm-group-du-3node-ranGen.yaml 的配置,请使用 PtpConfigSlave.yaml
      2
      特定于设备的接口名称。
      3
      您必须将 --summary_interval -4 值附加到 .spec.sourceFiles.spec.profile 中的 ptp4lOpts 中,以启用 PTP fast 事件。
      4
      所需的 phc2sysOpts 值。-m 将消息输出到 stdoutlinuxptp-daemon DaemonSet 解析日志并生成 Prometheus 指标。
      5
      可选。如果 ptpClockThreshold 小节不存在,则默认值用于 ptpClockThreshold 字段。小节显示默认的 ptpClockThreshold 值。ptpClockThreshold 值配置 PTP master 时钟在触发 PTP 事件前的时长。holdOverTimeout 是在 PTP master clock 断开连接时,PTP 时钟事件状态更改为 FREERUN 前的时间值(以秒为单位)。maxOffsetThresholdminOffsetThreshold 设置以纳秒为单位,它们与 CLOCK_REALTIME (phc2sys) 或 master 偏移 (ptp4l) 的值进行比较。当 ptp4lphc2sys 偏移值超出这个范围时,PTP 时钟状态被设置为 FREERUN。当偏移值在这个范围内时,PTP 时钟状态被设置为 LOCKED
  2. 将任何其他必要的更改和文件与自定义站点存储库合并。
  3. 将更改推送到站点配置存储库,以使用 GitOps ZTP 将 PTP 快速事件部署到新站点。

9.2.9. 配置 Image Registry Operator 以进行镜像的本地缓存

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

在初始部署期间,长时间下载时间不可避免。随着时间的推移,CRI-O 会在出现意外关闭时擦除 /var/lib/containers/storage 目录的风险。要解决镜像下载时间长的问题,您可以使用 GitOps Zero Touch Provisioning (ZTP) 在远程受管集群上创建本地镜像 registry。当集群部署在网络边缘时,这非常有用。

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

注意

本地镜像 registry 只能用于用户应用程序镜像,不能用于 OpenShift Container Platform 或 Operator Lifecycle Manager operator 镜像。

9.2.9.1. 使用 SiteConfig 配置磁盘分区

使用 SiteConfig CR 和 GitOps Zero Touch Provisioning (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
    指定分区的大小。如果值太小,部署会失败。
  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 字段中。

    Example

    [...]
    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 节点上进入 debug 会话。此步骤被实例化为一个名为 <node_name>-debug 的 debug pod:

      $ oc debug node/my-sno-node
    2. 运行以下命令,将 /host 设置为 debug shell 中的根目录。debug pod 在 pod 中的 /host 中挂载主机的 root 文件系统。将根目录改为 /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

9.2.9.2. 使用 PolicyGenerator CR 配置镜像 registry

使用 PolicyGenerator (PGT) CR 应用配置镜像 registry 所需的 CR,并修补 imageregistry 配置。

先决条件

  • 您已在受管集群中配置了磁盘分区。
  • 已安装 OpenShift CLI(oc)。
  • 已以具有 cluster-admin 权限的用户身份登录到 hub 集群。
  • 您已创建了 Git 存储库,在其中管理自定义站点配置数据以用于 GitOps Zero Touch Provisioning (ZTP)。

流程

  1. 在适当的 PolicyGenerator CR 中配置存储类、持久性卷声明、持久性卷和镜像 registry 配置。例如,要配置单个站点,请将以下 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
    根据您要在站点、通用或组级别配置镜像 registry,为 ztp-deploy-wave 设置适当的值。ZTP-deploy-wave: "100" 适用于开发或测试,因为它允许您将引用的源文件分组到一起。
    2
    ImageRegistryPV.yaml 中,确保将 spec.local.path 字段设置为 /var/imageregistry,以匹配 SiteConfig CR 中为 mount_point 字段设置的值。
    重要

    不要为 - fileName: ImageRegistryConfig.yaml 配置设置 complianceType: mustonlyhave。这可能导致 registry pod 部署失败。

  2. 在 Git 中提交 PolicyGenerator 的更改,然后推送到由 GitOps ZTP Argo CD 应用程序监控的 Git 存储库。

验证

使用以下步骤排除受管集群中本地镜像 registry 的错误:

  • 在登录到受管集群时,验证是否成功登录到 registry。运行以下命令:

    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. 验证从受管集群访问镜像 registry。请参阅"访问 registry"。
  • 检查 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 表示磁盘已被正确分区。

其他资源

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.