正文

kubelet从入门到放弃：拓扑管理(上)

ju13zh0b  2022-02-13  272

关键词：

<Kubelet从入门到放弃>系列将对Kubelet组件由基础知识到源码进行深入梳理。上一篇zouyee带各位看了CPU 管理的相关内容，其中提及拓扑管理，本文将对此进行详细剖析,拓扑管理在Kubernetes 1.18时提升为Beta。 TopologyManager功能可实现CPU、内存和外围设备（例如SR-IOV VF和GPU）的NUMA对齐，从而使集群满足低延迟需求。

一、背景介绍

注：下文TopologyManager简称为拓扑管理器

1.1 需求说明

随着单服务器节点内的处理器数量、硬件加速器及其他外围设备日益增多，越来越多的系统利用 CPU 和硬件加速器的组合来支持对延迟要求较高的任务和高吞吐量的并行计算。这类负载包括电信、科学计算、机器学习、金融服务和数据分析等。如何优化延迟敏感型的高性能并行计算应用的性能成了一个重大的挑战。

在引入拓扑管理器之前，CPU、内存和设备管理器在资源分配决策上彼此独立。这可能导致在多处理系统上出现与期望不符的资源分配，由于这些与期望不一致的分配，对性能或延迟敏感的应用将受到影响，例如， CPU 和设备是从不同的 NUMA 节点分配的，因此会导致额外的延迟。为了获得最佳性能，需要进行与 CPU 隔离、内存和设备局部性等有关的优化。

拓扑管理器是Kubelet中ContainerManager组件的一部分，充当存储分配资源信息的角色，以便ContainerManager组件可以做出与拓扑结构相适应的资源分配决策，以便在资源分配的时候实现拓扑结构上的对齐。注意拓扑管理不是单独起作用的，它和CPU manager、memory manager、Device manager共同为Pod分配资源，优化资源访问。

1.2 NUMA

在CPU管理中，我们已经介绍了NUMA技术（再回顾一遍）。

NUMA

NUMA，以内存访问的不一致性为代价，减轻对总线和memory的带宽需求。这种结构对进程调度算法的要求较高，尽量减少跨Node的内存访问次数，以提升系统性能。Core之间会共享总线、内存等资源。如果Core的数量较少，则没什么问题，但随着Core的增多，对总线以及内存带宽的需求就会显著增大，最终总线和内存会成为系统性能的瓶颈。

如下图所示，一个NUMA Node包括一个或者多个Socket，以及与之相连的local memory。一个多核的Socket有多个Core。如果CPU支持HT，OS还会把这个Core看成 2个Logical Processor。

Socket是一个物理上的概念，指的是主板上的cpu插槽
Node是一个逻辑上的概念，上图中没有提及。由于SMP体系中各个CPU访问内存只能通过单一的通道，导致内存访问成为瓶颈，cpu再多也无用。后来引入了NUMA，通过划分node，每个node有本地RAM，这样node内访问RAM速度会非常快。但跨Node的RAM访问代价会相对高一点,我们用Node之间的距离（Distance，抽象的概念）来定义各个Node之间互访资源的开销。
Core就是一个物理cpu,一个独立的硬件执行单元，比如寄存器，计算单元等
Thread就是超线程（HyperThreading）的概念，是一个逻辑cpu，共享core上的执行单元
- *

二、功能介绍

2.1 相关配置

在Kubernetes 1.18版本之前若需要启用拓扑管理器，需要在Kublet的特性门控处启用该特性。从Kubernetes 1.18 版本开始，这一特性默认启动。--feature-gates="...,TopologyManager=<true|false>"

为了满足定制对齐方式需求，拓扑管理器提供了两种不同的方式：scope 和 policy。

scope 定义了资源对齐的粒度（当前提供pod与 container 两种级别）。
policy 定义了对齐时实际使用的策略（当前提供best-effort、none、restricted、single-numa-node 等）。

注意：为了将 Pod 中的 CPU 与其他请求资源对齐，需要启用CPU 管理并且配置适当的 CPU 管理策略。

a. 作用域

正如上文所述，拓扑管理器提供以下两种不同的资源对齐粒度：

