5.3. 启用 Linux 控制组版本 2(cgroups v2)


您可以使用机器配置在集群中的特定节点上启用 Linux 控制组群版本 2 (cgroups v2)。用于启用 cgroups v2 的 OpenShift Container Platform 进程会禁用所有 cgroup 版本 1 控制器和层次结构。

重要

OpenShift Container Platform cgroup 版本 2 功能是一个开发者预览(Developer Preview)功能,目前还不被红帽支持。

先决条件

  • 您有一个正在运行的 OpenShift Container Platform 集群,它使用版本 4.10 或更高版本。
  • 以具有管理特权的用户身份登录集群。
  • 您有要配置的节点的 node-role.kubernetes.io 值。

    $ oc describe node <node-name>

    输出示例

    Name:               ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg
    Roles:              worker
    Labels:             beta.kubernetes.io/arch=amd64
                        beta.kubernetes.io/instance-type=n1-standard-4
                        beta.kubernetes.io/os=linux
                        failure-domain.beta.kubernetes.io/region=us-central1
                        failure-domain.beta.kubernetes.io/zone=us-central1-a
                        kubernetes.io/arch=amd64
                        kubernetes.io/hostname=ci-ln-v05w5m2-72292-5s9ht-worker-a-r6fpg
                        kubernetes.io/os=linux
                        node-role.kubernetes.io/worker= 1
    #...

    1
    这个值是您需要的节点角色。

流程

  1. 在节点上启用 cgroup v2:

    • 创建机器配置文件 YAML,如 worker-cgroups-v2.yaml

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfig
      metadata:
        labels:
          machineconfiguration.openshift.io/role: "worker" 1
        name: worker-enable-cgroups-v2
      spec:
        kernelArguments:
          - systemd.unified_cgroup_hierarchy=1 2
          - cgroup_no_v1="all" 3
      1
      为您要配置的节点指定 node-role.kubernetes.io 值,如 masterworkerinfra
      2
      在 systemd 中启用 cgroup v2。
      3
      禁用 cgroup v1。
    • 创建新机器配置:

      $ oc create -f worker-enable-cgroups-v2.yaml
  2. 检查机器配置以查看是否添加了新配置:

    $ oc get MachineConfig

    输出示例

    NAME                                               GENERATEDBYCONTROLLER                      IGNITIONVERSION   AGE
    00-master                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    00-worker                                          52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-master-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-container-runtime                        52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    01-worker-kubelet                                  52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-master-ssh                                                                                 3.2.0             40m
    99-worker-generated-registries                     52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    99-worker-ssh                                                                                 3.2.0             40m
    rendered-master-23e785de7587df95a4b517e0647e5ab7   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    rendered-worker-5d596d9293ca3ea80c896a1191735bb1   52dd3ba6a9a527fc3ab42afac8d12b693534c8c9   3.2.0             33m
    worker-enable-cgroups-v2                                                                      3.2.0             10s

  3. 检查节点,以查看每个受影响节点上的调度是否已禁用。这表示要应用更改:

    $ oc get nodes

    输出示例

    NAME                                       STATUS                     ROLES    AGE   VERSION
    ci-ln-fm1qnwt-72292-99kt6-master-0         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-master-1         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-master-2         Ready                      master   58m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-a-h5gt4   Ready,SchedulingDisabled   worker   48m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-b-7vtmd   Ready                      worker   48m   v1.24.0
    ci-ln-fm1qnwt-72292-99kt6-worker-c-rhzkv   Ready                      worker   48m   v1.24.0

  4. 节点返回 Ready 状态后,您可以通过检查节点上是否存在 sys/fs/cgroup.controllers 文件来验证 cgroup v2 是否已启用。此文件由 cgroup v2 创建。

    • 为该节点启动一个 debug 会话:

      $ oc debug node/<node_name>
    • 找到 sys/fs/cgroup/cgroup.controllers 文件。如果存在这个文件,则在该节点上启用了 cgroup v2。

      输出示例

      cgroup.controllers	cgroup.stat		cpuset.cpus.effective  io.stat		pids
      cgroup.max.depth	cgroup.subtree_control	cpuset.mems.effective  kubepods.slice	system.slice
      cgroup.max.descendants	cgroup.threads		init.scope	       memory.pressure	user.slice
      cgroup.procs		cpu.pressure		io.pressure	       memory.stat

其他资源

  • 有关在安装过程中启用 cgroups v2 的详情,请参考安装过程的 安装配置参数部分中的可选参数表。

5.3.1. 在节点中添加实时内核

一些 OpenShift Container Platform 工作负载需要高度确定性。虽然 Linux 不是实时操作系统,但 Linux 实时内核包含一个抢占调度程序,它为操作系统提供实时特征。

