任务

Kubernetes v1.16 版本的文档已不再维护。您现在看到的版本来自于一份静态的快照。如需查阅最新文档,请点击 最新版本。

任务
管理集群
管理集群
Debug DNS 方案
IP Masquerade Agent 用户指南
Kubernetes 云管理控制器
Safely Drain a Node while Respecting the PodDisruptionBudget (EN)
为 Kubernetes 运行 etcd 集群
为系统守护进程预留计算资源
为节点发布扩展资源
使用 CoreDNS 进行服务发现
使用 KMS 提供商进行数据加密
使用 Kubernetes API 访问集群
关键插件 Pod 的调度保证
启用端点切片
命名空间演练
在 Kubernetes 集群中使用 NodeLocal DNSCache
在 Kubernetes 集群中使用 sysctl
在实时集群上重新配置节点的 Kubelet
声明网络策略
开发云控制器管理器
控制节点上的 CPU 管理策略
控制节点上的拓扑管理策略
搭建高可用的 Kubernetes Masters
改变默认 StorageClass
更改 PersistentVolume 的回收策略
自定义 DNS 服务
访问集群上运行的服务
通过命名空间共享集群
通过配置文件设置 Kubelet 参数
配置 API 对象配额
配置多个调度器
配置资源不足时的处理方式
限制存储消耗
集群 DNS 服务自动伸缩
集群安全
集群管理
静态加密 Secret 数据
用插件扩展 kubectl
管理巨页(HugePages)
调度 GPUs

Edit This Page

控制节点上的拓扑管理策略

FEATURE STATE: Kubernetes v1.16 alpha

越来越多的系统利用 CPU 和硬件加速器的组合来支持对延迟要求较高的任务和高吞吐量的并行计算。 这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。 此类混合系统即用于构造这些高性能环境。

为了获得最佳性能,需要进行与 CPU 隔离、内存和设备局部性有关的优化。 但是,在 Kubernetes 中,这些优化由各自独立的组件集合来处理。

拓扑管理器(Topology Manager) 是一个 Kubelet 的一部分,旨在协调负责这些优化的一组组件。

准备开始

你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群,你可以通过 Minikube 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

要获知版本信息,请输入 kubectl version.

拓扑管理器如何工作

在引入拓扑管理器之前, Kubernetes 中的 CPU 和设备管理器相互独立地做出资源分配决策。 这可能会导致在多处理系统上出现并非期望的资源分配;由于这些与期望相左的分配,对性能或延迟敏感的应用将受到影响。 这里的不符合期望意指,例如, CPU 和设备是从不同的 NUMA 节点分配的,因此会导致额外的延迟。

拓扑管理器是一个 Kubelet 组件,扮演信息源的角色,以便其他 Kubelet 组件可以做出与拓扑结构相对应的资源分配决定。

拓扑管理器为组件提供了一个称为 建议供应者(Hint Providers) 的接口,以发送和接收拓扑信息。 拓扑管理器具有一组节点级策略,具体说明如下。

拓扑管理器从 建议提供者 接收拓扑信息,作为表示可用的 NUMA 节点和首选分配指示的位掩码。 拓扑管理器策略对所提供的建议执行一组操作,并根据策略对提示进行约减以得到最优解;如果存储了与预期不符的建议,则该建议的优选字段将被设置为 false。 在当前策略中,首选的是最窄的优选掩码。 所选建议将被存储为拓扑管理器的一部分。 取决于所配置的策略,所选建议可用来决定节点接受或拒绝 Pod 。 之后,建议会被存储在拓扑管理器中,供 建议提供者 进行资源分配决策时使用。

拓扑管理器策略

当前拓扑管理器:

如果满足这些条件,则拓扑管理器将综合考虑 CPU 和设备请求。

拓扑管理器支持四种分配策略。 您可以通过 Kubelet 标志 --topology-manager-policy 设置策略。 所支持的策略有四种:

  • none (默认)
  • best-effort
  • restricted
  • single-numa-node

none 策略

这是默认策略,不执行任何拓扑对齐。

best-effort 策略

对于 Guaranteed 类的 Pod 中的每个容器,具有 best-effort 拓扑管理策略的 kubelet 将调用每个建议提供者以确定资源可用性。 使用此信息,拓扑管理器存储该容器的首选 NUMA 节点亲和性。 如果亲和性不是首选,则拓扑管理器将存储该亲和性,并且无论如何都将 pod 接纳到该节点。

之后 建议提供者 可以在进行资源分配决策时使用这个信息。

restricted 策略

对于 Guaranteed 类 Pod 中的每个容器, 配置了 restricted 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。。 使用此信息,拓扑管理器存储该容器的首选 NUMA 节点亲和性。 如果亲和性不是首选,则拓扑管理器将从节点中拒绝此 Pod 。 这将导致 Pod 处于 Terminated 状态,且 Pod 无法被节点接纳。

如果 Pod 被允许运行在该节点,则 建议提供者 可以在做出资源分配决定时使用此信息。

single-numa-node 策略

对于 Guaranteed 类 Pod 中的每个容器, 配置了 single-numa-nodde 拓扑管理策略的 kubelet 调用每个建议提供者以确定其资源可用性。 使用此信息,拓扑管理器确定单 NUMA 节点亲和性是否可能。 如果是这样,则拓扑管理器将存储此信息,然后 建议提供者 可以在做出资源分配决定时使用此信息。 如果不可能,则拓扑管理器将拒绝 Pod 运行于该节点。 这将导致 Pod 处于 Terminated 状态,且 Pod 无法被节点接受。

Pod 与拓扑管理器策略的交互

考虑以下 pod 规范中的容器:

spec:
  containers:
  - name: nginx
    image: nginx

该 Pod 在 BestEffort QoS 类中运行,因为没有指定资源 requestslimits

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

由于 requests 数少于 limits,因此该 Pod 以 Burstable QoS 类运行。

如果选择的策略是 none 以外的任何其他策略,拓扑管理器不会考虑这些 Pod 中的任何一个规范。

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 在 Guaranteed QoS 类中运行,因为其 requests 值等于 limits 值。

拓扑管理器会对此 Pod 进行评估处理。 拓扑管理器首先调用 CPU 管理器的 static 策略,该策略返回可用 CPU 的拓扑信息。 拓扑管理器还咨询设备管理器以获得可用的 example.com/device 设备的拓扑信息。

拓扑管理器将使用此信息来存储此容器的最佳拓扑。 对于此 Pod, CPU 和设备管理器将在资源分配阶段使用这里存储的信息。

反馈