4.4. 配置 MCO 相关的自定义资源

除了管理 MachineConfig 对象外，MCO 管理两个自定义资源（CR）：KubeletConfig 和 ContainerRuntimeConfig。这些 CR 可让您更改节点级别的设置，这会影响到 Kubelet 和 CRI-O 容器运行时服务的行为。

4.4.1. 创建 KubeletConfig CRD 来编辑 kubelet 参数

kubelet 配置目前被序列化为 Ignition 配置，因此可以直接编辑。但是，在 Machine Config Controller (MCC) 中同时添加了新的 kubelet-config-controller 。这可让您使用 KubeletConfig 自定义资源 (CR) 来编辑 kubelet 参数。

注意

因为 kubeletConfig 对象中的字段直接从上游 Kubernetes 传递给 kubelet，kubelet 会直接验证这些值。kubeletConfig 对象中的无效值可能会导致集群节点不可用。有关有效值，请参阅 Kubernetes 文档。

请考虑以下指导：

为每个机器配置池创建一个 KubeletConfig CR，带有该池需要更改的所有配置。如果要将相同的内容应用到所有池，则所有池仅需要一个 KubeletConfig CR。
编辑现有的 KubeletConfig CR 以修改现有设置或添加新设置，而不是为每个更改创建一个 CR。建议您仅创建一个 CR 来修改不同的机器配置池，或用于临时更改，以便您可以恢复更改。
根据需要，创建多个 KubeletConfig CR，每个集群限制为 10。对于第一个 KubeletConfig CR，Machine Config Operator (MCO) 会创建一个机器配置，并附带 kubelet。对于每个后续 CR，控制器会创建另一个带有数字后缀的 kubelet 机器配置。例如，如果您有一个带有 -2 后缀的 kubelet 机器配置，则下一个 kubelet 机器配置会附加 -3。

如果要删除机器配置，以相反的顺序删除它们，以避免超过限制。例如，在删除 kubelet-2 机器配置前删除 kubelet-3 机器配置。

注意

如果您有一个带有 kubelet-9 后缀的机器配置，并且创建了另一个 KubeletConfig CR，则不会创建新的机器配置，即使少于 10 个 kubelet 机器配置。

KubeletConfig CR 示例

$ oc get kubeletconfig

NAME                AGE
set-max-pods        15m

显示 KubeletConfig 机器配置示例

$ oc get mc | grep kubelet

...
99-worker-generated-kubelet-1                  b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
...

以下流程演示了如何配置 worker 节点上的每个节点的最大 pod 数量。

先决条件

为您要配置的节点类型获取与静态 MachineConfigPool CR 关联的标签。执行以下步骤之一：

查看机器配置池：

$ oc describe machineconfigpool <name>

例如：

$ oc describe machineconfigpool worker

输出示例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: 2019-02-08T14:52:39Z
  generation: 1
  labels:
    custom-kubelet: set-max-pods 1

1: 如果添加了标签，它会出现在 labels 下。

如果标签不存在，则添加一个键/值对：

$ oc label machineconfigpool worker custom-kubelet=set-max-pods

流程

查看您可以选择的可用机器配置对象：
```
$ oc get machineconfig
```
默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

检查每个节点的最大 pod 的当前值：

$ oc describe node <node_name>

例如：

$ oc describe node ci-ln-5grqprb-f76d1-ncnqq-worker-a-mdv94

在 Allocatable 小节中找到 value: pods: <value>：

输出示例

Allocatable:
 attachable-volumes-aws-ebs:  25
 cpu:                         3500m
 hugepages-1Gi:               0
 hugepages-2Mi:               0
 memory:                      15341844Ki
 pods:                        250

通过创建一个包含 kubelet 配置的自定义资源文件，设置 worker 节点上的每个节点的最大 pod：
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods 1
  kubeletConfig:
    maxPods: 500 2
```
1
输入机器配置池中的标签。
2
添加 kubelet 配置。在本例中，使用 maxPods 设置每个节点的最大 pod。
注意
kubelet 与 API 服务器进行交互的频率取决于每秒的查询数量 (QPS) 和 burst 值。如果每个节点上运行的 pod 数量有限，使用默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就可以。如果节点上有足够 CPU 和内存资源，则建议更新 kubelet QPS 和 burst 速率。
```
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: set-max-pods
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
  kubeletConfig:
    maxPods: <pod_count>
    kubeAPIBurst: <burst_rate>
    kubeAPIQPS: <QPS>
