使用节点调优算子 | 可扩展性和性能 | OpenShift Container Platform 4.17

关于节点调整运算符
访问节点调整运算符规范示例
在集群上设置的默认配置文件
验证 TuneD 配置文件是否已应用
自定义调整规范
自定义调整示例
支持的 TuneD 守护程序插件
在托管集群中配置节点调整
通过设置内核引导参数为托管集群进行高级节点调整

了解节点调整运算符以及如何使用它通过协调 tuned 守护程序来管理节点级调整。

关于节点调整运算符

节点调整运算符可帮助您通过协调 TuneD 守护程序来管理节点级调整，并通过使用性能配置文件控制器来实现低延迟性能。大多数高性能应用程序都需要某种程度的内核调整。节点调整运算符为节点级 sysctl 的用户提供了一个统一的管理界面，并提供了更多灵活性来添加用户需求指定的自定义调整。

操作员将容器化的 TuneD 守护进程作为 Kubernetes 守护程序集管理 OpenShift Container Platform。它确保自定义调整规范以守护进程能够理解的格式传递给集群中运行的所有容器化 TuneD 守护进程。守护进程在集群中的所有节点上运行，每个节点一个。

容器化 TuneD 守护进程应用的节点级设置会在触发配置文件更改的事件中回滚，或者在容器化 TuneD 守护进程通过接收和处理终止信号而被优雅地终止时回滚。

节点调整操作员使用性能配置文件控制器实现自动调整，以实现 OpenShift Container Platform 应用程序的低延迟性能。

集群管理员配置性能配置文件以定义以下节点级设置：

将内核更新为 kernel-rt。
选择用于维护的 CPU。
选择用于运行工作负载的 CPU。

节点调整操作员是 4.1 及更高版本标准 OpenShift Container Platform 安装的一部分。

在早期版本的 OpenShift Container Platform 中，使用性能附加组件操作员来实现自动调整，以实现 OpenShift 应用程序的低延迟性能。在 OpenShift Container Platform 4.11 及更高版本中，此功能是节点调整操作员的一部分。

访问示例节点调整操作员规范

使用此过程访问示例节点调整操作员规范。

步骤

运行以下命令以访问示例节点调整操作员规范

oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator

默认 CR 旨在为 OpenShift Container Platform 平台提供标准的节点级调整，并且只能修改它来设置操作员管理状态。对默认 CR 的任何其他自定义更改都将被操作员覆盖。对于自定义调整，请创建您自己的 Tuned CR。新创建的 CR 将与默认 CR 结合，并根据节点或 Pod 标签和配置文件优先级将自定义调整应用于 OpenShift Container Platform 节点。

虽然在某些情况下，对 Pod 标签的支持可以作为自动提供所需调整的便捷方式，但不建议这样做，尤其是在大型集群中。默认 Tuned CR 没有 Pod 标签匹配功能。如果创建具有 Pod 标签匹配功能的自定义配置文件，则该功能将在此时启用。Pod 标签功能将在未来版本的节点调整操作员中弃用。

集群上设置的默认配置文件

以下是集群上设置的默认配置文件。

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/ocp-tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

从 OpenShift Container Platform 4.9 开始，所有 OpenShift TuneD 配置文件都随 TuneD 包一起提供。您可以使用oc exec 命令查看这些配置文件的内容。

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

验证 TuneD 配置文件是否已应用

验证应用于集群节点的 TuneD 配置文件。

$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

示例输出

NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m

名称 (NAME)：配置文件对象的名称。每个节点都有一个配置文件对象，并且它们的名称匹配。
TUNED：要应用的所需 TuneD 配置文件的名称。
已应用 (APPLIED)：如果 TuneD 守护进程应用了所需的配置文件，则为 True。（True/False/Unknown）。
已降级 (DEGRADED)：如果在应用 TuneD 配置文件期间报告了任何错误，则为 True。（True/False/Unknown）。
年龄 (AGE)：自创建配置文件对象以来经过的时间。

ClusterOperator/node-tuning 对象还包含有关操作员及其节点代理运行状况的有用信息。例如，ClusterOperator/node-tuning 状态消息会报告操作员错误配置。

要获取有关ClusterOperator/node-tuning 对象的状态信息，请运行以下命令：

$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator

示例输出

NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.17.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict

