支持控制台（Console）开发人员开始试用联系人

5.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。

在某些情况下，节点上的配置与当前应用的机器配置指定不完全匹配。这个状态被称为 配置偏移。Machine Config Daemon(MCD)定期检查节点是否有配置偏移。如果 MCD 检测到配置偏移，MCO 会将节点标记为 降级(degraded)，直到管理员更正节点配置。降级的节点在线且可操作，但无法更新。有关配置偏移的更多信息，请参阅了解配置偏移检测。

提示

使用 "Configuring chrony time service" 部分作为如何将其他配置文件添加到 OpenShift Container Platform 节点的模型。

5.2.1. 配置 chrony 时间服务

您可以通过修改 chrony .conf 文件的内容，并将这些内容作为机器配置传递给节点，从而设置 chrony 时间服务(chronyd)使用的时间服务器和相关设置。

流程

  1. 创建一个 Butane 配置，包括 chrony.conf 文件的内容。例如，要在 worker 节点上配置 chrony，请创建一个 99-worker-chrony.bu 文件。

    注意

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

    variant: openshift
version: 4.15.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
    1 2
    在 control plane 节点上，在这两个位置中将 master 替换为 worker。
    3
    为机器配置文件的 mode 字段指定数值模式。在创建文件并应用更改后，模式 将转换为十进制值。您可以使用 oc get mc <mc-name> -o yaml 命令来检查 YAML 文件。
    4
    指定任何有效的、可访问的时间源，如 DHCP 服务器提供的源。或者，您可以指定以下 NTP 服务器：1.rhel.pool.ntp.org, 2.rhel.pool.ntp.org, 或 3.rhel.pool.ntp.org。

  2. 使用 Butane 生成 MachineConfig 对象文件 99-worker-chrony.yaml，其中包含要交付至节点的配置： 

    $ butane 99-worker-chrony.bu -o 99-worker-chrony.yaml

  3. 使用以下两种方式之一应用配置：

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

    • 如果集群已在运行，请应用该文件： 

      $ oc apply -f ./99-worker-chrony.yaml

其他资源

5.2.2. 禁用 chrony 时间服务

您可以使用 MachineConfig 自定义资源 (CR) 为具有特定角色的节点禁用 chrony 时间服务 (chronyd)。

先决条件

  • 安装 OpenShift CLI（oc）。
  • 以具有 cluster-admin 特权的用户身份登录。

流程

  1. 创建 MachineConfig CR，为指定节点角色禁用 chronyd。

    1. 在 disable-chronyd.yaml 文件中保存以下 YAML： 

      apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: <node_role> 1
  name: disable-chronyd
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=NTP client/server
            Documentation=man:chronyd(8) man:chrony.conf(5)
            After=ntpdate.service sntp.service ntpd.service
            Conflicts=ntpd.service systemd-timesyncd.service
            ConditionCapability=CAP_SYS_TIME
            [Service]
            Type=forking
            PIDFile=/run/chrony/chronyd.pid
            EnvironmentFile=-/etc/sysconfig/chronyd
            ExecStart=/usr/sbin/chronyd $OPTIONS
            ExecStartPost=/usr/libexec/chrony-helper update-daemon
            PrivateTmp=yes
            ProtectHome=yes
            ProtectSystem=full
            [Install]
            WantedBy=multi-user.target
          enabled: false
          name: "chronyd.service"
      1
      要禁用 chronyd 的节点角色，如 master。

    2. 运行以下命令来创建 MachineConfig CR： 

      $ oc create -f disable-chronyd.yaml

5.2.3. 为节点添加内核参数

在一些特殊情况下，您可能需要为集群中的一组节点添加内核参数。进行此操作时应小心谨慎，而且您必须先清楚了解所设参数的影响。

警告

不当使用内核参数会导致系统变得无法引导。