```
1. 为带有标签的 worker 更新机器配置池：
```
$ oc label machineconfigpool worker custom-kubelet=large-pods
```
2. 创建 KubeletConfig 对象：
```
$ oc create -f change-maxPods-cr.yaml
```
3. 验证 KubeletConfig 对象是否已创建：
```
$ oc get kubeletconfig
```
  输出示例
```
NAME                AGE
set-max-pods        15m
```
  根据集群中的 worker 节点数量，等待每个 worker 节点被逐个重启。对于有 3 个 worker 节点的集群，这个过程可能需要大约 10 到 15 分钟。

验证更改是否已应用到节点：

在 worker 节点上检查 maxPods 值已更改：
```
$ oc describe node <node_name>
```

找到 Allocatable 小节：

 ...
Allocatable:
  attachable-volumes-gce-pd:  127
  cpu:                        3500m
  ephemeral-storage:          123201474766
  hugepages-1Gi:              0
  hugepages-2Mi:              0
  memory:                     14225400Ki
  pods:                       500 1
 ...

1: 在本例中，pods 参数应报告您在 KubeletConfig 对象中设置的值。

验证 KubeletConfig 对象中的更改：

$ oc get kubeletconfigs set-max-pods -o yaml

这应该显示 True 状态和 type:Success，如下例所示：

spec:
  kubeletConfig:
    maxPods: 500
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: set-max-pods
status:
  conditions:
  - lastTransitionTime: "2021-06-30T17:04:07Z"
    message: Success
    status: "True"
    type: Success

4.4.2. 创建 ContainerRuntimeConfig CR 以编辑 CRI-O 参数

您可以为与特定机器配置池（MCP）关联的节点更改与 OpenShift Container Platform CRI-O 运行时关联的一些设置。通过使用 ContainerRuntimeConfig 自定义资源（CR），您可以设置配置值并添加一个标签以匹配 MCP。然后，MCO 会使用更新的值重建关联节点上的 crio.conf 和 storage.conf 配置文件。

注意

要使用 ContainerRuntimeConfig CR 恢复实现的更改，您必须删除 CR。从机器配置池中删除标签不会恢复更改。

您可以使用 ContainerRuntimeConfig CR 修改以下设置：

PIDs limit：pidsLimit 参数设置 CRI-O pids_limit 参数，这是容器中允许的最大进程数。默认为 1024（pids_limit = 1024）。
日志级别: logLevel 参数设置 CRI-O log_level 参数，即日志消息的详细程度。默认为 info (log_level = info)。其他选项包括 fatal、panic、error、warn、debug 和 trace。
Overlay 大小：overlaySize 参数设置 CRI-O Overlay 存储驱动程序 size 参数，这是容器镜像的最大大小。
最大日志大小：logSizeMax 参数设置 CRI-O log_size_max 参数，这是容器日志文件允许的最大值。默认为没有限制（log_size_max = -1）。如果设置为正数，则必须至少小于 ConMon 读取缓冲的 8192。conMon 是一个监控单个容器管理器（如 Podman 或 CRI-O）与 OCI 运行时（如 runc 或 crun）之间的通信的程序。

您应该为每个机器配置池有一个ContainerRuntimeConfig CR，并为该池分配所有配置更改。如果要将相同的内容应用到所有池，则所有池只需要 oneContainerRuntimeConfig CR。

您应该编辑现有的 ContainerRuntimeConfig CR，以修改现有设置或添加新设置，而不是为每个更改创建新 CR。建议您只创建一个新的 ContainerRuntimeConfig CR 来修改不同的机器配置池，或者用于临时的更改，以便您可以恢复更改。

您可以根据需要创建多个 ContainerRuntimeConfig CR，每个集群的限制为 10。对于第一个 ContainerRuntimeConfig CR，MCO 会创建一个机器配置并附加 containerruntime。对于每个后续 CR，控制器会创建一个带有数字后缀的新 containerruntime 机器配置。例如，如果您有一个带有 -2 后缀的 containerruntime 机器配置，则下一个 containerruntime 机器配置会附加 -3。

如果要删除机器配置，应该以相反的顺序删除它们，以避免超过限制。例如，您应该在删除 containerruntime-2 机器配置前删除 containerruntime-3 机器配置。

注意

如果您的机器配置带有 containerruntime-9 后缀，并且创建了 anotherContainerRuntimeConfig CR，则不会创建新的机器配置，即使少于 10 个 containerruntime 机器配置。

显示多个 ContainerRuntimeConfig CR 示例

$ oc get ctrcfg

输出示例

NAME         AGE
ctr-pid      24m
ctr-overlay  15m
ctr-level    5m45s

显示多个 containerruntime 机器配置示例

$ oc get mc | grep container

输出示例

...
01-master-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
01-worker-container-runtime                        b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             57m
...
99-worker-generated-containerruntime               b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             26m
99-worker-generated-containerruntime-1             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             17m
99-worker-generated-containerruntime-2             b5c5119de007945b6fe6fb215db3b8e2ceb12511   3.2.0             7m26s
...

以下示例将 pids_limit 增加到 2048，将 log_level 设置为 debug，将覆盖大小设置为 8 GB，并将 log_size_max 设置为无限：

ContainerRuntimeConfig CR 示例

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig:
   pidsLimit: 2048 2
   logLevel: debug 3
   overlaySize: 8G 4
   logSizeMax: "-1" 5

1: 指定机器配置池标签。
2: 可选：指定容器中允许的最大进程数。
3: 可选：指定日志消息的详细程度。
4: 可选：指定容器镜像的最大大小。
5: 可选：指定容器日志文件允许的最大大小。如果设置为正数，则必须至少为 8192。

流程

使用 ContainerRuntimeConfig CR 更改 CRI-O 设置：

为 ContainerRuntimeConfig CR 创建 YAML 文件：

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     pools.operator.machineconfiguration.openshift.io/worker: '' 1
 containerRuntimeConfig: 2
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G
   logSizeMax: "-1"

1: 为您要修改的机器配置池指定一个标签。
2: 根据需要设置参数。

创建 ContainerRuntimeConfig CR：
```
$ oc create -f <file_name>.yaml
```

验证是否已创建 CR：

$ oc get ContainerRuntimeConfig

输出示例

NAME           AGE
overlay-size   3m19s

检查是否创建了新的 containerruntime 机器配置：

$ oc get machineconfigs | grep containerrun

输出示例

99-worker-generated-containerruntime   2c9371fbb673b97a6fe8b1c52691999ed3a1bfc2  3.2.0  31s

监控机器配置池，直到所有系统都显示为 ready 状态：

$ oc get mcp worker

输出示例

NAME    CONFIG               UPDATED  UPDATING  DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT  DEGRADEDMACHINECOUNT  AGE
worker  rendered-worker-169  False    True      False     3             1                  1                    0                     9h

验证设置是否在 CRI-O 中应用：

打开到机器配置池中节点的 oc debug 会话，并运行 chroot /host。
```
$ oc debug node/<node_name>
```
```
sh-4.4# chroot /host
```

验证 crio.conf 文件中的更改：

sh-4.4# crio config | egrep 'log_level|pids_limit|log_size_max'

输出示例

pids_limit = 2048
log_size_max = -1
log_level = "debug"

验证 'storage.conf' 文件中的更改：

sh-4.4# head -n 7 /etc/containers/storage.conf

输出示例

[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

4.4.3. 使用 CRI-O 为 Overlay 设置默认的最大容器根分区大小

每个容器的根分区显示底层主机的所有可用磁盘空间。按照以下说明，为所有容器的 root 磁盘设置最大分区大小。

要配置最大 Overlay 大小，以及其他 CRI-O 选项，如日志级别和 PID 限制，您可以创建以下 ContainerRuntimeConfig 自定义资源定义（CRD）：

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
 name: overlay-size
spec:
 machineConfigPoolSelector:
   matchLabels:
     custom-crio: overlay-size
 containerRuntimeConfig:
   pidsLimit: 2048
   logLevel: debug
   overlaySize: 8G

流程

创建配置对象：
```
$ oc apply -f overlaysize.yml
```
要将新的 CRI-O 配置应用到 worker 节点，请编辑 worker 机器配置池：
```
$ oc edit machineconfigpool worker
```

根据在 ContainerRuntimeConfig CRD 中设置的 matchLabels 名称添加 custom-crio 标签：

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  creationTimestamp: "2020-07-09T15:46:34Z"
  generation: 3
  labels:
    custom-crio: overlay-size
    machineconfiguration.openshift.io/mco-built-in: ""

保存更改，然后查看机器配置：

$ oc get machineconfigs

新的 99-worker-generated-containerruntime 和 rendered-worker-xyz 对象被创建：

输出示例

99-worker-generated-containerruntime  4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m42s
rendered-worker-xyz                   4173030d89fbf4a7a0976d1665491a4d9a6e54f1   3.2.0             7m36s

创建这些对象后，监控机器配置池以了解要应用的更改：

$ oc get mcp worker

worker 节点将 UPDATING 显示为 True，以及机器数量、更新的数字和其他详情：

输出示例

NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker rendered-worker-xyz False True False     3             2                   2                    0                      20h

完成后，worker 节点会从 UPDATING 转换回 False，UPDATEDMACHINECOUNT 数与 MACHINECOUNT 数匹配：

输出示例

NAME   CONFIG              UPDATED   UPDATING   DEGRADED  MACHINECOUNT  READYMACHINECOUNT  UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
worker   rendered-worker-xyz   True      False      False      3         3            3             0           20h

查看 worker 机器，您会看到新的 8 GB 最大大小配置适用于所有 worker：

输出示例

head -n 7 /etc/containers/storage.conf
[storage]
  driver = "overlay"
  runroot = "/var/run/containers/storage"
  graphroot = "/var/lib/containers/storage"
  [storage.options]
    additionalimagestores = []
    size = "8G"

在容器内，您会看到 root 分区现在为 8 GB：

输出示例

~ $ df -h
Filesystem                Size      Used Available Use% Mounted on
overlay                   8.0G      8.0K      8.0G   0% /

4.4. 配置 MCO 相关的自定义资源

4.4.1. 创建 KubeletConfig CRD 来编辑 kubelet 参数

4.4.2. 创建 ContainerRuntimeConfig CR 以编辑 CRI-O 参数

4.4.3. 使用 CRI-O 为 Overlay 设置默认的最大容器根分区大小

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links