《深入剖析kubernetes》学习笔记（7）——作业调度和资源管理

40. kubernetes的资源模型和资源管理

  • Pod是kubernetes中最小的调度单元，与调度和资源管理相关的属性都属于Pod对象的字段（实际上定义在Pod的各容器下），例如

    apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

  • 资源的分类

    • 可压缩资源，例如CPU，当其不足时，Pod只会“饥饿”等待，而不会退出
    • 不可压缩资源，例如内存，当其不足时，Pod会被内核kill

  • yaml中资源的单位

    • CPU：一般写作cpu:“500m”，表示500milicpu，意味着0.5cpu，也可以直接写成cpu:0.5，但这种写法不通用，仍建议使用m为单位
    • 内存：默认单位时bytes，例如memory:500Mi，意味着内存为500*1024*1024bytes；memory:100M意味着内存为500*1000*1000bytes

  • 定义资源限制时，还分limits和requests两种

    • 在调度的时候，kube-scheduler 只会按照 requests 的值进行计算
    • 在真正设置 Cgroups 限制的时候，kubelet 则会按照 limits 的值来进行设置
    • 类似Borg 论文中对“动态资源边界”的思想（刚提交作业时，其所需资源一般远小于他的资源限额，所以刚提交时会主动减小其资源限额，以提升效率，当资源用量提升到一定阈值时再“快速恢复”）

  • kubernetes的QoS模型，给Pod划分为几个QoS级别：

    • Guaranteed： Pod 里的每一个 Container 都同时设置了 requests 和 limits，并且 requests 和 limits 值相等（若仅设置了limits没有设置requests，kubernetes会自动设置与limits取值相同的requests）
    • Burstable：Pod 不满足 Guaranteed 的条件，但至少有一个 Container 设置了 requests
    • BestEffort：Pod 既没有设置 requests，也没有设置 limits

  • 当宿主机资源紧张的时候，kubelet 会对 Pod 进行 Eviction（即资源回收）

  • 比如，可用内存（memory.available）、可用的宿主机磁盘空间（nodefs.available），以及容器运行时镜像存储空间（imagefs.available）等等

  • Eviction 在 Kubernetes 里分为 Soft 和 Hard 两种模式。

    • Soft Eviction 允许设置一段“优雅时间”，达到阈值持续一段时间才会触发Eviction
    • Hard Eviction 模式下，Eviction 过程就会在阈值达到之后立刻开始。

  • Eviction时，kubelet根据Pod的QoS级别来决定回收哪些Pod:

    • 首先选择 BestEffort 类别的 Pod
    • 其次是Burstable 类别中资源使用量超过requestes的Pod
    • 最后是Guaranteed类别中资源使用量超过limits的，或者宿主机内存紧张的Pod
      • 建议将DaemonSet的Pod都设置为Guaranteed级别，不然一旦被回收又会立刻重建，令资源回收失去意义

  • cpuset的设置

    • 通过cpuset的设置，可将容器绑定到某个CPU核心上，无需共享CPU，减小OS在CPU之间切换的开销，提高容器中应用性能
    • 设置方式：保证Pod是Guaranteed类别，且CPU的requests和limits是相同的整数

41.kubernetes的默认调度器

  • 调度器职责在于为一个新创建出来的 Pod，寻找一个最合适的节点（Node）。
  • 调度器的核心在于两个相互独立的控制循环：
    • Informer Path
      • 启动一系列Informer，监听Etcd中与Pod、Node、Service 等与调度相关的 API 对象的变化
      • 将待调度的Pod加入调度队列（默认是优先级队列）
      • 更新调度器缓存（scheduler cache）中的信息
    • Scheduling Path
      • 是实际负责调度的主循环
      • 从调度队列中取出一个Pod，调用Predicates算法“过滤”得到一组Node（“过滤”所需的Node信息都是从调度器缓存中获取的），再调用Priority算法对这组Node进行打分，得分最高的作为调度的结果
      • 执行“乐观绑定”（也叫做Assume），真正的绑定操作需要访问APIServer，修改Pod对象中nodeName字段的值，而在本步骤中直接修改调度器缓存中的Pod和Node的信息
      • 创建一个Goroutine来异步地向APIServer发起更新Pod的请求，完成真正的Bind操作
  • Admit操作
    • 由于“乐观绑定”的操作，所以当新Pod完成调度要在某个节点上启动时，该节点kubelet还要执行Admit操作再次验证Pod是否确实能够在本节点上运行。
    • 实际就是再执行了一遍GeneralPredicates的基本调度算法