如果您的 OpenShift Container Platform 工作负载需要这些实时特征,您可以将机器切换到 Linux 实时内核。对于 OpenShift Container Platform,4.11,您可以使用 MachineConfig 对象进行这个切换。虽然进行这个切换非常简单(只需要把机器配置的 kernelType 设置为 realtime),但进行更改前需要注意:

  • 目前,实时内核只支持在 worker 节点上运行,且只支持无线电访问网络(RAN)使用。
  • 使用为 Red Hat Enterprise Linux for Real Time 8 认证系统的裸机安装完全支持以下步骤。
  • OpenShift Container Platform 中的实时支持仅限于特定的订阅。
  • 以下流程也支持与 Google Cloud Platform 搭配使用。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群(版本 4.4 或更高版本)。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 为实时内核创建一个机器配置:创建一个 YAML 文件(例如,99-worker-realtime.yaml),其中包含一个 realtime 内核类型的 MachineConfig 对象。本例告诉集群在所有 worker 节点中使用实时内核:

    $ cat << EOF > 99-worker-realtime.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: "worker"
      name: 99-worker-realtime
    spec:
      kernelType: realtime
    EOF
  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中:

    $ oc create -f 99-worker-realtime.yaml
  3. 检查实时内核: 每当受影响节点重新引导后,登录到集群,并运行以下命令来确保您配置的节点组中使用实时内核替换了常规内核:

    $ oc get nodes

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-143-147.us-east-2.compute.internal  Ready   worker   103m  v1.24.0
    ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.24.0
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.24.0

    $ oc debug node/ip-10-0-143-147.us-east-2.compute.internal

    输出示例

    Starting pod/ip-10-0-143-147us-east-2computeinternal-debug ...
    To use host binaries, run `chroot /host`
    
    sh-4.4# uname -a
    Linux <worker_node> 4.18.0-147.3.1.rt24.96.el8_1.x86_64 #1 SMP PREEMPT RT
            Wed Nov 27 18:29:55 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

    内核名称包含 rt 和 "PREMPT RT" 来表示这是一个实时内核。

  4. 要返回常规内核,请删除 MachineConfig 对象:

    $ oc delete -f 99-worker-realtime.yaml

5.3.2. 配置 journald 设置

如果您需要在 OpenShift Container Platform 节点上配置 journald 服务设置,您可以修改适当的配置文件并将该文件作为机器配置传递给适当的节点池。

此流程描述了如何修改 /etc/systemd/journald.conf 文件中的 journald 限制设置并将其应用到 worker 节点。有关如何使用该文件的详情,请查看 journald.conf 手册页。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 创建一个 Butane 配置文件 40-worker-custom-journald.bu,其中包含带有所需设置的 /etc/systemd/journald.conf 文件。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    variant: openshift
    version: 4.11.0
    metadata:
      name: 40-worker-custom-journald
      labels:
        machineconfiguration.openshift.io/role: worker
    storage:
      files:
      - path: /etc/systemd/journald.conf
        mode: 0644
        overwrite: true
        contents:
          inline: |
            # Disable rate limiting
            RateLimitInterval=1s
            RateLimitBurst=10000
            Storage=volatile
            Compress=no
            MaxRetentionSec=30s
  2. 使用 Butane 生成 MachineConfig 对象文件 40-worker-custom-journald.yaml,包含要发送到 worker 节点的配置:

    $ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
  3. 将机器配置应用到池:

    $ oc apply -f 40-worker-custom-journald.yaml
  4. 检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中,每个节点都成功应用了新的机器配置:

    $ oc get machineconfigpool
    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m
  5. 要检查是否应用了更改,您可以登录到 worker 节点:

    $ oc get node | grep worker
    ip-10-0-0-1.us-east-2.compute.internal   Ready    worker   39m   v0.0.0-master+$Format:%h$
    $ oc debug node/ip-10-0-0-1.us-east-2.compute.internal
    Starting pod/ip-10-0-141-142us-east-2computeinternal-debug ...
    ...
    sh-4.2# chroot /host
    sh-4.4# cat /etc/systemd/journald.conf
    # Disable rate limiting
    RateLimitInterval=1s
    RateLimitBurst=10000
    Storage=volatile
    Compress=no
    MaxRetentionSec=30s
    sh-4.4# exit

5.3.3. 为 RHCOS 添加扩展

RHCOS 是基于容器的最小 RHEL 操作系统,旨在为所有平台的 OpenShift Container Platform 集群提供一组通用的功能。通常不建议在 RHCOS 系统中添加软件软件包,但 MCO 提供了一个 extensions(扩展) 功能,您可以使用 MCO 为 RHCOS 节点添加一组最小的功能。

