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
- 这个值是您需要的节点角色。
流程
在节点上启用 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
创建新机器配置:
$ oc create -f worker-enable-cgroups-v2.yaml
检查机器配置以查看是否添加了新配置:
$ 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
检查节点,以查看每个受影响节点上的调度是否已禁用。这表示要应用更改:
$ 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
节点返回
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 或更高版本)。
- 以具有管理特权的用户身份登录集群。
流程
为实时内核创建一个机器配置:创建一个 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
将机器配置添加到集群。键入以下内容将机器配置添加到集群中:
$ oc create -f 99-worker-realtime.yaml
检查实时内核: 每当受影响节点重新引导后,登录到集群,并运行以下命令来确保您配置的节点组中使用实时内核替换了常规内核:
$ 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" 来表示这是一个实时内核。要返回常规内核,请删除
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 集群。
- 以具有管理特权的用户身份登录集群。
流程
创建一个 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
使用 Butane 生成
MachineConfig
对象文件40-worker-custom-journald.yaml
,包含要发送到 worker 节点的配置:$ butane 40-worker-custom-journald.bu -o 40-worker-custom-journald.yaml
将机器配置应用到池:
$ oc apply -f 40-worker-custom-journald.yaml
检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。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
要检查是否应用了更改,您可以登录到 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 或更高版本)。
- 以具有管理特权的用户身份登录集群。
流程
为扩展创建机器配置:创建一个 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
将机器配置添加到集群。键入以下内容将机器配置添加到集群中:
$ oc create -f 80-extensions.yaml
这会将所有 worker 节点设置为安装
usbguard
的 rpm 软件包。检查是否应用了扩展:
$ oc get machineconfig 80-worker-extensions
输出示例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 80-worker-extensions 3.2.0 57s
检查是否应用新机器配置,并且节点是否处于降级状态。它可能需要几分钟时间。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
检查扩展。要检查是否应用了扩展,请运行:
$ 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。
流程
创建 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
运行 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>
通过两种方式之一将配置应用到节点:
-
如果集群还没有运行,在生成清单文件后,将
MachineConfig
对象文件添加到<installation_directory>/openshift
目录中,然后继续创建集群。 如果集群已在运行,请应用该文件:
$ oc apply -f 98-worker-firmware-blob.yaml
已为您创建一个
MachineConfig
对象 YAML 文件,以完成机器的配置。
-
如果集群还没有运行,在生成清单文件后,将
-
如果将来需要更新
MachineConfig
对象,请保存 Butane 配置。
其他资源