您可以设置的内核参数示例包括：

  • nosmt：在内核中禁用对称多线程 (SMT)。多线程允许每个 CPU 有多个逻辑线程。您可以在多租户环境中考虑使用 nosmt，以减少潜在的跨线程攻击风险。禁用 SMT 在本质上相当于选择安全性而非性能。
  • systemd.unified_cgroup_hierarchy：启用 Linux 控制组版本 2 (cgroup v2)。cgroup v2 是内核控制组的下一个版本，它包括了多个改进。

  • Enforcing=0：将 Security Enhanced Linux（SELinux）配置为以 permissive 模式运行。在 permissive 模式中，系统会象 enforcing 模式一样加载安全策略，包括标记对象并在日志中记录访问拒绝条目，但它并不会拒绝任何操作。虽然不建议在生产环境系统中使用 permissive 模式，但 permissive 模式会有助于调试。

    警告

    不支持在生产环境中禁用 RHCOS 上的 SELinux。在节点上禁用 SELinux 后，必须在生产集群中重新设置前重新置备它。

如需内核参数的列表和描述，请参阅 Kernel.org 内核参数。

在以下流程中，您要创建一个用于标识以下内容的 MachineConfig 对象：

  • 您要添加内核参数的一组机器。本例中为具有 worker 角色的机器。
  • 附加到现有内核参数末尾的内核参数。
  • 指示机器配置列表中应用更改的位置的标签。

先决条件

  • 具有正常运行的 OpenShift Container Platform 集群的管理特权。

流程

  1. 列出 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

  2. 创建一个用于标识内核参数的 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:
  kernelArguments:
    - enforcing=03
    1
    仅将新内核参数应用到 worker 节点。
    2
    用于标识它插入到机器配置中的什么位置（05）以及发挥什么作用（添加一个内核参数来配置 SELinux permissive 模式）。
    3
    将确切的内核参数标识为 enforcing=0。

  3. 创建新机器配置： 

    $ oc create -f 05-worker-kernelarg-selinuxpermissive.yaml

  4. 检查机器配置以查看是否添加了新配置： 

    $ 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

  5. 检查节点： 

    $ oc get nodes

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.28.5
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.28.5
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.28.5
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.28.5
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.28.5
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.28.5

    您可以发现，在应用更改时每个 worker 节点上的调度都会被禁用。

  6. 前往其中一个 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 参数已添加至其他内核参数。

5.2.4. 在 RHCOS 上启用带有内核参数的多路径

Red Hat Enterprise Linux CoreOS (RHCOS) 支持主磁盘上的多路径，允许对硬件故障进行更强大的弹性，以实现更高的主机可用性。通过机器配置激活多路径，提供安装后支持。

重要

对于在 OpenShift Container Platform 4.8 或更高版本中置备的节点，推荐在安装过程中启用多路径。在任何 I/O 到未优化路径会导致 I/O 系统错误的设置中，您必须在安装时启用多路径。有关在安装过程中启用多路径的更多信息，请参阅在裸机上安装中的 "使用 RHCOS 上内核参数启用多路径"。

重要

在 IBM Z® 和 IBM® LinuxONE 中，您只能在在安装过程中为它配置集群时启用多路径。如需更多信息，请参阅在 IBM Z® 和 IBM® LinuxONE 上安装使用 z/VM 的集群"安装 RHCOS 并启动 OpenShift Container Platform bootstrap 过程"。

重要

当在配置了多路径的 IBM Power® 上的带有 "vSCSI" 存储的单个 VIOS 主机中安装或配置了 OpenShift Container Platform 4.15 集群作为安装后任务时，启用了多路径的 CoreOS 节点无法引导。此行为是正常的，因为只有一个路径可用于节点。

先决条件

  • 您有一个正在运行的 OpenShift Container Platform 集群，它使用版本 4.7 或更高版本。
  • 以具有管理特权的用户身份登录集群。
  • 您已确认为多路径启用了磁盘。只有通过 HBA 适配器连接到 SAN 的主机上才支持多路径。

流程

  1. 要在 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'

  2. 在 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'

  3. 使用之前创建的 master 或 worker YAML 文件创建新机器配置： 

    $ oc create -f ./99-worker-kargs-mpath.yaml

  4. 检查机器配置以查看是否添加了新配置： 

    $ 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

  5. 检查节点： 

    $ oc get nodes

    输出示例

    NAME                           STATUS                     ROLES    AGE   VERSION
