云原生之Kubernetes：22、资源调度器与调度机制详解

最新推荐文章于 2023-09-22 05:30:00 发布

湫一刀

最新推荐文章于 2023-09-22 05:30:00 发布

阅读量399

点赞数 3

分类专栏：云原生 # Kubernetes 文章标签： kubernetes

[email protected]

本文链接：https://blog.csdn.net/flq18210105507/article/details/126784300

版权

云原生同时被 2 个专栏收录

44 篇文章 10 订阅

订阅专栏

Kubernetes

32 篇文章 9 订阅

订阅专栏

22.资源调度器与调度机制

前言

在Kubernetes中，调度是指确保Pod与Node节点的匹配度，以便Kubelet可以运行它们。

1、调度概述

在kubernetes集群的概念中，调度主要是做两件事情：

监听新创建，且未被分配至任何node节点的pod资源
根据机身集群的计算资源、规则、匹配度等情况，为新的pod资源进行调度

2、调度流程

调度流程

如图所示，调度流程可分为两大块：

Filtering和Scoring

1、Filtering
在这里插入图片描述

预选阶段，也称为predicate。
会按照预选过滤器，首先把不符合要求的node节点直接剔除在外。
这一阶段为可行性筛选。
通常，会有不止一个。如果筛选列表为空，则该Pod尚无法完成调度。

如图所示，经过Filtering阶段，node01和node03已经标红并剔除在外。

常用的预选过滤器，我整理了一个表格供大家参考，所有过滤器可移步Filtering大全。

预选过滤器名	说明
PodFitsHostPorts	检查node节点是否有可用端口
PodFitsHost	检查pod中是否通过hostname定义了node
PodFitsResources	检查标签选择器和node节点标签是否匹配
NoVolumeZoneConflict	检查节点上Pod请求的卷是否可用
NoDiskConflict	检查pod请求的volume是否已经挂载
MaxCSIVolumeCount	评估应该新增多少个CSI卷，以及是否超出配置的限制
CheckNodeMemoryPressure	如果节点处于内存压力，不会将pod调度至此
CheckNodePIDPressure	如果节点pid稀缺，不会将pod调度至此
CheckNodeDiskPressure	如果节点磁盘存在压力，不会将pod调度至此
CheckNodeCondition	检查节点是否具备调度的基础条件，如文件系统是否可用，网络是否可用或者kubelet是否就绪，否则不会将pod调度至此
PodToleratesNodeTaints	检查pod的容忍度是否能容忍节点的污点
CheckVolumeBinding	评估Pod是否适合其所需的容量，这适用于绑定和未绑定的PVC

2、Scoring

打分阶段，也称为priority。
通过优选函数对节点进行打分，从而决定调度策略。
这一阶段为优选阶段，筛选哪个节点更优。

如图所示，经过Scoring阶段，只剩下node04和node06了。

常用的优选过滤器，我也整理了一个表格供大家参考，所有过滤器可移步Scoring大全。

优选过滤器名	说明
SelectorSpreadPriority	标签优先级计算
InterPodAffinityPriority	pod亲和度计算
LeastRequestedPriority	倾向于调度至请求较少、资源更空闲的节点上
MostRequestedPriority	倾向于调度至请求较多、资源更紧凑的节点上
RequestedToCapacityRatioPriority	使用默认资源打分函数进行优选计算
BalancedResourceAllocation	倾向于调度至资源平衡的节点
NodePreferAvoidPodsPriority	通过scheduler.alpha.kubernetes.io/preferAvoidPods注释，避免pod间调度至同一个node节点
NodeAffinityPriority	node亲和度计算
TaintTolerationPriority	根据节点上无法忍受的污点数量，为所有节点准备优先级列表
ImageLocalityPriority	倾向于本地已有pod缓存的节点
ServiceSpreadingPriority	对于给定服务，此策略旨在确保该服务的Pod在不同的节点上运行
CalculateAntiAffinityPriorityMap	此策略有助于实现pod的反亲和力
EqualPriorityMap	所有节点给定一个相同的权重

3、InterPodAffinityPriority与NodeAffinityPriority

在优选过滤器中，我提到过两个过滤器InterPodAffinityPriority和NodeAffinityPriority，他们是十分重要的，常常也会理解出现偏差。
1、InterPodAffinityPriority

我们称之为pod亲和度，pod对pod的亲和性，表示是否愿意与相关pod调度至一个区域（可以是node、机架、也可以是机房）

如何定义同一区域，则需要使用topologyKey（v1.16特性）进行标识，下一章节我会着重讲解的。