如果ClusterOperator/node-tuning 或配置文件对象的状态为DEGRADED，则会在操作员或操作数日志中提供其他信息。

自定义调整规范

操作员的自定义资源 (CR) 具有两个主要部分。第一部分profile: 是 TuneD 配置文件及其名称的列表。第二个recommend: 定义了配置文件选择逻辑。

多个自定义调整规范可以作为操作员命名空间中的多个 CR 共存。操作员会检测到新 CR 的存在或旧 CR 的删除。所有现有的自定义调整规范都会合并，并更新容器化 TuneD 守护进程的相应对象。

管理状态

通过调整默认 Tuned CR 来设置操作员管理状态。默认情况下，操作员处于“已管理”状态，并且默认 Tuned CR 中不存在spec.managementState 字段。操作员管理状态的有效值如下：

已管理 (Managed)：操作员将在更新配置资源时更新其操作数。
未管理 (Unmanaged)：操作员将忽略对配置资源的更改。
已移除 (Removed)：操作员将删除其操作数和操作员提供的资源。

配置文件数据

profile: 部分列出了 TuneD 配置文件及其名称。

profile:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

推荐的配置文件

profile: 选择逻辑由 CR 的recommend: 部分定义。recommend: 部分是根据选择条件推荐配置文件的项目列表。

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

列表的各个项目

- machineConfigLabels: (1)
    <mcLabels> (2)
  match: (3)
    <match> (4)
  priority: <priority> (5)
  profile: <tuned_profile_name> (6)
  operand: (7)
    debug: <bool> (8)
    tunedConfig:
      reapply_sysctl: <bool> (9)

1	可选。
2	键/值`MachineConfig` 标签的字典。键必须唯一。
3	如果省略，则假设配置文件匹配，除非具有更高优先级的配置文件首先匹配或设置了`machineConfigLabels`。
4	可选列表。
5	配置文件排序优先级。数字越小，优先级越高（`0` 是最高优先级）。
6	要在匹配时应用的 TuneD 配置文件。例如`tuned_profile_1`。
7	可选操作数配置。
8	为 TuneD 守护进程打开或关闭调试。选项包括：`true` 为打开，`false` 为关闭。默认为`false`。
9	为 TuneD 守护进程打开或关闭`reapply_sysctl` 功能。选项包括：`true` 为打开，`false` 为关闭。

<match> 是一个可选列表，递归定义如下：

- label: <label_name> (1)
  value: <label_value> (2)
  type: <label_type> (3)
    <match> (4)

1	节点或 Pod 标签名称。
2	可选节点或 Pod 标签值。如果省略，则`<label_name>` 的存在足以匹配。
3	可选对象类型（`node` 或 `pod`）。如果省略，则假定为`node`。
4	可选的`<match>` 列表。

如果未省略<match>，则所有嵌套的<match> 部分也必须计算为true。否则，将假定为false，并且不会应用或推荐具有相应<match> 部分的配置文件。因此，嵌套（子<match> 部分）充当逻辑 AND 运算符。相反，如果<match> 列表的任何项目匹配，则整个<match> 列表将计算为true。因此，列表充当逻辑 OR 运算符。

如果定义了machineConfigLabels，则为给定的recommend: 列表项目打开基于机器配置池的匹配。<mcLabels> 指定机器配置的标签。将自动创建机器配置以应用主机设置（例如内核启动参数）以用于配置文件<tuned_profile_name>。这涉及查找所有机器配置池，其机器配置选择器与<mcLabels> 匹配，并在分配了找到的机器配置池的所有节点上设置配置文件<tuned_profile_name>。要定位同时具有主节点和工作节点角色的节点，必须使用主节点角色。

列表项match和machineConfigLabels通过逻辑或运算符连接。match项首先以短路方式进行评估。因此，如果它评估结果为true，则不会考虑machineConfigLabels项。

使用基于机器配置池的匹配时，建议将具有相同硬件配置的节点分组到同一个机器配置池中。不遵循此做法可能会导致TuneD操作数为共享相同机器配置池的两个或多个节点计算冲突的内核参数。

示例：基于节点或 Pod 标签的匹配

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

