第 6 章 使用 CPU Manager 和拓扑管理器
CPU Manager 管理 CPU 组并限制特定 CPU 的负载。
CPU Manager 对于有以下属性的负载有用：
- 需要尽可能多的 CPU 时间。
- 对处理器缓存丢失非常敏感。
- 低延迟网络应用程序。
- 需要与其他进程协调，并从共享一个处理器缓存中受益。
拓扑管理器（Topology Manager）从 CPU Manager、设备管理器和其他 Hint 提供者收集提示信息，以匹配相同非统一 内存访问（NUMA）节点上的所有 QoS 类的 pod 资源（如 CPU、SR-IOV VF 和其他设备资源）。
拓扑管理器使用收集来的提示信息中获得的拓扑信息，根据配置的 Topology Manager 策略以及请求的 Pod 资源，决定节点是否被节点接受或拒绝。
拓扑管理器对希望使用硬件加速器来支持对工作延迟有极高要求的操作及高吞吐并发计算的负载很有用。
要使用拓扑管理器，您必须使用 静态 策略配置 CPU Manager。
6.1. 设置 CPU Manager
要配置 CPU Manager，请创建一个 KubeletConfig 自定义资源 (CR) 并将其应用到所需的一组节点。
流程
运行以下命令来标记节点：
# oc label node perf-node.example.com cpumanager=true
要为所有计算节点启用 CPU Manager，请运行以下命令来编辑 CR：
# oc edit machineconfigpool worker
将
custom-kubelet: cpumanager-enabled标签添加到metadata.labels部分。metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled创建
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运行以下命令来创建动态 kubelet 配置：
# oc create -f cpumanager-kubeletconfig.yaml
这会在 kubelet 配置中添加 CPU Manager 功能，如果需要，Machine Config Operator（MCO）将重启节点。要启用 CPU Manager，则不需要重启。
运行以下命令，检查合并的 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" } ]运行以下命令，检查更新的
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
运行以下命令来创建项目：
$ oc new-project <project_name>
创建请求一个或多个内核的 pod。限制和请求都必须将其 CPU 值设置为一个整数。这是专用于此 pod 的内核数：
# cat cpumanager-pod.yaml
输出示例
apiVersion: v1 kind: Pod metadata: generateName: cpumanager- spec: securityContext: runAsNonRoot: true seccompProfile: type: RuntimeDefault containers: - name: cpumanager image: gcr.io/google_containers/pause:3.2 resources: requests: cpu: 1 memory: "1G" limits: cpu: 1 memory: "1G" securityContext: allowPrivilegeEscalation: false capabilities: drop: [ALL] nodeSelector: cpumanager: "true"创建 pod：
# oc create -f cpumanager-pod.yaml
验证
运行以下命令，验证 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运行以下命令，验证 CPU 是否已完全分配给 pod：
# oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
输出示例
NAMESPACE NAME CPU Requests CPU Limits Memory Requests Memory Limits Age cpuman cpumanager-mlrrz 1 (28%) 1 (28%) 1G (13%) 1G (13%) 27m
确认正确配置了
cgroups。运行以下命令，获取cluster进程的进程 ID (PID)：# oc debug node/perf-node.example.com
sh-4.2# systemctl status | grep -B5 pause
注意如果输出返回多个暂停进程条目，您必须识别正确的暂停进程。
输出示例
# ├─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
运行以下命令，验证 pod 服务质量(QoS)等级
Guaranteed是否在kubepods.slice子目录中：# cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
# for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
注意其他 QoS 等级的 Pod 会位于父
kubepods的子cgroups中。输出示例
cpuset.cpus 1 tasks 32706
运行以下命令，检查任务允许的 CPU 列表：
# grep ^Cpus_allowed_list /proc/32706/status
输出示例
Cpus_allowed_list: 1
验证系统中的另一个 pod 无法在为
Guaranteedpod 分配的内核中运行。例如，要验证besteffortQoS 层中的 pod，请运行以下命令：# cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
# 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