container （默认）
pod
在 kubelet 启动时，可以使用 --topology-manager-scope 标志来配置其中任一粒度。
1）容器作用域
默认使用的是 container 作用域，拓扑管理依次进行一系列的资源对齐，即对每一个容器（包含在一个 Pod 里）单独计算对齐。拓扑管理会把单个容器任意地对齐到 NUMA 节点上。
2）Pod作用域
在启动 kubelet时，配置 --topology-manager-scope=pod ，即可对齐粒度为 pod 。
该作用域允许把一个 Pod 里的所有容器作为一个分组，分配到一个共同的 NUMA 节点，即拓扑管理会把一个 Pod 当成一个整体，并且试图把整个 Pod（所有容器）分配到一个单个的 NUMA 节点或者一个共同的 NUMA 节点集。下例说明了拓扑管理器在不同的场景下使用的对齐方式：
- 所有容器可以被分配到一个单一的 NUMA 节点；
- 所有容器可以被分配到一个共享的 NUMA 节点集合。
  整个 Pod 请求的某种资源总量通过 request/limit公式计算，因此，对某一种资源而言，该总量等于以下数值中的最大值：
- 所有应用容器请求之和
- Init容器请求的最大值
  对于延迟敏感或者 IPC 高吞吐量工作负载，在配置Pod 作用域及 single-numa-node 拓扑管理策略时，可以把一个 Pod 里的所有容器都放到单一 NUMA 节点，使得该 Pod 消除了 NUMA 之间的通信开销。
  在 single-numa-node 策略下，只有当可能的分配方案中存在合适的 NUMA 节点集时，Kubelet才会准入该Pod。如下述的示例：
- 节点集只包含单个 NUMA 节点时，Pod 就会被准入
- 节点集包含多个 NUMA 节点时，Pod 会被拒绝
  简而言之，拓扑管理器首先计算出 NUMA 节点集，然后使用拓扑管理策略来测试该集合，从而决定拒绝或者接受 Pod。