上面的 CR 根据配置文件优先级转换为容器化 TuneD 守护程序的recommend.conf文件。优先级最高的配置文件（10）是openshift-control-plane-es，因此它首先被考虑。在给定节点上运行的容器化 TuneD 守护程序会查看在同一节点上是否运行带有tuned.openshift.io/elasticsearch标签的 Pod。如果没有，则整个<match>部分评估结果为false。如果存在具有该标签的 Pod，则为了使<match>部分评估结果为true，节点标签也需要是node-role.kubernetes.io/master或node-role.kubernetes.io/infra。

如果优先级为10的配置文件的标签匹配，则应用openshift-control-plane-es配置文件，并且不考虑其他配置文件。如果节点/Pod 标签组合不匹配，则考虑第二高优先级的配置文件（openshift-control-plane）。如果容器化 TuneD Pod 在带有标签node-role.kubernetes.io/master或node-role.kubernetes.io/infra的节点上运行，则应用此配置文件。

最后，配置文件openshift-node的优先级最低，为30。它缺少<match>部分，因此始终匹配。如果在给定节点上没有其他更高优先级的配置文件匹配，它充当配置文件的通配符以设置openshift-node配置文件。

示例：基于机器配置池的匹配

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

为了最大限度地减少节点重启次数，请使用机器配置池的节点选择器将匹配的标签标记到目标节点上，然后创建上面的 Tuned CR，最后创建自定义机器配置池本身。

特定于云提供商的 TuneD 配置文件

通过此功能，可以方便地将所有特定于云提供商的节点分配给专门为 OpenShift Container Platform 集群上的给定云提供商定制的 TuneD 配置文件。这无需添加额外的节点标签或将节点分组到机器配置池中即可完成。

此功能利用spec.providerID节点对象的<cloud-provider>://<cloud-provider-specific-id>形式的值，并在 NTO 操作数容器中使用<cloud-provider>值写入文件/var/lib/ocp-tuned/provider。然后，TuneD 使用此文件的内容加载provider-<cloud-provider>配置文件（如果存在此类配置文件）。

openshift-control-plane和openshift-node配置文件都继承设置的openshift配置文件现在已通过使用条件配置文件加载来更新此功能。NTO 和 TuneD 当前都不包含任何特定于云提供商的配置文件。但是，可以创建自定义配置文件provider-<cloud-provider>，该配置文件将应用于所有特定于云提供商的集群节点。

示例 GCE 云提供商配置文件

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

由于配置文件继承，provider-<cloud-provider>配置文件中指定的任何设置都将被openshift配置文件及其子配置文件覆盖。

自定义调整示例

使用默认 CR 中的 TuneD 配置文件

以下 CR 为标签tuned.openshift.io/ingress-node-label设置为任何值的 OpenShift Container Platform 节点应用自定义节点级调整。

示例：使用 openshift-control-plane TuneD 配置文件进行自定义调整

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress

强烈建议自定义配置文件编写者包含默认 Tuned CR 中提供的默认 TuneD 守护程序配置文件。上面的示例使用默认的openshift-control-plane配置文件来实现此目的。

使用内置 TuneD 配置文件

鉴于 NTO 管理的 DaemonSet 成功推出，所有 TuneD 操作数都管理相同版本的 TuneD 守护程序。要列出守护程序支持的内置 TuneD 配置文件，请按以下方式查询任何 TuneD Pod

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'

您可以在自定义调整规范中使用由此检索的配置文件名称。

示例：使用内置 hpc-compute TuneD 配置文件

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-hpc-compute
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile for HPC compute workloads
      include=openshift-node,hpc-compute
    name: openshift-node-hpc-compute

  recommend:
  - match:
    - label: tuned.openshift.io/openshift-node-hpc-compute
    priority: 20
    profile: openshift-node-hpc-compute

除了内置的hpc-compute配置文件外，上面的示例还包括默认 Tuned CR 中提供的openshift-node TuneD 守护程序配置文件，以便为计算节点使用 OpenShift 特定的调整。

覆盖主机级 sysctl

可以使用/run/sysctl.d/、/etc/sysctl.d/和/etc/sysctl.conf主机配置文件在运行时更改各种内核参数。OpenShift Container Platform 添加了几个主机配置文件，这些文件在运行时设置内核参数；例如，net.ipv[4-6].、fs.inotify.和vm.max_map_count。这些运行时参数在 kubelet 和 Operator 启动之前为系统提供基本的函数调整。

