配置与 MCO 相关的自定义资源 | 机器配置 | OpenShift Container Platform 4.17

创建 KubeletConfig CRD 以编辑 kubelet 参数
创建 ContainerRuntimeConfig CR 以编辑 CRI-O 参数
为使用 CRI-O 的 Overlay 设置默认最大容器根分区大小

除了管理MachineConfig对象外，MCO 还管理两种自定义资源 (CR)：KubeletConfig和ContainerRuntimeConfig。这些 CR 允许您更改影响 kubelet 和 CRI-O 容器运行时服务行为的节点级设置。

创建 KubeletConfig CRD 以编辑 kubelet 参数

kubelet 配置当前序列化为 Ignition 配置，因此可以直接编辑。但是，机器配置控制器 (MCC) 中还添加了一个新的kubelet-config-controller。这允许您使用KubeletConfig自定义资源 (CR) 来编辑 kubelet 参数。

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

请考虑以下指导

编辑现有的KubeletConfig CR 以修改现有设置或添加新设置，而不是为每次更改创建 CR。建议您仅创建 CR 以修改不同的机器配置池，或用于旨在临时的更改，以便您可以恢复更改。
为每个机器配置池创建一个KubeletConfig CR，其中包含您想要为此池进行的所有配置更改。
根据需要，创建多个KubeletConfig CR，每个集群最多 10 个。对于第一个KubeletConfig CR，Machine Config Operator (MCO) 会创建一个附加了kubelet后缀的机器配置。对于每个后续的 CR，控制器都会创建一个另一个带有数字后缀的kubelet机器配置。例如，如果您有一个带有-2后缀的kubelet机器配置，则下一个kubelet机器配置将附加-3。

如果您将 kubelet 或容器运行时配置应用于自定义机器配置池，则machineConfigSelector中的自定义角色必须与自定义机器配置池的名称匹配。

例如，因为以下自定义机器配置池名为infra，所以自定义角色也必须是infra。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
  name: infra
spec:
  machineConfigSelector:
    matchExpressions:
      - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,infra]}
# ...

如果您想删除机器配置，请按相反的顺序删除它们，以避免超过限制。例如，您应先删除kubelet-3机器配置，然后再删除kubelet-2机器配置。

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

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

以下过程是一个示例，展示如何在工作节点上配置每个节点的最大 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 配置的自定义资源文件，设置工作节点上的每个节点的最大 Pod 数。

针对特定机器配置池的 Kubelet 配置也会影响任何依赖池。例如，为包含工作节点的池创建 kubelet 配置也将应用于任何子集池，包括包含基础设施节点的池。为避免这种情况，您必须创建一个新的机器配置池，其选择表达式仅包含工作节点，并使您的 kubelet 配置以该新池为目标。

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) 和突发值。如果每个节点上运行的 Pod 数量有限，则默认值（kubeAPIQPS 为 50，kubeAPIBurst 为 100）就足够了。如果节点上有足够的 CPU 和内存资源，建议更新 kubelet QPS 和突发速率。

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>

使用标签更新工作节点的机器配置池。

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

创建KubeletConfig对象。
```
$ oc create -f change-maxPods-cr.yaml
```
验证KubeletConfig对象是否已创建。
```
$ oc get kubeletconfig
```
示例输出
```
NAME                AGE
set-max-pods        15m
```
根据集群中工作节点的数量，等待工作节点逐个重启。对于具有 3 个工作节点的集群，这可能需要大约 10 到 15 分钟。

验证更改是否已应用于节点。

在一个工作节点上检查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

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

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

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

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

PID 限制：预计在ContainerRuntimeConfig中设置 PID 限制将被弃用。如果需要 PID 限制，建议改用KubeletConfig CR 中的podPidsLimit字段。默认podPidsLimit值为4096，默认pids_limit值为0。如果podPidsLimit小于pids_limit，则有效容器 PID 限制由podPidsLimit中设置的值定义。

CRI-O 标志应用于容器的 cgroup，而 Kubelet 标志设置在 Pod 的 cgroup 上。请相应地调整 PID 限制。
日志级别：logLevel参数设置 CRI-O log_level参数，即日志消息的详细程度。默认为info（log_level = info）。其他选项包括fatal、panic、error、warn、debug和trace。
覆盖大小：overlaySize参数设置 CRI-O Overlay 存储驱动程序的size参数，即容器映像的最大大小。
最大日志大小：预计在ContainerRuntimeConfig中设置最大日志大小将被弃用。如果需要最大日志大小，建议改用KubeletConfig CR 中的containerLogMaxSize字段。
容器运行时：defaultRuntime参数将容器运行时设置为runc或crun。默认为runc。

每个机器配置池应该只有一个ContainerRuntimeConfig CR，其中包含您想要为此池进行的所有配置更改。如果您将相同的内容应用于所有池，则所有池只需要一个ContainerRuntimeConfig CR。

您应该编辑现有的ContainerRuntimeConfig CR 来修改现有设置或添加新设置，而不是为每次更改创建一个新的 CR。建议仅当要修改不同的机器配置池或进行临时更改以便可以还原更改时，才创建新的ContainerRuntimeConfig CR。

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

如果您想删除机器配置，则应按相反的顺序删除它们，以避免超过限制。例如，您应先删除containerruntime-3机器配置，然后再删除containerruntime-2机器配置。

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

显示多个ContainerRuntimeConfig CR 的示例

$ oc get ctrcfg

示例输出

NAME         AGE
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
...

以下示例将log_level字段设置为debug并将覆盖大小设置为 8 GB。

ContainerRuntimeConfig CR 示例

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

1	指定机器配置池标签。对于容器运行时配置，角色必须与关联的机器配置池名称匹配。
2	可选：指定日志消息的详细程度。
3	可选：指定容器镜像的最大大小。
4	可选：指定要部署到新容器的容器运行时。默认值为`runc`。

步骤

使用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)
   logLevel: debug
   overlaySize: 8G

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

监视机器配置池，直到所有配置都显示为就绪状态。

$ 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 | grep 'log_level'

示例输出

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"

设置CRI-O叠加层的默认最大容器根分区大小

每个容器的根分区显示底层主机的所有可用磁盘空间。请遵循以下指南来设置所有容器根磁盘的最大分区大小。

要配置最大叠加层大小以及其他CRI-O选项（如日志级别），您可以创建以下ContainerRuntimeConfig自定义资源定义 (CRD)

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

步骤

创建配置对象
```
$ oc apply -f overlaysize.yml
```
要将新的CRI-O配置应用于您的工作节点，请编辑工作机器配置池
```
$ 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

工作节点将显示UPDATING为True，以及机器数量、已更新数量和其他详细信息

示例输出

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

完成后，工作节点将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

查看工作机器，您会看到新的8 GB最大大小配置已应用于所有工作节点

示例输出

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"

查看容器内部，您会看到根分区现在为8 GB

示例输出

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