目前,有以下扩展可用:

  • usbguard:添加 usbguard 扩展可保护 RHCOS 系统不受入侵 USB 设备的攻击。详情请查看 USBGuard
  • Kerberos:添加 kerberos 扩展提供了一种机制,允许用户和机器标识自身对网络进行定义的定义、限制对管理员配置的区域和服务的访问权限。请参阅使用 Kerberos 的详情,包括如何设置 Kerberos 客户端并挂载 Kerberized NFS 共享。

以下流程描述了如何使用机器配置为 RHCOS 节点添加一个或多个扩展。

先决条件

  • 有一个正在运行的 OpenShift Container Platform 集群(版本 4.6 或更高版本)。
  • 以具有管理特权的用户身份登录集群。

流程

  1. 为扩展创建机器配置:创建一个 YAML 文件(如 80-extensions.yaml),其中包含 MachineConfig extensions 对象。本例告诉集群添加 usbguard 扩展。

    $ cat << EOF > 80-extensions.yaml
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 80-worker-extensions
    spec:
      config:
        ignition:
          version: 3.2.0
      extensions:
        - usbguard
    EOF
  2. 将机器配置添加到集群。键入以下内容将机器配置添加到集群中:

    $ oc create -f 80-extensions.yaml

    这会将所有 worker 节点设置为安装 usbguard 的 rpm 软件包。

  3. 检查是否应用了扩展:

    $ oc get machineconfig 80-worker-extensions

    输出示例

    NAME                 GENERATEDBYCONTROLLER IGNITIONVERSION AGE
    80-worker-extensions                       3.2.0           57s

  4. 检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。worker 池将显示更新进行中,每台机器都成功应用了新机器配置:

    $ oc get machineconfigpool

    输出示例

    NAME   CONFIG             UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
    master rendered-master-35 True    False    False    3            3                 3                   0                    34m
    worker rendered-worker-d8 False   True     False    3            1                 1                   0                    34m

  5. 检查扩展。要检查是否应用了扩展,请运行:

    $ oc get node | grep worker

    输出示例

    NAME                                        STATUS  ROLES    AGE   VERSION
    ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.24.0

    $ oc debug node/ip-10-0-169-2.us-east-2.compute.internal

    输出示例

    ...
    To use host binaries, run `chroot /host`
    sh-4.4# chroot /host
    sh-4.4# rpm -q usbguard
    usbguard-0.7.4-4.el8.x86_64.rpm

5.3.4. 在机器配置清单中载入自定义固件 Blob

因为 /usr/lib 中固件 Blob 的默认位置是只读的,所以您可以通过更新搜索路径来查找自定义固件 Blob。这可让您在 RHCOS 不管理 blob 时载入机器配置清单中的本地固件 Blob。

流程

  1. 创建 Butane 配置文件 98-worker-firmware-blob.bu,它会更新搜索路径,以便其为 root 所有且对本地存储可写。以下示例将本地工作站的自定义 blob 文件放在 /var/lib/firmware 下的节点上。

    注意

    有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。

    自定义固件 blob 的 Butane 配置文件

    variant: openshift
    version: 4.11.0
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 98-worker-firmware-blob
    storage:
      files:
      - path: /var/lib/firmware/<package_name> 1
        contents:
          local: <package_name> 2
        mode: 0644 3
    openshift:
      kernel_arguments:
        - 'firmware_class.path=/var/lib/firmware' 4

    1
    设置将固件软件包复制到的节点上的路径。
    2
    指定包含从运行 Butane 的系统上本地文件目录中读取的内容的文件。本地文件的路径相对于 files-dir 目录,必须在下一步中使用 --files-dir 选项指定它。
    3
    为 RHCOS 节点上的文件设置权限。建议把选项设置为 0644
    4
    firmware_class.path 参数自定义内核搜索路径,在其中查找从本地工作站复制到节点的根文件系统的自定义固件 Blob。这个示例使用 /var/lib/firmware 作为自定义路径。
  2. 运行 Butane 生成 MachineConfig 对象文件,该文件使用名为 98-worker-firmware-blob.yaml 的本地工作站中的固件 blob 副本。固件 blob 包含要传送到节点的配置。以下示例使用 --files-dir 选项指定工作站上本地文件或目录所在的目录:

    $ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir <directory_including_package_name>
  3. 通过两种方式之一将配置应用到节点:

    • 如果集群还没有运行,在生成清单文件后,将 MachineConfig 对象文件添加到 <installation_directory>/openshift 目录中,然后继续创建集群。
    • 如果集群已在运行,请应用该文件:

      $ oc apply -f 98-worker-firmware-blob.yaml

      已为您创建一个 MachineConfig 对象 YAML 文件,以完成机器的配置。

  4. 如果将来需要更新 MachineConfig 对象,请保存 Butane 配置。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.