42.默认调度器策略

Predicates算法过滤Node的策略

  • 最基础的调度策略GeneralPredicates
    • PodFitsResources检查Pod的requests字段，计算宿主机的CPU和内存资源是否足够
    • PodFitsHost检查宿主机名字是否和Pod的sepc.nodeName一致（应只在admit操作中生效？）
    • PodFitsHostPort检查Pod申请的宿主机端口spec.nodePort是否已被占用
    • PodMatchNodeSelector检查Pod的nodeSelector或者nodeAffinity指定的节点是否与当前考察节点匹配
    • 该组策略检查了Pod能否运行在一个Node上的基本条件，在Pod启动之后前，kubelet还会执行Admit操作，即再执行一遍GeneralPredicates
  • 与Volume相关的过滤策略
    • NoDiskConflict检查多个Pod声明挂载的持久化Volume是否冲突
    • MaxPDVolumeCountPredicate检查某类型的持久化Volume是否超过一定数目
    • VolumeZonePredicate检查持久化 Volume 的 Zone（高可用域）标签，是否与待考察节点的 Zone 标签相匹配
    • VolumeBindingPredicate检查该Pod对应的PV的spec.nodeAffinity字段是否和该节点匹配【本地持久化卷“延迟绑定”发生的地方，若Pod的PVC还没有和PV绑定，调度器负责遍历所有待绑定的PV，当出现可用PV、且宿主机满足nodeAffinity要求一致时，该规则才返回“成功”】
  • 与宿主机相关的过滤策略
    • 主要检查待调度的Pod是否满足Node自身的要求，例如
    • PodToleratesNodeTaints检查Pod的Toleration字段是否和Node的Taint字段匹配
    • NodeMemoryPressurePredicate检查当前节点内存是否充足
  • 与Pod相关的过度策略
    • 与GeneralPredicates的规则大多数重合
    • PodAffinityPredicate检查待调度的Pod和当前节点已有Pod之间的亲密和反亲密关系
  • 当开始调度一个 Pod 时，Kubernetes 调度器会同时启动 16 个 Goroutine，来并发地为集群里的所有 Node 计算 Predicates，最后返回可以运行这个 Pod 的宿主机列表

Priority算法

  • LeastRequestedPriority：选择空闲资源（CPU 和 Memory）最多的宿主机

    • score = (cpu((capacity-sum(requested))10/capacity) + memory((capacity-sum(requested))10/capacity))/2

  • BalancedResourceAllocation：选择资源占用最均衡的宿主机

    • score = 10 - variance(cpuFraction,memoryFraction,volumeFraction)*10

  • ImageLocalityPriority：如果Pod所需镜像很大，则已有其所需镜像的node的得分会更高

    • 为了避免引起调度堆叠，当大镜像分布的节点很少时，则适当调低这些节点的权重

  • 还有NodeAffinityPriority、TaintTolerationPriority 和 InterPodAffinityPriority等

