7.8. 拓扑管理器
理解并使用拓扑管理器。
7.8.1. 拓扑管理器策略
拓扑管理器通过从 Hint 提供者（如 CPU Manager 和设备管理器）收集拓扑提示来调整所有级别服务质量（QoS）的 Pod 资源，并使用收集的提示来匹配 Pod 资源。
拓扑管理器支持四个分配策略，这些策略在名为 cpumanager-enabled 的 KubeletConfig 自定义资源 (CR) 中分配：
none策略- 这是默认策略，不执行任何拓扑对齐调整。
best-effort策略-
对于带有
best-effort拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选设置，则拓扑管理器会保存这个设置，并把 pod 分配给节点。 restricted策略-
对于带有
restricted拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这些信息，拓扑管理器会保存那个容器的首选 NUMA 节点关联性设置。如果关联性没有被首选，则拓扑管理器会从节点拒绝这个 pod，从而导致 pod 处于Terminated状态，且 pod 准入失败。 single-numa-node策略-
对于带有
single-numa-node拓扑管理策略的 pod 中的每个容器，kubelet 会调用每个 Hint 提供者来发现其资源的可用性。使用这个信息，拓扑管理器会决定单个 NUMA 节点关联性是否可能。如果是，pod 将会分配给该节点。如果无法使用单一 NUMA 节点关联性，则拓扑管理器会拒绝来自节点的 pod。这会导致 pod 处于 Terminated 状态，且 pod 准入失败。
7.8.2. 设置拓扑管理器
要使用拓扑管理器，您必须在名为 cpumanager-enabled 的 KubeletConfig 自定义资源 (CR) 中配置分配策略。如果您设置了 CPU Manager，则该文件可能会存在。如果这个文件不存在，您可以创建该文件。
先决条件
-
将 CPU Manager 策略配置为
static。
流程
激活 Topolgy Manager:
在自定义资源中配置拓扑管理器分配策略。
$ oc edit KubeletConfig cpumanager-enabled
apiVersion: machineconfiguration.openshift.io/v1 kind: KubeletConfig metadata: name: cpumanager-enabled spec: machineConfigPoolSelector: matchLabels: custom-kubelet: cpumanager-enabled kubeletConfig: cpuManagerPolicy: static 1 cpuManagerReconcilePeriod: 5s topologyManagerPolicy: single-numa-node 2
7.8.3. Pod 与拓扑管理器策略的交互
以下的 Pod specs 示例演示了 Pod 与 Topology Manager 的交互。
因为没有指定资源请求或限制，以下 pod 以 BestEffort QoS 类运行。
spec:
containers:
- name: nginx
image: nginx
因为请求小于限制，下一个 pod 以 Burstable QoS 类运行。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
如果所选策略不是 none，则拓扑管理器将不考虑其中任何一个 Pod 规格。
因为请求等于限制，最后一个 pod 以 Guaranteed QoS 类运行。
spec:
containers:
- name: nginx
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "2"
example.com/device: "1"
requests:
memory: "200Mi"
cpu: "2"
example.com/device: "1"拓扑管理器将考虑这个 pod。拓扑管理器会参考 CPU Manager 和设备管理器的 hint 供应商，以获取 pod 的拓扑提示。
拓扑管理器将使用此信息存储该容器的最佳拓扑。在本 pod 中，CPU Manager 和设备管理器将在资源分配阶段使用此存储的信息。
