28. Kubernetes深入Pod-Pod调度策略之kube-scheduler

释放双眼,带上耳机,听听看~!

官方文档:https://kubernetes.io/zh/docs/concepts/scheduling-eviction/kube-scheduler/

kube-scheduler调度介绍

kube-scheduler是Kubernetes 集群的默认调度器,并且是集群控制面(master)的一部分。
对每一个新创建的Pod或者是未被调度的Pod,kube-scheduler会选择一个最优的Node去运行这个Pod。然而,Pod内的每一个容器对资源都有不同的需求,而且Pod本身也有不同的资源需求。因此,Pod在被调度到Node上之前,根据这些特定的资源调度需求,需要对集群中的Node进行一次过滤。

在一个集群中,满足一个Pod调度请求的所有Node称之为可调度节点。如果没有任何一个Node能满足Pod的资源请求,那么这个Pod将一直停留在未调度状态直到调度器能够找到合适的Node。

调度器先在集群中找到一个Pod的所有可调度节点,然后根据一系列函数对这些可调度节点打分,然后选出其中得分最高的Node来运行Pod。之后,调度器将这个调度决定通知给kube-apiserver,这个过程叫做绑定。

在做调度决定时需要考虑的因素包括:单独和整体的资源请求、硬件/软件/策略限制、亲和以及反亲和要求、数据局域性、负载间的干扰等等。

kube-scheduler 调度流程

kube-scheduler 给一个 pod 做调度选择包含两个步骤:

  1. 过滤(Predicates 预选策略)
  2. 打分(Priorities 优选策略)

过滤阶段:过滤阶段会将所有满足 Pod 调度需求的 Node 选出来。例如,PodFitsResources 过滤函数会检查候选 Node 的可用资源能否满足 Pod 的资源请求。在过滤之后,得出一个 Node 列表,里面包含了所有可调度节点;通常情况下,这个 Node 列表包含不止一个 Node。如果这个列表是空的,代表这个 Pod 不可调度。

打分阶段:在过滤阶段后调度器会为 Pod 从所有可调度节点中选取一个最合适的 Node。根据当前启用的打分规则,调度器会给每一个可调度节点进行打分。最后,kube-scheduler 会将 Pod 调度到得分最高的 Node 上。如果存在多个得分最高的 Node,kube-scheduler 会从中随机选取一个。

整体流程如下图所示:

过滤阶段

官方文档:https://kubernetes.io/docs/reference/scheduling/policies/
在调度时的过滤阶段到底时通过什么规则来对Node进行过滤的呢?就是通过以下规则!

  1. PodFitsHostPorts:检查Node上是否不存在当前被调度Pod的端口(如果被调度Pod用的端口已被占用,则此Node被Pass)。
  2. PodFitsHost:检查Pod是否通过主机名指定了特性的Node (是否在Pod中定义了nodeName)。
  3. PodFitsResources:检查Node是否有空闲资源(如CPU和内存)以满足Pod的需求。
  4. PodMatchNodeSelector:检查Pod是否通过节点选择器选择了特定的Node (是否在Pod中定义了nodeSelector)。
  5. NoVolumeZoneConflict:检查Pod请求的卷在Node上是否可用 (不可用的Node被Pass)。
  6. NoDiskConflict:根据Pod请求的卷和已挂载的卷,检查Pod是否合适于某个Node (例如Pod要挂载/data到容器中,Node上/data/已经被其它Pod挂载,那么此Pod则不适合此Node)
  7. MaxCSIVolumeCount::决定应该附加多少CSI卷,以及是否超过了配置的限制。
  8. CheckNodeMemoryPressure:对于内存有压力的Node,则不会被调度Pod。
  9. CheckNodePIDPressure:对于进程ID不足的Node,则不会调度Pod。
  10. CheckNodeDiskPressure:对于磁盘存储已满或者接近满的Node,则不会调度Pod。
  11. CheckNodeCondition:Node报告给API Server说自己文件系统不足,网络有写问题或者kubelet还没有准备好运行Pods等问题,则不会调度Pod。
  12. PodToleratesNodeTaints:检查Pod的容忍度是否能承受被打上污点的Node。
  13. CheckVolumeBinding:根据一个Pod并发流量来评估它是否合适(这适用于结合型和非结合型PVCs)。

打分阶段

官方文档:https://kubernetes.io/docs/reference/scheduling/policies/
当过滤阶段执行后满足过滤条件的Node,将进行打分阶段。

  1. SelectorSpreadPriority:优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量
  2. InterPodAffinityPriority:优先将 Pod 调度到相同的拓扑上(如同一个节点、Rack、Zone 等)
  3. LeastRequestedPriority:节点上放置的Pod越多,这些Pod使用的资源越多,这个Node给出的打分就越低,所以优先调度到Pod少及资源使用少的节点上。
  4. MostRequestedPriority:尽量调度到已经使用过的 Node 上,将把计划的Pods放到运行整个工作负载所需的最小节点数量上。
  5. RequestedToCapacityRatioPriority:使用默认资源评分函数形状创建基于requestedToCapacityResourceAllocationPriority
  6. BalancedResourceAllocation:优先平衡各节点的资源使用。
  7. NodePreferAvoidPodsPriority:根据节点注释对节点进行优先级排序,以使用它来提示两个不同的 Pod 不应在同一节点上运行。scheduler.alpha.kubernetes.io/preferAvoidPods
  8. NodeAffinityPriority:优先调度到匹配 NodeAffinity (Node亲和性调度)的节点上。
  9. TaintTolerationPriority:优先调度到匹配 TaintToleration (污点) 的节点上
  10. ImageLocalityPriority:尽量将使用大镜像的容器调度到已经下拉了该镜像的节点上。
  11. ServiceSpreadingPriority:尽量将同一个 service 的 Pod 分布到不同节点上,服务对单个节点故障更具弹性。
  12. EqualPriority:将所有节点的权重设置为 1。
  13. EvenPodsSpreadPriority:实现首选pod拓扑扩展约束。

kube-scheduler 调度示例

默认配置使用的就是kube-scheduler调度组件,我们下面例子启动三个Pod,看分别被分配到哪个Node。
1.创建资源配置清单

cat scheduler-pod.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: scheduler-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: scheduler-pod
  template:
    metadata:
      labels:
        app: scheduler-pod
    spec:
      containers:
      - image: busybox:latest
        name: scheduler-pod
        command: [ "/bin/sh", "-c", "tail -f /etc/passwd" ]

2.使用kubectl创建资源对象

kubectl apply -f scheduler-pod.yaml

3.查看被kube-scheduler自动调度的Pod
两个Pod在Node03上,一个在Node02上

kubectl get pods -o wide | grep scheduler
scheduler-deploy-65d8f9c98-cqdm9    1/1     Running            0          111s    10.244.5.59   k8s-node03   <none>           <none>
scheduler-deploy-65d8f9c98-d4t9p    1/1     Running            0          111s    10.244.5.58   k8s-node03   <none>           <none>
scheduler-deploy-65d8f9c98-f8xxc    1/1     Running            0          111s    10.244.2.45   k8s-node02   <none>           <none>

4.我们查看一下Node资源的使用情况
Node01,可用内存2.7G

Node02,可用内存5.8G

Node03,可用内存5.6G

所以默认的kube-scheduler调度策略经过了过滤和打分后,将以上三个Pod分布在Node2和Node3上。

Ops工具

27. Kubernetes深入Pod-Pod调度策略

2020-6-16 11:43:39

Ops工具

29. Kubernetes深入Pod-Pod调度策略之nodeName

2020-6-16 11:44:22

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索