第 3 章 安装后机器配置任务
有时您需要更改 OpenShift Container Platform 节点上运行的操作系统。这包括更改网络时间服务的设置、添加内核参数或者以特定的方式配置日志。
除了一些特殊功能外,通过创建称为 Machine Config Operator 管理的 MachineConfig
对象,可以对 OpenShift Container Platform 节点上的操作系统进行大多数更改。
本节中的任务介绍了如何使用 Machine Config Operator 的功能在 OpenShift Container Platform 节点上配置操作系统功能。
3.1. 了解 Machine Config Operator
3.1.1. Machine Config Operator
用途
Machine Congig Operator 管理并应用基本操作系统和容器运行时的配置和更新,包括内核和 kubelet 之间的所有配置和更新。
有四个组件:
-
machine-config-server
:为加入集群的新机器提供 Ignition 配置。 -
machine-config-controller
:协调机器升级到MachineConfig
对象定义的配置。提供用来控制单独一组机器升级的选项。 -
machine-config-daemon
:在更新过程中应用新机器配置。验证并验证机器的状态到请求的机器配置。 -
machine-config
:提供安装、首次启动和更新一个机器的完整机器配置源。
project
3.1.2. 机器配置概述
Machine Config Operator(MCO)管理对 systemd、CRI-O 和 Kubelet、内核、Network Manager 和其他系统功能的更新。它还提供了一个 MachineConfig
CRD,它可以在主机上写入配置文件(请参阅 machine-config-operator)。了解 MCO 的作用以及如何与其他组件交互对于对 OpenShift Container Platform 集群进行高级系统级更改至关重要。以下是您应该了解的 MCO、机器配置以及它们的使用方式:
- 机器配置可以对每个系统的操作系统上的文件或服务进行特定的更改,代表一个 OpenShift Container Platform 节点池。
MCO 应用对机器池中的操作系统的更改。所有 OpenShift Container Platform 集群都以 worker 和 control plane 节点(也称为 master 节点)池开头。通过添加更多角色标签,您可以配置自定义节点池。例如,您可以设置一个自定义的 worker 节点池,其中包含应用程序所需的特定硬件功能。但是,本节中的示例着重介绍了对默认池类型的更改。
重要一个节点可以应用多个标签来指示其类型,如
master
或worker
,但只能是一个单一机器配置池的成员。- 在将 OpenShift Container Platform 安装到磁盘前,必须先进行一些机器配置。在大多数情况下,这可以通过创建直接注入 OpenShift Container Platform 安装程序进程中的机器配置来实现,而不必作为安装后机器配置运行。在其他情况下,您可能需要在 OpenShift Container Platform 安装程序启动时传递内核参数时进行裸机安装,以完成诸如设置每个节点的 IP 地址或高级磁盘分区等操作。
- MCO 管理机器配置中设置的项目。MCO 不会覆盖您对系统进行的手动更改,除非明确告知 MCO 管理冲突文件。换句话说,MCO 只提供您请求的特定更新,它不会声明对整个节点的控制。
- 强烈建议手动更改节点。如果您需要退出某个节点并启动一个新节点,则那些直接更改将会丢失。
-
MCO 只支持写入
/etc
和/var
目录里的文件,虽然有些目录的符号链接可以通过符号链接到那些区域之一来写入。例如/opt
和/usr/local
目录。 - Ignition 是 MachineConfig 中使用的配置格式。详情请参阅 Ignition 配置规格 v3.2.0。
- 虽然 Ignition 配置设置可以在 OpenShift Container Platform 安装时直接交付,且以 MCO 提供 Ignition 配置的方式格式化,但 MCO 无法查看这些原始 Ignition 配置是什么。因此,您应该在部署 Ignition 配置前将 Ignition 配置设置嵌套到机器配置中。
-
当由 MCO 管理的文件在 MCO 之外更改时,Machine Config Daemon(MCD)会将该节点设置为
degraded
。然而,它不会覆盖这个错误的文件,它应该继续处于degraded(降级)
状态。 -
使用机器配置的一个关键原因是,当您为 OpenShift Container Platform 集群中的池添加新节点时,会应用它。
machine-api-operator
置备一个新机器, MCO 配置它。
MCO 使用 Ignition 作为配置格式。OpenShift Container Platform 4.6 从 Ignition 配置规格版本 2 移到版本 3。
3.1.2.1. 机器配置可以更改什么?
MCO 可更改的组件类型包括:
config:创建 Ignition 配置对象(请参阅 Ignition 配置规格),以完成修改 OpenShift Container Platform 机器上的文件、systemd 服务和其他功能,包括:
-
Configuration files:创建或覆盖
/var
或/etc
目录中的文件。 - systemd units:在附加设置中丢弃并设置 systemd 服务的状态,或者添加到现有 systemd 服务中。
- 用户和组:在安装后更改 passwd 部分中的 SSH 密钥。
-
Configuration files:创建或覆盖
只有 core
用户才支持通过机器配置更改 SSH 密钥。
- kernelArguments:在 OpenShift Container Platform 节点引导时在内核命令行中添加参数。
-
kernelType:(可选)使用非标准内核而不是标准内核。使用
realtime
来使用 RT 内核(用于 RAN)。这只在选择的平台上被支持。 - fips:启用 FIPS 模式。不应在安装时设置 FIPS,而不是安装后的步骤。
只有在 x86_64
架构中的 OpenShift Container Platform 部署支持 FIPS 验证的/Modules in Process 加密库。
- extensions:通过添加所选预打包软件来扩展 RHCOS 功能。对于这个功能,可用的扩展程序包括 usbguard 和内核模块。
-
Custom resources(用于
ContainerRuntime
和Kubelet
):在机器配置外,MCO 管理两个特殊自定义资源,用于修改 CRI-O 容器运行时设置(ContainerRuntime
CR)和 Kubelet 服务(Kubelet
CR)。
MCO 不是更改 OpenShift Container Platform 节点上的操作系统组件的唯一 Operator。其他 Operator 也可以修改操作系统级别的功能。一个例子是 Node Tuning Operator,它允许您通过 Tuned 守护进程配置集进行节点级别的性能优化。
安装后可以进行的 MCO 配置任务包括在以下步骤中。如需在 OpenShift Container Platform 安装过程中或之前完成的系统配置任务,请参阅 RHCOS 裸机安装的描述。
3.1.2.2. project
详情请参阅 openshift-machine-config-operator GitHub 站点。
3.1.3. 检查机器配置池状态
要查看 Machine Config Operator(MCO)、其子组件及其管理的资源的状态,请使用以下 oc
命令:
流程
要查看集群中为每个机器配置池 (MCP) 中可用 MCO 管理的节点数量,请运行以下命令:
$ oc get machineconfigpool
输出示例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-06c9c4… True False False 3 3 3 0 4h42m worker rendered-worker-f4b64… False True False 3 2 2 0 4h42m
其中:
- UPDATED
-
True
状态表示 MCO 已将当前机器配置应用到该 MCP 中的节点。当前机器配置在oc get mcp
输出中的STATUS
字段中指定。False
状态表示 MCP 中的节点正在更新。 - UPDATING
-
True
状态表示 MCO 正在按照MachineConfigPool
自定义资源中的规定应用到该 MCP 中的至少一个节点。所需的机器配置是新编辑的机器配置。要进行更新的节点可能不适用于调度。False
状态表示 MCP 中的所有节点都已更新。 - DEGRADED
-
True
状态表示 MCO 被禁止将当前或所需的机器配置应用到该 MCP 中的至少一个节点,或者配置失败。降级的节点可能不适用于调度。False
状态表示 MCP 中的所有节点都就绪。 - MACHINECOUNT
- 表示该 MCP 中的机器总数。
- READYMACHINECOUNT
- 指明 MCP 中准备进行调度的机器总数。
- UPDATEDMACHINECOUNT
- 指明 MCP 中有当前机器配置的机器总数。
- DEGRADEDMACHINECOUNT
- 指明 MCP 中标记为 degraded 或 unreconcilable 的机器总数。
在前面的输出中,有三个 control plane (master) 节点和三个 worker 节点。control plane MCP 和关联的节点更新至当前机器配置。worker MCP 中的节点会更新为所需的机器配置。worker MCP 中的两个节点被更新,一个仍在更新,如
UPDATEDMACHINECOUNT
为2
。没有问题,如DEGRADEDMACHINECOUNT
为0
,DEGRADED
为False
。虽然 MCP 中的节点正在更新,但
CONFIG
下列出的机器配置是当前的机器配置,该配置会从这个配置进行更新。更新完成后,列出的机器配置是所需的机器配置,它被更新为 MCP。注意如果节点被封锁,则该节点不包含在
READYMACHINECOUNT
中,但包含在MACHINECOUNT
中。另外,MCP 状态被设置为UPDATING
。因为节点具有当前的机器配置,所以它被计算在UPDATEDMACHINECOUNT
总计:输出示例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-06c9c4… True False False 3 3 3 0 4h42m worker rendered-worker-c1b41a… False True False 3 2 3 0 4h42m
要通过检查
MachineConfigPool
自定义资源来检查 MCP 中的节点状态,请运行以下命令:$ oc describe mcp worker
输出示例
... Degraded Machine Count: 0 Machine Count: 3 Observed Generation: 2 Ready Machine Count: 3 Unavailable Machine Count: 0 Updated Machine Count: 3 Events: <none>
注意如果节点被封锁,则节点不包含在
Ready Machine Count
中。它包含在Unavailable Machine Count
中:输出示例
... Degraded Machine Count: 0 Machine Count: 3 Observed Generation: 2 Ready Machine Count: 2 Unavailable Machine Count: 1 Updated Machine Count: 3
要查看每个现有的
MachineConfig
对象,请运行以下命令:$ oc get machineconfigs
输出示例
NAME GENERATEDBYCONTROLLER IGNITIONVERSION AGE 00-master 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 00-worker 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 01-master-container-runtime 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m 01-master-kubelet 2c9371fbb673b97a6fe8b1c52… 3.2.0 5h18m ... rendered-master-dde... 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m rendered-worker-fde... 2c9371fbb673b97a6fe8b1c52... 3.2.0 5h18m
请注意,列为
rendered
的MachineConfig
对象并不意味着要更改或删除。要查看特定机器配置的内容(本例中为
01-master-kubelet
),请运行以下命令:$ oc describe machineconfigs 01-master-kubelet
命令的输出显示此
MachineConfig
对象同时包含配置文件(cloud.conf
和kubelet.conf
) 和 systemd 服务(Kubernetes Kubelet):输出示例
Name: 01-master-kubelet ... Spec: Config: Ignition: Version: 3.2.0 Storage: Files: Contents: Source: data:, Mode: 420 Overwrite: true Path: /etc/kubernetes/cloud.conf Contents: Source: data:,kind%3A%20KubeletConfiguration%0AapiVersion%3A%20kubelet.config.k8s.io%2Fv1beta1%0Aauthentication%3A%0A%20%20x509%3A%0A%20%20%20%20clientCAFile%3A%20%2Fetc%2Fkubernetes%2Fkubelet-ca.crt%0A%20%20anonymous... Mode: 420 Overwrite: true Path: /etc/kubernetes/kubelet.conf Systemd: Units: Contents: [Unit] Description=Kubernetes Kubelet Wants=rpc-statd.service network-online.target crio.service After=network-online.target crio.service ExecStart=/usr/bin/hyperkube \ kubelet \ --config=/etc/kubernetes/kubelet.conf \ ...
如果应用的机器配置出现问题,您可以随时退出这一更改。例如,如果您运行 oc create -f ./myconfig.yaml
以应用机器配置,您可以运行以下命令来删除该机器配置:
$ oc delete -f ./myconfig.yaml
如果这是唯一的问题,则受影响池中的节点应返回非降级状态。这会导致呈现的配置回滚到其之前更改的状态。
如果在集群中添加自己的机器配置,您可以使用上例中显示的命令检查其状态以及应用到它们的池的相关状态。