！15666k8s解决pod调度不均衡的问题 2020-07-31阅读 1.8K评论 1 问题及原因 k8s是通过sceduler来调度pod的，在调度过程中，由于一些原因，会出现调度不均衡的问

k8s解决pod调度不均衡的问题

2020-07-31阅读 1.8K评论 1

问题及原因

k8s是通过sceduler来调度pod的，在调度过程中，由于一些原因，会出现调度不均衡的问题，例如：

节点故障新节点被加到集群中节点资源利用不足

这些都会导致pod在调度过程中分配不均，例如会造成节点负载过高，引发pod触发OOM等操作造成服务不可用

其中，节点资源利用不足时是最容易出现问题的，例如，设置的requests和limits不合理，或者没有设置requests/limits都会造成调度不均衡

解决办法及分析

在这之前，我们需要先装一个metrics，安装方法可参考：k8s的metrics部署

Scheduler在调度过程中，经过了预选阶段和优选阶段，选出一个可用的node节点，来把pod调度到该节点上。那么在预选阶段和优选阶段是如何选出node节点的呢？

最根本的一个调度策略就是判断节点是否有可分配的资源，我们可以通过以下kubectl describe node node名来查看，现在按照这个调度策略来分析下

查看当前的节点资源占用情况



可以看到，当前的k8s集群共有三个node节点，但是节点的资源分布情况极其不均匀，而实际上，k8s在进行调度时，计算的就是requests的值，不管你limits设置多少，k8s都不关心。所以当这个值没有达到资源瓶颈时，理论上，该节点就会一直有pod调度上去。所以这个时候就会出现调度不均衡的问题。有什么解决办法？

给每一个pod设置requests和limits，如果资源充足，最好将requests和limits设置成一样的，提高Pod的QoS重平衡，采取人为介入或定时任务方式，根据多维度去对当前pod分布做重平衡

重平衡工具Descheduler

工具简介

Descheduler 的出现就是为了解决 Kubernetes 自身调度（一次性调度）不足的问题。它以定时任务方式运行，根据已实现的策略，重新去平衡 pod 在集群中的分布。

截止目前，Descheduler 已实现的策略和计划中的功能点如下：

已实现的调度策略

RemoveDuplicates 移除重复 podLowNodeUtilization 节点低度使用RemovePodsViolatingInterPodAntiAffinity 移除违反pod反亲和性的 podRemovePodsViolatingNodeAffinity

路线图中计划实现的功能点

Strategy to consider taints and tolerations 考虑污点和容忍Consideration of pod affinity 考虑 pod 亲和性Strategy to consider pod life time 考虑 pod 生命周期Strategy to consider number of pending pods 考虑待定中的 pod 数量Integration with cluster autoscaler 与集群自动伸缩集成Integration with metrics providers for obtaining real load metrics 与监控工具集成来获取真正的负载指标Consideration of Kubernetes’s scheduler’s predicates 考虑 k8s 调度器的预判机制

策略介绍

RemoveDuplicates 此策略确保每个副本集(RS)、副本控制器(RC)、部署(Deployment)或任务(Job)只有一个 pod 被分配到同一台 node 节点上。如果有多个则会被驱逐到其它节点以便更好的在集群内分散 pod。LowNodeUtilization a. 此策略会找到未充分使用的 node 节点并在可能的情况下将那些被驱逐后希望重建的 pod 调度到该节点上。 b. 节点是否利用不足由一组可配置的 阈值(thresholds) 决定。这组阈值是以百分比方式指定了 CPU、内存以及 pod数量 的。只有当所有被评估资源都低于它们的阈值时，该 node 节点才会被认为处于利用不足状态。 c. 同时还存在一个 目标阈值(targetThresholds)，用于评估那些节点是否因为超出了阈值而应该从其上驱逐 pod。任何阈值介于 thresholds 和 targetThresholds 之间的节点都被认为资源被合理利用了，因此不会发生 pod 驱逐行为（无论是被驱逐走还是被驱逐来）。 d. 与之相关的还有另一个参数numberOfNodes，这个参数用来激活指定数量的节点是否处于资源利用不足状态而发生 pod 驱逐行为。RemovePodsViolatingInterPodAntiAffinity 此策略会确保 node 节点上违反 pod 间亲和性的 pod 被驱逐。比如节点上有 podA 并且 podB 和 podC（也在同一节点上运行）具有禁止和 podA 在同一节点上运行的反亲和性规则，则 podA 将被从节点上驱逐，以便让 podB 和 podC 可以运行。RemovePodsViolatingNodeAffinity 此策略会确保那些违反 node 亲和性的 pod 被驱逐。比如 podA 运行在 nodeA 上，后来该节点不再满足 podA 的 node 亲和性要求，如果此时存在 nodeB 满足这一要求，则 podA 会被驱逐到 nodeB 节点上。