除非reapply_sysctl选项设置为false，否则 Operator 不会覆盖这些设置。将此选项设置为false会导致TuneD在其应用自定义配置文件后不应用主机配置文件中的设置。

示例：覆盖主机级 sysctl

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-no-reapply-sysctl
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift profile
      include=openshift-node
      [sysctl]
      vm.max_map_count=>524288
    name: openshift-no-reapply-sysctl
  recommend:
  - match:
    - label: tuned.openshift.io/openshift-no-reapply-sysctl
    priority: 15
    profile: openshift-no-reapply-sysctl
    operand:
      tunedConfig:
        reapply_sysctl: false

支持的 TuneD 守护程序插件

排除[main]部分，在使用 Tuned CR 的profile:部分中定义的自定义配置文件时，支持以下 TuneD 插件

audio
cpu
disk
eeepc_she
modules
mounts
net
scheduler
scsi_host
selinux
sysctl
sysfs
usb
video
vm
bootloader

一些插件提供的一些动态调整功能不受支持。目前不支持以下 TuneD 插件

script
systemd

TuneD bootloader 插件仅支持 Red Hat Enterprise Linux CoreOS (RHCOS) 工作节点。

其他资源

在托管集群中配置节点调整

要在托管集群中的节点上设置节点级调整，可以使用节点调整运算符。在托管控制平面中，您可以通过创建包含Tuned对象的 ConfigMap 并引用节点池中的这些 ConfigMap 来配置节点调整。

步骤

创建一个包含有效 tuned 清单的 ConfigMap，并在节点池中引用该清单。在以下示例中，Tuned清单定义一个配置文件，该配置文件将vm.dirty_ratio设置为 55，适用于包含任何值的tuned-1-node-label节点标签的节点。将以下ConfigMap清单保存到名为tuned-1.yaml的文件中

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tuned-1
      namespace: clusters
    data:
      tuning: |
        apiVersion: tuned.openshift.io/v1
        kind: Tuned
        metadata:
          name: tuned-1
          namespace: openshift-cluster-node-tuning-operator
        spec:
          profile:
          - data: |
              [main]
              summary=Custom OpenShift profile
              include=openshift-node
              [sysctl]
              vm.dirty_ratio="55"
            name: tuned-1-profile
          recommend:
          - priority: 20
            profile: tuned-1-profile

如果未向 Tuned spec 的spec.recommend部分中的条目添加任何标签，则假定基于节点池的匹配，因此spec.recommend部分中优先级最高的配置文件将应用于池中的节点。虽然可以通过在 Tuned.spec.recommend.match部分中设置标签值来实现更细粒度的基于节点标签的匹配，但除非将节点池的.spec.management.upgradeType值设置为InPlace，否则节点标签在升级期间不会持久存在。

在管理集群中创建ConfigMap对象

$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml

通过编辑节点池或创建一个节点池，在节点池的spec.tuningConfig字段中引用ConfigMap对象。在此示例中，假设您只有一个名为nodepool-1的NodePool，其中包含 2 个节点。

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
      ...
      name: nodepool-1
      namespace: clusters
    ...
    spec:
      ...
      tuningConfig:
      - name: tuned-1
    status:
    ...

可以在多个节点池中引用相同的 ConfigMap。在托管控制平面中，节点调整运算符会将节点池名称和命名空间的哈希值附加到 Tuned CR 的名称中，以区分它们。在此情况之外，请勿为同一个托管集群中的不同 Tuned CR 创建多个同名的 TuneD 配置文件。

验证

创建包含 Tuned 清单的 ConfigMap 对象并在 NodePool 中引用它之后，节点调整运算符会将 Tuned 对象同步到托管集群。您可以验证定义了哪些 Tuned 对象以及哪些 TuneD 配置文件应用于每个节点。

列出托管集群中的 Tuned 对象

$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

示例输出

NAME       AGE
default    7m36s
rendered   7m36s
tuned-1    65s

列出托管集群中的 Profile 对象

$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

示例输出

NAME                           TUNED            APPLIED   DEGRADED   AGE
nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
nodepool-1-worker-2            tuned-1-profile  True      False      7m14s

如果未创建自定义配置文件，则默认应用 openshift-node 配置文件。

要确认调整是否正确应用，请在节点上启动调试 shell 并检查 sysctl 值

$ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

示例输出

vm.dirty_ratio = 55

