7.4. 推荐的节点主机实践

先决条件

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：

   重要

   以特定机器配置池为目标的 kubelet 配置也会影响任何依赖的池。例如，为包含 worker 节点的池创建 kubelet 配置也适用于任何子集池，包括包含基础架构节点的池。要避免这种情况，您必须使用仅包含 worker 节点的选择表达式创建新的机器配置池，并让 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) 和 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=set-max-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

流程

1. 编辑 worker 机器配置池：

   $ oc edit machineconfigpool worker

2. 添加 maxUnavailable 字段并设置值：

   spec:
     maxUnavailable: <node_count>

   重要

   当设置该值时，请考虑无法使用的 worker 节点数量，而不影响在集群中运行的应用程序。

流程

1. 可选：标记节点：

   # oc label node perf-node.example.com cpumanager=true

2. 编辑启用 CPU Manager 的节点的 MachineConfigPool 。在这个示例中，所有 worker 都启用了 CPU Manager：

   # oc edit machineconfigpool worker

3. 为 worker 机器配置池添加标签：

   metadata:
     creationTimestamp: 2020-xx-xxx
     generation: 3
     labels:
       custom-kubelet: cpumanager-enabled

4. 创建 KubeletConfig，cpumanager-kubeletconfig.yaml，自定义资源 (CR) 。请参阅上一步中创建的标签，以便使用新的 kubelet 配置更新正确的节点。请参见 MachineConfigPoolSelector 部分：

   apiVersion: machineconfiguration.openshift.io/v1
   kind: KubeletConfig
   metadata:
     name: cpumanager-enabled
   spec:
     machineConfigPoolSelector:
       matchLabels:
         custom-kubelet: cpumanager-enabled
     kubeletConfig:
        cpuManagerPolicy: static 1
        cpuManagerReconcilePeriod: 5s 2

   1

   指定一个策略：

   • none.这个策略明确启用了现有的默认 CPU 关联性方案，从而不会出现超越调度程序自动进行的关联性。这是默认策略。
   • static。此策略允许保证 pod 中的容器具有整数 CPU 请求。它还限制对节点上的专用 CPU 的访问。如果为 static，则需要使用一个小些 s。

   2

   可选。指定 CPU Manager 协调频率。默认值为 5s。

5. 创建动态 kubelet 配置：

   # oc create -f cpumanager-kubeletconfig.yaml

   这会在 kubelet 配置中添加 CPU Manager 功能，如果需要，Machine Config Operator（MCO）将重启节点。要启用 CPU Manager，则不需要重启。

6. 检查合并的 kubelet 配置：

   # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

   输出示例

          "ownerReferences": [
               {
                   "apiVersion": "machineconfiguration.openshift.io/v1",
                   "kind": "KubeletConfig",
                   "name": "cpumanager-enabled",
                   "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
               }
           ]

7. 检查 worker 是否有更新的 kubelet.conf：

   # oc debug node/perf-node.example.com
   sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

   输出示例

   cpuManagerPolicy: static        1
   cpuManagerReconcilePeriod: 5s   2

   1

   在创建 KubeletConfig CR 时，会定义 cpuManagerPolicy。

   2

   在创建 KubeletConfig CR 时，会定义 cpuManagerReconcilePeriod。

8. 创建请求一个或多个内核的 pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于此 pod 的内核数：

   # cat cpumanager-pod.yaml

   输出示例

   apiVersion: v1
   kind: Pod
   metadata:
     generateName: cpumanager-
   spec:
     containers:
     - name: cpumanager
       image: gcr.io/google_containers/pause-amd64:3.0
       resources:
         requests:
           cpu: 1
           memory: "1G"
         limits:
           cpu: 1
           memory: "1G"
     nodeSelector:
       cpumanager: "true"

9. 创建 pod：

   # oc create -f cpumanager-pod.yaml

10. 确定为您标记的节点调度了 pod：

    # oc describe pod cpumanager

    输出示例

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

11. 确认正确配置了 cgroups。获取 pause 进程的进程 ID（PID）：

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    服务质量（QoS）等级为 Guaranteed 的 pod 被放置到 kubepods.slice 中。其它 QoS 等级的 pod 会位于 kubepods 的子 cgroups 中：

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    输出示例

    cpuset.cpus 1
    tasks 32706

12. 检查任务允许的 CPU 列表：

    # grep ^Cpus_allowed_list /proc/32706/status

    输出示例

     Cpus_allowed_list:    1

13. 确认系统中的另一个 pod（在这个示例中，QoS 等级为 burstable 的 pod）不能在为等级为Guaranteed 的 pod 分配的内核中运行：

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    输出示例

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    这个 VM 有两个 CPU 内核。system-reserved 设置保留 500 millicores，这代表一个内核中的一半被从节点的总容量中减小，以达到 Node Allocatable 的数量。您可以看到 Allocatable CPU 是 1500 毫秒。这意味着您可以运行一个 CPU Manager pod，因为每个 pod 需要一个完整的内核。一个完整的内核等于 1000 毫秒。如果您尝试调度第二个 pod，系统将接受该 pod，但不会调度它：

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s