遵循机制

当 Descheduler 调度器决定于驱逐 pod 时，它将遵循下面的机制：

Critical pods (with annotations scheduler.alpha.kubernetes.io/critical-pod) are never evicted 关键 pod（带注释 scheduler.alpha.kubernetes.io/critical-pod）永远不会被驱逐。Pods (static or mirrored pods or stand alone pods) not part of an RC, RS, Deployment or Jobs are never evicted because these pods won’t be recreated 不属于RC，RS，部署或作业的Pod（静态或镜像pod或独立pod）永远不会被驱逐，因为这些pod不会被重新创建。Pods associated with DaemonSets are never evicted 与 DaemonSets 关联的 Pod 永远不会被驱逐。Pods with local storage are never evicted 具有本地存储的 Pod 永远不会被驱逐。BestEffort pods are evicted before Burstable and Guaranteed pods QoS 等级为 BestEffort 的 pod 将会在等级为 Burstable 和 Guaranteed 的 pod 之前被驱逐。

部署方式

Descheduler 会以 Job 形式在 pod 内运行，因为 Job 具有多次运行而无需人为介入的优势。为了避免被自己驱逐 Descheduler 将会以 关键型 pod 运行，因此它只能被创建建到 kube-system namespace 内。 关于 Critical pod 的介绍请参考：Guaranteed Scheduling For Critical Add-On Pods

要使用 Descheduler，我们需要编译该工具并构建 Docker 镜像，创建 ClusterRole、ServiceAccount、ClusterRoleBinding、ConfigMap 以及 Job。

yaml文件下载地址：-github.com

git clone -github.com

Run As A Job

kubectl create -f kubernetes/rbac.yaml kubectl create -f kubernetes/configmap.yaml kubectl create -f kubernetes/job.yaml

Run As A CronJob

kubectl create -f kubernetes/rbac.yaml kubectl create -f kubernetes/configmap.yaml kubectl create -f kubernetes/cronjob.yaml

两种方式，一种是以任务的形式启动，另一种是以计划任务的形式启动，建议以计划任务方式去启动

启动之后，可以来验证下descheduler是否启动成功

kubectl get pod -n kube-system | grep descheduler descheduler-job-6qtk2 1/1 Running 0 158m

再来验证下pod是否分布均匀



可以看到，目前node02这个节点的pod数是20个，相比较其他节点，还是差了几个，那么我们只对pod数量做重平衡的话，可以对descheduler做如下的配置修改

cat kubernetes/configmap.yaml — apiVersion: v1 kind: ConfigMap metadata: name: descheduler-policy-configmap namespace: kube-system data: policy.yaml: | apiVersion: “descheduler/v1alpha1” kind: “DeschedulerPolicy” strategies: “RemoveDuplicates”: enabled: true “RemovePodsViolatingInterPodAntiAffinity”: enabled: true “LowNodeUtilization”: enabled: true params: nodeResourceUtilizationThresholds: thresholds: #阈值 # “cpu” : 20 #注释掉下面这些关于cpu和内存的配置项 # “memory”: 20 “pods”: 24 #把pod的数值调高一些 targetThresholds: # 目标阈值 #“cpu” : 50 # “memory”: 50 “pods”: 25

修改完成后，重启下即可

kubectl delete -f kubernetes/configmap.yaml kubectl apply -f kubernetes/configmap.yaml kubectl delete -f kubernetes/cronjob.yaml kubectl apply -f kubernetes/cronjob.yaml

然后，看下Descheduler的调度日志

lownodeutilization.go:236] 4 pods evicted

通过这个日志，可以看到

Node “k8s-node01” is over utilized，然后就是有提示evicting pods from node “k8s-node01”，这就说明，Descheduler已经在重新调度了，最终调度结果如下：



本文参与腾讯云自媒体分享计划，欢迎正在阅读的你也加入，一起分享。

文章来自专栏

dogfei

226 篇文章

28 人关注

订阅

评论 (1)写评论