ip-10-0-136-161.ec2.internal   Ready                      worker   28m   v1.28.5
ip-10-0-136-243.ec2.internal   Ready                      master   34m   v1.28.5
ip-10-0-141-105.ec2.internal   Ready,SchedulingDisabled   worker   28m   v1.28.5
ip-10-0-142-249.ec2.internal   Ready                      master   34m   v1.28.5
ip-10-0-153-11.ec2.internal    Ready                      worker   28m   v1.28.5
ip-10-0-153-150.ec2.internal   Ready                      master   34m   v1.28.5

    您可以发现，在应用更改时每个 worker 节点上的调度都会被禁用。

  6. 前往其中一个 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

    您应看到添加的内核参数。

其他资源

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

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

如果您的 OpenShift Container Platform 工作负载需要这些实时特征，您可以将机器切换到 Linux 实时内核。对于 OpenShift Container Platform，4.15 您可以使用 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.28.5
ip-10-0-146-92.us-east-2.compute.internal   Ready   worker   101m  v1.28.5
ip-10-0-169-2.us-east-2.compute.internal    Ready   worker   102m  v1.28.5

    $ 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.2.6. 配置 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.15.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.2.7. 为 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.28.5

    $ 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.2.8. 在机器配置清单中载入自定义固件 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.15.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 配置。

其他资源

5.2.9. 更改节点访问的核心用户密码

默认情况下，Red Hat Enterprise Linux CoreOS (RHCOS) 在集群的节点上创建一个名为 core 的用户。您可以使用 core 用户通过云供应商串口控制台或裸机基板管理控制器管理器 (BMC) 访问节点。例如，如果节点停机且您无法使用 SSH 或 oc debug node 命令访问该节点，这非常有用。但是，默认情况下，此用户没有密码，因此您无法在不创建密码的情况下登录。

您可以使用机器配置为 core 用户创建密码。Machine Config Operator (MCO) 分配密码并将密码注入 /etc/shadow 文件中，允许您使用 core 用户登录。MCO 不会检查密码哈希。因此，如果密码出现问题，MCO 无法报告。

注意
  • 密码只能通过云供应商串口控制台或 BMC 正常工作。它不适用于 SSH。
  • 如果您有包含 /etc/shadow 文件或 systemd 单元的机器配置，则优先于密码哈希。

您可以通过编辑用于创建密码的机器配置来更改密码。另外，您可以通过删除机器配置来删除密码。删除机器配置不会删除用户帐户。

流程

  1. 使用您的操作系统支持的工具，创建一个哈希密码。例如，通过运行以下命令，使用 mkpasswd 创建哈希密码： 

    $ mkpasswd -m SHA-512 testpass

    输出示例

    $ $6$CBZwA6s6AVFOtiZe$aUKDWpthhJEyR3nnhM02NM1sKCpHn9XN.NPrJNQ3HYewioaorpwL3mKGLxvW0AOb4pJxqoqP4nFX77y0p00.8.

  2. 创建包含 core 用户名和散列密码的机器配置文件： 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: set-core-user-password
spec:
  config:
    ignition:
      version: 3.2.0
    passwd:
      users:
      - name: core 1
        passwordHash: <password> 2
    1
    这必须是 core。
    2
    与 core 帐户一起使用的散列密码。

  3. 运行以下命令来创建机器配置： 

    $ oc create -f <file-name>.yaml

    节点不会重启，并在几分钟内可用。您可以使用 oc get mcp 来监控要更新的机器配置池，如下例所示： 

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
master   rendered-master-d686a3ffc8fdec47280afec446fce8dd   True      False      False      3              3                   3                     0                      64m
worker   rendered-worker-4605605a5b1f9de1d061e9d350f251e5   False     True       False      3              0                   0                     0                      64m

验证

  1. 节点返回 UPDATED=True 状态后，运行以下命令为节点启动 debug 会话： 

    $ oc debug node/<node_name>

  2. 运行以下命令，将 /host 设置为 debug shell 中的根目录： 

    sh-4.4# chroot /host

  3. 检查 /etc/shadow 文件的内容：

    输出示例

    ...
core:$6$2sE/010goDuRSxxv$o18K52wor.wIwZp:19418:0:99999:7:::
...

    哈希密码分配给 core 用户。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.