b. 策略
拓扑管理支持四种分配策略，在 Kubelet 启动时，可以通过 Kubelet命令行 --topology-manager-policy 设置。当前支持的策略有四种：
- none (默认)
- best-effort
- restricted
- single-numa-node
  1）none
  这是默认策略，不执行任何拓扑对齐。
  2）best-effort
  对于 Guaranteed 类Pod 中的每个容器，配置 best-effort 拓扑管理策略的 kubelet 将调用每个Hint Provider以确定资源可用性。使用此信息，拓扑管理器存储该容器的首选亲和性NUMA 节点。如果亲和性不是首选，则拓扑管理器将存储该亲和性，并且无论如何都将 Pod 接纳到该节点。
  之后Hint Provider在进行资源分配决策时使用该信息。
  3）restricted 策略
  对于 Guaranteed 类 Pod 中的每个容器，配置了 restricted 拓扑管理策略的 Kubelet 调用每个Hint Provider以确定其资源可用性。使用此信息，拓扑管理器存储该容器的首选亲和性 NUMA 节点。如果亲和性不是首选，则拓扑管理器将从节点中拒绝此 Pod 。这将导致 Pod 处于 Terminated 状态。Pod调度失败，Kubernetes 调度器不会尝试重新调度该 Pod，建议使用 ReplicaSet 或者 Deployment部署 Pod。
  如果 Pod 被允许运行在某节点，则 Hint Provider 可以在做出资源分配决策时使用此信息。
  4）single-numa-node 策略
  对于 Guaranteed 类 Pod 中的每个容器，配置了 single-numa-nodde 拓扑管理策略的 Kubelet 调用每个Hint Provider以确定其资源可用性。使用此信息，拓扑管理器确定单一 NUMA 节点亲和性是否可能。如果是这样，则拓扑管理器将存储此信息，然后Hint Provider可以在做出资源分配决定时使用此信息。如果不满足，则拓扑管理器将拒绝该Pod ，这将导致 Pod 处于 Terminated 状态。
  一旦 Pod 处于 Terminated 状态，Kubernetes 调度器将不会尝试重新调度该 Pod。建议使用 ReplicaSet 或者 Deployment 来重新部署 Pod。
  2.2 Pod配置
  注意：关于Pod三种QoS介绍，后续会详细说明。
  因为没有指定资源 requests 或 limits，该 Pod 以 BestEffort QoS 运行。
  spec:
  containers:
  - name: nginx
  image: nginx
  因为 requests少于 limits，该 Pod 以 Burstable QoS 运行。
  spec:
  containers:
  - name: nginx
  image: nginx
  resources:
  limits:
  memory: "200Mi"
  requests:
  memory: "100Mi"
  针对上述 Pod，如果选择的策略是 none 以外的任何其他策略，拓扑管理器都会评估这些 Pod 的资源使用。拓扑管理器会调用Hint Provider，获得拓扑结果。若策略为 static，则 CPU 管理器策略返回默认的拓扑结果，因为这些 Pod 并没有显式地请求 CPU 资源。
  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因为其 requests 值等于 limits 值，因此以 Guaranteed QoS 运行。
  spec:
  containers:
  - name: nginx
  image: nginx
  resources:
  limits:
  example.com/deviceA: "1"
  example.com/deviceB: "1"
  requests:
  example.com/deviceA: "1"
  example.com/deviceB: "1"
  上述Pod因为未指定 CPU 和内存请求，所以 Pod 以 BestEffort QoS 类运行。
  总结如下：
  1. 对于 Guaranteed 类的Pod, 如果CPU 请求数为整数，CPU 管理器策略为static 时，将返回与 CPU 请求有关的hint，而设备管理器将返回有关所请求设备的hint。对于 Guaranteed 类的 CPU 请求可共享的 Pod（非整数CPU），CPU 管理器策略为static 时，将返回默认的拓扑hint，因为没有排他性的 CPU 请求，而设备管理器则针对所请求的设备返回有关hint。在上述两种 Guaranteed Pod 的情况中，CPU 管理器策略为none时，返回默认的拓扑hint。
  2. 对于 BestEffort Pod，由于没有 CPU 请求，CPU 管理器策略为static时，将发送默认hint，而设备管理器将为每个请求的设备发送hint。
  基于此信息，拓扑管理器将为 Pod 计算最佳hint并存储该信息，为 Hint Provider在进行资源分配时使用。
  2.3 示范说明
  例如，在图1中，包含2个NUMA节点，2个Socket（每个Socket具有4个CPU，2个GPU和2个NIC），CPU 0-3、GPU 0和NIC 0在Socket 0中，其属于NUMA 0节点，CPU 4-7、GPU 1和NIC 1在Socket 1中，其属于NUMA 1节点。
  只有相应外设实现Device Plugin接口，且Kubelet启用Device Manager时，Pod才能够从设备插件提供的可用资源中请求设备资源（例如intel.com/sriov、nvidia.com/gpu等）。例如已经完成Device Plugin接口的Nvidia GPU设备插件和Intel SRIOV网络设备插件。
  假设Kubelet对于CPUManager启用了static策略，并且gpu-vendor.com和nic-vendor.com的设备插件已实现Device Plugin接口，则下面的Pod配置可以使用拓扑管理器以运行其选定的策略：
  spec:
  containers:
  - name: numa-aligned-container
  image: alpine
  resources:
  limits:
  cpu: 2
  memory: 200Mi
  gpu-vendor.com/gpu: 1
  nic-vendor.com/nic: 1
  按照图1资源情况，资源对齐结果如下所示：
  {cpu: {0, 1}, gpu: 0, nic: 0}
  {cpu: {0, 2}, gpu: 0, nic: 0}
  {cpu: {0, 3}, gpu: 0, nic: 0}
  {cpu: {1, 2}, gpu: 0, nic: 0}
  {cpu: {1, 3}, gpu: 0, nic: 0}
  {cpu: {2, 3}, gpu: 0, nic: 0}
  
  {cpu: {4, 5}, gpu: 1, nic: 1}
  {cpu: {4, 6}, gpu: 1, nic: 1}
  {cpu: {4, 7}, gpu: 1, nic: 1}
  {cpu: {5, 6}, gpu: 1, nic: 1}
  {cpu: {5, 7}, gpu: 1, nic: 1}
  {cpu: {6, 7}, gpu: 1, nic: 1}
  注意：（再次申明）如果某个Pod被拓扑管理器拒绝，它的状态将为Terminated，并带有一个Pod准入错误和“TopologyAffinityError的原因说明。一旦Pod处于该状态，Kubernetes调度程序将不会尝试重新调度。

gradle从入门到放弃

1Gradle工具的基本介绍Java作为一门世界级主流编程语言，有一款高效易用的项目管理工具是Java开发者共同追求的心愿和目标。先是2000年的Ant，后有2004年Maven两个工具的诞生，都在Java市场上取得了巨大的成功。但是二者都有一定... 查看详情

docker从入门到放弃(代码片段)

...机时候用到的docker，时间长了也忘了，准备好好梳理学习入门一波。《十分感谢大神的文章，本文基于大神的文章学习整理。》一、入门基础??Docker使查看详情

webpack从入门到放弃之路

公司的中流砥柱要走啦!!!!我要接手这些摊子啦!!!!!硬着头皮上吧!/(ㄒoㄒ)/~~第一部分:webpack使用部分第二部分:自动化部署部分第三部分:前端视频部分tobecontinue… 查看详情

vue从入门到放弃(代码片段)

今日学习内容：1.vuex的介绍2.vuex的结构和组成3.vuex的安装命令4.vuex的state、getters、mutations、actions的使用5.modules模块化和命名空间的使用vuex的介绍**VueX是一个专门为Vue.js应用设计的状态管理架构，统一管理和维护各个vue组... 查看详情

vue从入门到放弃(代码片段)

