3.2. 使用 MachineConfig 对象配置节点
您可以使用本节中的任务创建 MachineConfig
对象,修改 OpenShift Container Platform 节点上运行的文件、systemd 单元文件和其他操作系统功能。有关使用机器配置的更多信息,请参阅有关 更新 SSH 授权密钥、验证镜像签名、启用 SCTP 的内容,并为 OpenShift Container Platform 配置 iSCSI initiatorname。
OpenShift Container Platform 支持 Ignition 规格版本 3.2。您创建的所有新机器配置都应该基于 Ignition 规格版本 3.2。如果要升级 OpenShift Container Platform 集群,任何现有的 Ignition 规格版本 2.x 机器配置将自动转换为规格版本 3.2。
使用 "Configuring chrony time service" 部分作为如何将其他配置文件添加到 OpenShift Container Platform 节点的模型。
3.2.1. 配置 chrony 时间服务
您可以通过修改 chrony .conf 文件的内容,并将这些内容作为机器配置传递给节点,从而设置 chrony
时间服务(chronyd
)使用的时间服务器和相关设置。
流程
创建一个 Butane 配置,包括
chrony.conf
文件的内容。例如,要在 worker 节点上配置 chrony,请创建一个99-worker-chrony.bu
文件。注意如需有关 Butane 的信息,请参阅"使用 Butane 创建机器配置"。
variant: openshift version: 4.8.0 metadata: name: 99-worker-chrony 1 labels: machineconfiguration.openshift.io/role: worker 2 storage: files: - path: /etc/chrony.conf mode: 0644 3 overwrite: true contents: inline: | pool 0.rhel.pool.ntp.org iburst 4 driftfile /var/lib/chrony/drift makestep 1.0 3 rtcsync logdir /var/log/chrony
使用 Butane 生成
MachineConfig
对象文件99-worker-chrony.yaml
,其中包含要交付至节点的配置:$ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml
使用以下两种方式之一应用配置:
-
如果集群还没有运行,在生成清单文件后,将
MachineConfig
对象文件添加到<installation_directory>/openshift
目录中,然后继续创建集群。 如果集群已在运行,请应用该文件:
$ oc apply -f ./99-worker-chrony.yaml
-
如果集群还没有运行,在生成清单文件后,将
其他资源
3.2.2. 为节点添加内核参数
在一些特殊情况下,您可能需要为集群中的一组节点添加内核参数。进行此操作时应小心谨慎,而且您必须先清楚了解所设参数的影响。
不当使用内核参数会导致系统变得无法引导。
您可以设置的内核参数示例包括:
- Enforcing=0:将 Security Enhanced Linux(SELinux)配置为以 permissive 模式运行。在 permissive 模式中,系统会象 enforcing 模式一样加载安全策略,包括标记对象并在日志中记录访问拒绝条目,但它并不会拒绝任何操作。虽然不建议在生产环境系统中使用 permissive 模式,但 permissive 模式会有助于调试。
-
nosmt:在内核中禁用对称多线程 (SMT)。多线程允许每个 CPU 有多个逻辑线程。您可以在多租户环境中考虑使用
nosmt
,以减少潜在的跨线程攻击风险。禁用 SMT 在本质上相当于选择安全性而非性能。
如需内核参数的列表和描述,请参阅 Kernel.org 内核参数。
在以下流程中,您要创建一个用于标识以下内容的 MachineConfig
对象:
- 您要添加内核参数的一组机器。本例中为具有 worker 角色的机器。
- 附加到现有内核参数末尾的内核参数。
- 指示机器配置列表中应用更改的位置的标签。
先决条件
- 具有正常运行的 OpenShift Container Platform 集群的管理特权。
流程
列出 OpenShift Container Platform 集群的现有
MachineConfig
对象,以确定如何标记您的机器配置:$ 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
创建一个用于标识内核参数的
MachineConfig
对象文件(例如05-worker-kernelarg-selinuxpermissive.yaml
)apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: worker1 name: 05-worker-kernelarg-selinuxpermissive2 spec: config: ignition: version: 3.2.0 kernelArguments: - enforcing=03
创建新机器配置:
$ oc create -f 05-worker-kernelarg-selinuxpermissive.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 05-worker-kernelarg-selinuxpermissive 3.2.0 105s 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
检查节点:
$ oc get nodes
输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.21.0 ip-10-0-136-243.ec2.internal Ready master 34m v1.21.0 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.21.0 ip-10-0-142-249.ec2.internal Ready master 34m v1.21.0 ip-10-0-153-11.ec2.internal Ready worker 28m v1.21.0 ip-10-0-153-150.ec2.internal Ready master 34m v1.21.0
您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。
前往其中一个 worker 节点并列出内核命令行参数(主机上的
/proc/cmdline
中),以检查内核参数确实已发挥作用:$ oc debug node/ip-10-0-141-105.ec2.internal
输出示例
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline BOOT_IMAGE=/ostree/rhcos-... console=tty0 console=ttyS0,115200n8 rootflags=defaults,prjquota rw root=UUID=fd0... ostree=/ostree/boot.0/rhcos/16... coreos.oem.id=qemu coreos.oem.id=ec2 ignition.platform.id=ec2 enforcing=0 sh-4.2# exit
您应看到
enforcing=0
参数已添加至其他内核参数。
3.2.3. 在 RHCOS 上启用带有内核参数的多路径
Red Hat Enterprise Linux CoreOS (RHCOS) 支持主磁盘上的多路径,允许对硬件故障进行更强大的弹性,以实现更高的主机可用性。通过机器配置激活多路径,提供安装后支持。
对于在 OpenShift Container Platform 4.8 或更高版本中置备的节点,推荐在安装过程中启用多路径。在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中,您必须在安装时启用多路径。有关在安装过程中启用多路径的更多信息,请参阅在裸机上安装中的 "使用 RHCOS 上内核参数启用多路径"。
在 IBM Z 和 LinuxONE 中,您只能在在安装过程中为它配置集群时启用多路径。如需更多信息,请参阅在 IBM Z 和 LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。
先决条件
- 您有一个正在运行的 OpenShift Container Platform 集群,它使用版本 4.7 或更高版本。
- 您以具有管理特权的用户身份登录集群。
流程
要在 control plane 节点上启用多路径安装后:
创建机器配置文件,如
99-master-kargs-mpath.yaml
,该文件指示集群添加master
标签并标识多路径内核参数,例如:apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "master" name: 99-master-kargs-mpath spec: kernelArguments: - 'rd.multipath=default' - 'root=/dev/disk/by-label/dm-mpath-root'
在 worker 节点上启用多路径安装后:
创建机器配置文件,如
99-worker-kargs-mpath.yaml
,该文件指示集群添加worker
标签并标识多路径内核参数,例如:apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig metadata: labels: machineconfiguration.openshift.io/role: "worker" name: 99-worker-kargs-mpath spec: kernelArguments: - 'rd.multipath=default' - 'root=/dev/disk/by-label/dm-mpath-root'
使用之前创建的 master 或 worker YAML 文件创建新机器配置:
$ oc create -f ./99-worker-kargs-mpath.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-kargs-mpath 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 105s 99-worker-ssh 3.2.0 40m rendered-master-23e785de7587df95a4b517e0647e5ab7 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m rendered-worker-5d596d9293ca3ea80c896a1191735bb1 52dd3ba6a9a527fc3ab42afac8d12b693534c8c9 3.2.0 33m
检查节点:
$ oc get nodes
输出示例
NAME STATUS ROLES AGE VERSION ip-10-0-136-161.ec2.internal Ready worker 28m v1.20.0 ip-10-0-136-243.ec2.internal Ready master 34m v1.20.0 ip-10-0-141-105.ec2.internal Ready,SchedulingDisabled worker 28m v1.20.0 ip-10-0-142-249.ec2.internal Ready master 34m v1.20.0 ip-10-0-153-11.ec2.internal Ready worker 28m v1.20.0 ip-10-0-153-150.ec2.internal Ready master 34m v1.20.0
您可以发现,在应用更改时每个 worker 节点上的调度都会被禁用。
前往其中一个 worker 节点并列出内核命令行参数(主机上的
/proc/cmdline
中),以检查内核参数确实已发挥作用:$ oc debug node/ip-10-0-141-105.ec2.internal
输出示例
Starting pod/ip-10-0-141-105ec2internal-debug ... To use host binaries, run `chroot /host` sh-4.2# cat /host/proc/cmdline ... rd.multipath=default root=/dev/disk/by-label/dm-mpath-root ... sh-4.2# exit
您应看到添加的内核参数。
其他资源
- 有关在安装过程中启用多路径的更多信息,请参阅在 RHCOS 上启用使用内核参数的多路径。
3.2.4. 在节点中添加实时内核
一些 OpenShift Container Platform 工作负载需要高度确定性。虽然 Linux 不是实时操作系统,但 Linux 实时内核包含一个抢占调度程序,它为操作系统提供实时特征。
如果您的 OpenShift Container Platform 工作负载需要这些实时特征,您可以将机器切换到 Linux 实时内核。对于 OpenShift Container Platform 4.8,您可以使用 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.21.0 ip-10-0-146-92.us-east-2.compute.internal Ready worker 101m v1.21.0 ip-10-0-169-2.us-east-2.compute.internal Ready worker 102m v1.21.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
3.2.5. 配置 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.8.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
其他资源
3.2.6. 为 RHCOS 添加扩展
RHCOS 是基于容器的最小 RHEL 操作系统,旨在为所有平台的 OpenShift Container Platform 集群提供一组通用的功能。通常不建议在 RHCOS 系统中添加软件软件包,但 MCO 提供了一个 extensions(扩展)
功能,您可以使用 MCO 为 RHCOS 节点添加一组最小的功能。
目前,提供了以下扩展程序:
-
usbguard:添加
usbguard
扩展可保护 RHCOS 系统不受入侵 USB 设备的攻击。详情请查看 USBGuard。
以下流程描述了如何使用机器配置为 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.18.3
$ 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
3.2.7. 在机器配置清单中载入自定义固件 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.9.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 配置。
其他资源