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

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

3.3.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 数量。

先决条件

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

    1. 查看机器配置池： 

      $ 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 下。

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

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

流程

  1. 查看您可以选择的可用机器配置对象： 

    $ oc get machineconfig

    默认情况下，与 kubelet 相关的配置为 01-master-kubelet 和 01-worker-kubelet。

  2. 检查每个节点的最大 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

  3. 通过创建一个包含 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 分钟。

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

    1. 在 worker 节点上检查 maxPods 值已更改： 

      $ oc describe node <node_name>

    2. 找到 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 对象中设置的值。

  5. 验证 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

3.3.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 设置：

  1. 为 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
    根据需要设置参数。

  2. 创建 ContainerRuntimeConfig CR： 

    $ oc create -f <file_name>.yaml

  3. 验证是否已创建 CR： 

    $ oc get ContainerRuntimeConfig

    输出示例

    NAME           AGE
overlay-size   3m19s

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

    $ oc get machineconfigs | grep containerrun

    输出示例

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

  5. 监控机器配置池，直到所有系统都显示为 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

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

    1. 打开到机器配置池中节点的 oc debug 会话，并运行 chroot /host。 

      $ oc debug node/<node_name>
      sh-4.4# chroot /host

    2. 验证 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"

    3. 验证 '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"

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

流程

  1. 创建配置对象： 

    $ oc apply -f overlaysize.yml

  2. 要将新的 CRI-O 配置应用到 worker 节点，请编辑 worker 机器配置池： 

    $ oc edit machineconfigpool worker

  3. 根据在 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: ""

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

    $ 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

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

    $ 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% /