《java从入门到放弃》入门篇：变量

变量是什么玩意呢？变量，顾名思义就是能变化的量-- 好吧，举个栗子。图片上的各种餐具，就是变量，因为同一个盘子可以在不同的时间装不同的菜，在这一桌可以装土豆肉丝，在下一桌可以装清炒黄瓜(当然，这个盘... 查看详情

git从入门到放弃

git重要命令一、本地操作主要操作:gitbranch分支：分支管理，创建分支gitcheckout分支：切换分支gitcheckout–文件：放弃修改文件，.放弃所有文件gitmerge分支：合并分支，在Git中合并两个分支时会产生一个... 查看详情

nginx从入门到放弃

前面我们学习了nginx的基本操作和日志管理，今天我们学习一下生产环境经常会用到的路由定位location设置，在工作中，经常可能会出现怎么设置的路由访问不到网页呀？总是出现404错误啊，这些都很有可能是location的配置有误所... 查看详情

typescript从入门到放弃

先点赞后关注，防止会迷路寄语：长风破浪会有时，直挂云帆济沧海。本文已收录至https://github.com/likekk/-Blog欢迎大家star??????,共同学习，共同进步。如果文章有错误的地方，欢迎大家指出。后期将在将github上规划前端学习的路线... 查看详情

《java从入门到放弃》文章目录

...，等相关内容都写完后，再按学习顺序来整理。《Java从入门到放弃》入门篇：XMLHttpRequest的基本用法《Java从入门到放弃》入门篇：Struts2的基本访问方《Java从入门到放弃》入门篇：Struts2的基本访查看详情

深度学习---从入门到放弃优化器(代码片段)

深度学习—从入门到放弃（四）优化器1.案例引入-MNIST手写数字识别现代深度学习优化中的许多核心思想（和技巧）可以在训练MLP以解决图像分类任务的中进行说明。在这里我们使用的是手写数字的MNIST数据集࿰... 查看详情

vue.js2.0从入门到放弃---入门案例

最近，vue.js越来越火。在这样的大浪潮下，我也开始进入vue的学习行列中，在网上也搜了很多教程，按着教程来做，也总会出现这样那样的问题（坑啊，由于网上那些教程都是Vue.js1.x版本的，现在用Vue.js的构建工具都已经升级到... 查看详情

java从入门到放弃

（1）Java入门变量与注释用户输入if语句java中的循环while 查看详情

深度学习:从入门到放弃

https://zhuanlan.zhihu.com/p/22976342 首发于深度学习:从入门到放弃写文章登录 FCN学习:SemanticSegmentation余俊1年前感谢@huangh12 @郑途 @麦田守望者对标签图像生成的研究和讨论，这几天研究了一下，补充如下。-------------------... 查看详情

《java从入门到放弃》javase入门篇：网络编程(入门版)

要进行网络编程，首先要搞清楚目的是什么。网络编程说简单点就是在网络上的计算机进行数据的交互。650)this.width=650;"src="https://s4.51cto.com/wyfs02/M00/07/18/wKiom1nDU8jBR29DAADRe0E88II285.png"title="11.png"width="600"height="328"border="0"hspace="0 查看详情

[资源]深度学习从入门到放弃

Relationship:　　MachineLearning---->DeepLearning　　　　　　　　　　　　　　　　　　　　　　　　　　---->DeepReinforcementLearning[LearningRoadMap]　　　　　　　　　　　　　　ReinforcementLearningPapers:　　DeepLearningPapersReadin 查看详情

vue从入门到放弃(代码片段)

----------------------------------------------------点击这里《专栏目录》查看更多--------------------------------------------------------------------------------------------------------点击这里《专栏目录》查看更多---------------- 查看详情

正文

kubelet从入门到放弃：拓扑管理(上)

一、背景介绍

1.1 需求说明

1.2 NUMA

NUMA

二、功能介绍

2.1 相关配置

a. 作用域

b. 策略

2.2 Pod配置

2.3 示范说明

gradle从入门到放弃

docker从入门到放弃(代码片段)

webpack从入门到放弃之路

vue从入门到放弃(代码片段)

vue从入门到放弃(代码片段)

《java从入门到放弃》入门篇：变量

git从入门到放弃

nginx从入门到放弃

typescript从入门到放弃

《java从入门到放弃》文章目录

深度学习---从入门到放弃优化器(代码片段)

vue.js2.0从入门到放弃---入门案例

java从入门到放弃

深度学习:从入门到放弃

《java从入门到放弃》javase入门篇：网络编程(入门版)

[资源]深度学习从入门到放弃

vue从入门到放弃(代码片段)

vue从入门到放弃(代码片段)