通过设置内核启动参数来高级调整托管集群的节点

对于托管控制平面中的更高级调整（需要设置内核启动参数），您也可以使用节点调整运算符。以下示例显示如何创建预留巨页的节点池。

步骤

创建一个包含 Tuned 对象清单的 ConfigMap 对象，用于创建 10 个大小为 2 MB 的巨页。将此 ConfigMap 清单保存到名为 tuned-hugepages.yaml 的文件中。

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: tuned-hugepages
      namespace: clusters
    data:
      tuning: |
        apiVersion: tuned.openshift.io/v1
        kind: Tuned
        metadata:
          name: hugepages
          namespace: openshift-cluster-node-tuning-operator
        spec:
          profile:
          - data: |
              [main]
              summary=Boot time configuration for hugepages
              include=openshift-node
              [bootloader]
              cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
            name: openshift-node-hugepages
          recommend:
          - priority: 20
            profile: openshift-node-hugepages

.spec.recommend.match 字段故意留空。在这种情况下，此 Tuned 对象将应用于引用此 ConfigMap 对象的节点池中的所有节点。将具有相同硬件配置的节点分组到同一个节点池中。否则，TuneD 操作数可能会为共享同一个节点池的两个或多个节点计算冲突的内核参数。

在管理集群中创建ConfigMap对象
```
$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml (1)
```
1 将 <management_cluster_kubeconfig> 替换为管理集群 kubeconfig 文件的名称。

创建一个 NodePool 清单 YAML 文件，自定义 NodePool 的升级类型，并在 spec.tuningConfig 部分引用您创建的 ConfigMap 对象。使用 hcp CLI 创建 NodePool 清单并将其保存到名为 hugepages-nodepool.yaml 的文件中。

$ hcp create nodepool aws \
  --cluster-name <hosted_cluster_name> \(1)
  --name <nodepool_name> \(2)
  --node-count <nodepool_replicas> \(3)
  --instance-type <instance_type> \(4)
  --render > hugepages-nodepool.yaml

1	将 `<hosted_cluster_name>` 替换为托管集群的名称。
2	将 `<nodepool_name>` 替换为节点池的名称。
3	将 `<nodepool_replicas>` 替换为节点池副本的数量，例如 `2`。
4	将 `<instance_type>` 替换为实例类型，例如 `m5.2xlarge`。

hcp create 命令中的 --render 标志不会渲染密钥。要渲染密钥，必须在 hcp create 命令中同时使用 --render 和 --render-sensitive 标志。

在 hugepages-nodepool.yaml 文件中，将 .spec.management.upgradeType 设置为 InPlace，并将 .spec.tuningConfig 设置为引用您创建的 tuned-hugepages ConfigMap 对象。

    apiVersion: hypershift.openshift.io/v1alpha1
    kind: NodePool
    metadata:
      name: hugepages-nodepool
      namespace: clusters
      ...
    spec:
      management:
        ...
        upgradeType: InPlace
      ...
      tuningConfig:
      - name: tuned-hugepages

为了避免在应用新的 MachineConfig 对象时不必要地重新创建节点，请将 .spec.management.upgradeType 设置为 InPlace。如果使用 Replace 升级类型，则在应用 TuneD 操作数计算的新内核启动参数时，节点将被完全删除，新节点可以替换它们。

在管理集群中创建 NodePool

$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml

验证

节点可用后，容器化的 TuneD 守护程序将根据应用的 TuneD 配置文件计算所需的内核启动参数。节点准备好并重新启动一次以应用生成的 MachineConfig 对象后，您可以验证 TuneD 配置文件是否已应用以及内核启动参数是否已设置。

列出托管集群中的 Tuned 对象

$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

示例输出

NAME                 AGE
default              123m
hugepages-8dfb1fed   1m23s
rendered             123m

列出托管集群中的 Profile 对象

$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

示例输出

NAME                           TUNED                      APPLIED   DEGRADED   AGE
nodepool-1-worker-1            openshift-node             True      False      132m
nodepool-1-worker-2            openshift-node             True      False      131m
hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s

新 NodePool 中的两个工作节点都应用了 openshift-node-hugepages 配置文件。

要确认调整是否正确应用，请在节点上启动调试 shell 并检查 /proc/cmdline。

$ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

示例输出

BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

其他资源

托管控制平面概述