同理，还会有pod反亲和，这个你应该很好理解了。

除此之外，pod亲和度分为以下两种：

硬亲和(required)：使用requiredDuringSchedulingIgnoredDuringExecution字段定义，如果条件都不满足，则不调度，Pod对象的状态会一直是Pending状态
软亲和(preferred)：使用preferredDuringSchedulingIgnoredDuringExecution字段定义，如果条件都不满足，也会从中按照打分，“勉为其难”的选择一个进行调度

pod亲和度的API文档：

kubectl explain pod.spec.affinity.podAffinity

pod反亲和度的API文档：

kubectl explain pod.spec.affinity.podAntiAffinity

2、NodeAffinityPriority

我们称之为node亲和度，pod对node的亲和性，表示是否愿意调度到某个node上，其也细分为以下两种：

硬亲和(required)：使用requiredDuringSchedulingIgnoredDuringExecution字段定义，如果条件都不满足，则不调度，Pod对象的状态会一直是Pending状态
软亲和(preferred)：使用preferredDuringSchedulingIgnoredDuringExecution字段定义，如果条件都不满足，也会从中按照打分，“勉为其难”的选择一个进行调度

node亲和度的api文档：

kubectl explain pod.spec.affinity.nodeAffinity

4、示例：PodAffinity

上面，我提到过pod亲和度的定义，我们再来回顾一下：

pod亲和度，pod对pod的亲和性，表示是否愿意与相关pod调度在一个区域（可以是node、机架、也可以是机房），如何定义同一区域，则需要使用topologyKey（v1.16特性）进行标识。

我们先一起来看一下这个例子：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-with-preferred-pod-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp
      labels:
        app: myapp
    spec:
      affinity:
        podAffinity:           #pod亲和性
          preferredDuringSchedulingIgnoredDuringExecution:    #软亲和
          - weight: 80
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["db"]}
              topologyKey: rack
          - weight: 20
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - {key: app, operator: In, values: ["db"]}
              topologyKey: zone
      containers:
      - name: myapp
        image: nginx

上面这个例子表示：

1、定义了一个pod软亲和：preferredDuringSchedulingIgnoredDuringExecution
2、软亲和条件有2个，app标签中是否存在值为db的pod资源，但优先度不同；前者80，后者只有20
3、同一位置指标的定义为topologyKey，一个为rack，另一个为zone

可能你还是有点困惑，这里对于调度的情况我再来归纳一下：

该deployment定义了3个pod，其更愿意调度至存在app=db标签的pod的同一个机柜（rack），其次之选则是会选择调度至存在app=db标签的pod的同一个区域(zone)。
此时他们对同一位置的解释是截然不同的，现在你是否理解了呢？

5、示例：NodeAffinity

这里，我们也再次回顾一下概念，增强记忆。

node亲和度，pod对node的亲和性，表示是否愿意调度到某个node上，也细分为硬亲和和软亲和。

我们现在直接来看下面这个例子，其中：

1、定义了一个软亲和：preferredDuringSchedulingIgnoredDuringExecution
2、表示最期望调度至zone=foo的节点上
3、次期望调度至存在ssd标签的节点

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deploy-with-node-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
    spec:
      affinity:
        nodeAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:         #软亲和
          - weight: 60
            preference:
              matchExpressions:
              - {key: zone, operator: In, values: ["foo"]}
          - weight: 30
            preference:
              matchExpressions:
              - {key: ssd, operator: Exists, values: []}
      containers:
      - name: myapp
        image: nginx

6、表达式的优先级辨析

我们在实际使用过程中，很可能会使用多个表达式来限制调度的期望，可能是多个标签的过滤、也可能是多个表达式的拼接。
那么这些表达式的优先级是怎么样的呢，如果你没搞明白直接操作，会带来意想不到的后果的！（不建议）

我们先来看一个demo：

apiVersion: v1
kind: Pod
metadata:
  name: required-nodeAffinity-pod-or
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:           #硬亲和
        nodeSelectorTerms:
        - matchExpressions:               #matchExpressions级别是或关系（or）
          - {key: zone, operator: In, values: ["foo"]}   我们是(and)与关系，需要都满足
          - {key: zone, operator: In, values: ["bar"]}   我们是(and)与关系，需要都满足
        - matchExpressions:               #matchExpressions级别是或关系（or）
          - {key: ssd, operator: Exists, values: []}
  containers:
  - name: myapp
    image: nginx
    resources:
      requests:
        cpu: 6
        memory: 20Gi