43.调度优先级和抢占机制

  • 优先级（Priority）和抢占（Preemption）解决的是调度失败时怎么办的问题

  • 基本思路

    • 当某个高优先级的Pod调度失败，则“挤走“某个Node上的一些低优先级Pod，从而保证高优先级Pod的成功调度

  • PriorityClass的定义

    apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."
    • Kubernetes 规定，优先级是一个 32 bit 的整数，且不超过10亿，超出的部分分配给了系统Pod

  • 具体实现

    • 调度器维护了两个调度队列
      • activeQ，存放下一个调度周期需要调度的Pod
      • unschedulableQ，存放调度失败的Pod。当其中的Pod更新后，就将其移动到activeQ中
    • 如何寻找Victims（应该被”挤走“的Pod）？
      • 第一步，检查调度失败原因，确认抢占是否可以帮抢占者找到新节点。（比如，若因没有和nodeAffinity匹配的节点而调度失败，则不会触发抢占）
      • 第二步，复制一份缓存的节点信息，用该副本模拟抢占操作。
    • 模拟抢占操作的过程
      • 遍历缓存副本中的所有节点，在每个节点上，从最低优先级开始逐一删除Pod，一旦抢占者可以运行，则记录该Node和需要删除的Pod列表
      • 从所有可能的抢占结果中选择一个，找到最优结果，以尽量减小对现有系统的影响（被删除的Pod数量最小，或者优先级最低等等）
    • 实际抢占过程
      • 第一步，清理牺牲者Pod所携带的nominatedNodeName字段
      • 第二步，将抢占者Pod的nominatedNodeName字段设置为被抢占的Node名字，抢占者Pod重新进入activeQ，进入下一个调度周期【需要注意，调度器不能保证该Pod一定会被调度到nominatedNodeName指定的Node上】
      • 第三步，开启一个Goroutine，同步删除牺牲者
    • 当activeQ中存在有比当前待调度的Pod优先级更高的Pod携带了nominatedNodeName字段时，则对当前待调度Pod，调度器会对所有Node执行两遍Predicates算法
      • 第一遍， 调度器会假设上述“潜在的抢占者”已经运行在这个节点上，然后执行 Predicates 算法；
        • 原因在于，考虑InterPodAntiAffinity的规则，若抢占者已经存在待考察Node上了，当前Pod还能否成功调度到该Node上
      • 第二遍， 调度器会正常执行 Predicates 算法，即：不考虑任何“潜在的抢占者”。

  • 当整个集群发生可能会影响调度结果的变化（比如，添加或者更新 Node，添加和更新 PV、Service 等）时，调度器会执行一个被称为 MoveAllToActiveQueue 的操作，把所调度失败的 Pod 从 unscheduelableQ 移动到 activeQ 里面

  • 当一个已经调度成功的 Pod 被更新时，调度器则会将 unschedulableQ 里所有跟这个 Pod 有 Affinity/Anti-affinity 关系的 Pod，移动到 activeQ 里面

44.GPU管理和device plugin

  • 基本使用诉求：只要在 Pod 的 YAML 里面，声明某容器需要的 GPU 个数，那么 Kubernetes 为我创建的容器里就应该出现对应的 GPU 设备，以及它对应的驱动目录
  • Kubernetes 在 Pod 的 API 对象里，没有为 GPU 专门设置一个资源类型字段，而是使用了一种叫作 Extended Resource（ER）的特殊字段来负责传递 GPU 的信息，例如
apiVersion: v1
kind: Pod
metadata:
  name: cuda-vector-add
spec:
  restartPolicy: OnFailure
  containers:
    - name: cuda-vector-add
      image: "k8s.gcr.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  • 宿主机需要向kubernetes的APIServer汇报自身的GPU资源情况，这是通过device plugin机制实现的
  • Device Plugin示意图

img

  • Device Plugin工作流程
    • 每一种硬件设备，都有对应的Device Plugin管理，通过gRPC的方法与kubelet连接
    • ListAndWatch：定期向kubelet汇报该Node上的GPU列表
    • Allocate：Pod调度到本机后，kubelet从自己持有的GPU中为该容器分配其所需的GPU，即通过Allocate()方法向Device Plugin传递待分配的GPU ID列表
    • Device Plugin根据Allocate()方法提供的GPU ID列表，查找设备的路径和驱动目录，返回给kubelet
    • kubelet将设备的信息追加在CRI请求中，发送给Docker，则Docker创建的容器就会有这个设备，并挂载了其所需的驱动目录
  • Device Plugin机制的缺点：
    • Allocate 和 ListAndWatch API 无法添加可扩展性的参数，所以对硬件设备的管理只能停留在“设备个数”这一层面，无法完成更加复杂的操作
posted @ 2021-02-08 10:48  lwjj  阅读(386)  评论(0)  编辑  收藏  举报