kubernetes之pod重调度-descheduler

DevOpSec
• 阅读 326

kubernetes之pod重调度-descheduler

1. kubernetes-sigs/descheduler简介

在使用kubernetes中,你是否存在以下困扰?

  • 一些节点使用不足或过度使用。
  • 最初的调度决策不再成立,因为污点或标签被添加到节点或从节点删除,不再满足 pod/节点亲和性要求。
  • 一些节点出现故障,它们的 pod 移动到其他节点。
  • 新节点被添加到集群中。

如果你也像我一样遇到上述问题的话,救星来了,那就是kubernetes-sigs/descheduler项目,该项目可以重新平衡资源使用,避免节点利用率不均匀,造成资源空闲和浪费,descheduler根据其策略,找到可以移动的 pod 并驱逐它们。请注意,在当前的实现中,descheduler不会安排被驱逐的pod的替换,而是依赖于默认的kube-scheduler。
项目地址: https://github.com/kubernetes-sigs/descheduler

2.kubernetes-sigs/descheduler实践

  1. Job模式
kubectl create -f  kubernetes/base/rbac.yaml
kubectl create -f  kubernetes/base/configmap.yaml
kubectl create -f  kubernetes/job/job.yaml
  1. cronjob模式
kubectl create -f  kubernetes/base/rbac.yaml
kubectl create -f  kubernetes/base/configmap.yaml
kubectl create -f  kubernetes/cronjob/cronjob.yaml
  1. deployment模式
kubectl create -f  kubernetes/base/rbac.yaml
kubectl create -f  kubernetes/base/configmap.yaml
kubectl create -f  kubernetes/deployment/deployment.yaml
  1. helm模式
helm repo add descheduler https://kubernetes-sigs.github.io/descheduler/
helm install my-release --namespace kube-system descheduler/descheduler

具体的chart配置参考: https://github.com/kubernetes-sigs/descheduler/blob/master/charts/descheduler/README.md
5. Kustomize模式

1. job: kustomize build 'github.com/kubernetes-sigs/descheduler/kubernetes/job?ref=v0.21.0' | kubectl apply -f -
2. cronjob: kustomize build 'github.com/kubernetes-sigs/descheduler/kubernetes/cronjob?ref=v0.21.0' | kubectl apply -f -
3. deployment: kustomize build 'github.com/kubernetes-sigs/descheduler/kubernetes/deployment?ref=v0.21.0' | kubectl apply -f -

3.kubernetes-sigs/descheduler策略

支持的策略:

  1. RemoveDuplicates
  2. LowNodeUtilization
  3. HighNodeUtilization
  4. RemovePodsViolatingInterPodAntiAffinity
  5. RemovePodsViolatingNodeAffinity
  6. RemovePodsViolatingNodeTaints
  7. RemovePodsViolatingTopologySpreadConstraint
  8. RemovePodsHavingTooManyRestarts
  9. PodLifeTime 目前在实现中

所有策略默认启用。
策略示意图:
kubernetes之pod重调度-descheduler

策略公共配置:

  • nodeSelector - 限制处理的节点
  • evictLocalStoragePods - 允许驱逐具有本地存储的 Pod
  • evictSystemCriticalPods - [警告:将驱逐 Kubernetes 系统 Pod] 允许驱逐具有任何优先级的 Pod,包括像 kube-dns 这样的系统 Pod
  • ignorePvcPods- 设置是否应驱逐或忽略 PVC pod(默认为false)
  • maxNoOfPodsToEvictPerNode - 从每个节点驱逐的 Pod 的最大数量(通过所有策略求和)
apiVersion: "descheduler/v1alpha1"
kind: "DeschedulerPolicy"
nodeSelector: prod=dev
evictLocalStoragePods: true
evictSystemCriticalPods: true
maxNoOfPodsToEvictPerNode: 40
ignorePvcPods: false
strategies:
  ...

总结

kubernetes-sigs/descheduler可以说是在我们日常k8s运维过程中,提高资源使用效率的法宝,我们应该好好掌握它,最棒的事,它的文档写的非常详细,至于具体到策略的用法,这里就不在赘述,自行去github上学习即可,最后附上文档地址:https://github.com/kubernetes-sigs/descheduler#policy-and-strategies

点赞
收藏
评论区
推荐文章
Prodan Labs Prodan Labs
3年前
Kubernetes自定义调度器 — 初识调度框架
Kubernetes已经成为容器编排(Orchestration)平台的事实标准,它为容器化应用提供了简单且高效部署的方式、大规模可伸缩、资源调度等生命周期管理功能。kubescheduler作为kubernetes的核心组件,它负责整个集群资源的调度功能,根据特定的调度算法或调度策略,将Pod调度到最优的Node节点,使集群的资源得到合理且充分的利用。
Prodan Labs Prodan Labs
3年前
Kubernetes自定义调度器 — 初窥门径
通过上一篇文章对schedulerframework调度框架已经有了大致了解,根据我们的实际生产的一些问题(如计算服务没有被调度到实际CPU最优的节点)和需求,来实现一个简单的基于CPU指标的自定义调度器。自定义调度器通过kubernetes资源指标服务metricsserver来获取各节点的当前的资源情况,并进行打分,然后把Pod调度到分数最高的节
DevOpSec DevOpSec
1年前
kubernetes之pod拓扑分布约束
kubernetes之pod拓扑分布约束在日常使用kubernetes的过程中中,很多时候我们并没有过多的关心pod的到底调度在哪里,只是通过多副本的测试,来提高的我们的业务的可用性,但是当多个
Stella981 Stella981
2年前
Kubernetes工作流程
Kubernetes工作流程!(https://oscimg.oschina.net/oscnet/125154c88288a56d3f8a0a76942105107de.png)客户端创建pod流程:1.用户管理员创建Pod的请求默认是通过kubectl客户端管理命令apiser
Stella981 Stella981
2年前
Kubernetes Pod 故障归类与排查方法
Pod概念Pod是kubernetes集群中最小的部署和管理的基本单元,协同寻址,协同调度。Pod是一个或多个容器的集合,是一个或一组服务(进程)的抽象集合。Pod中可以共享网络和存储(可以简单理解为一个逻辑上的虚拟机,但并不是虚拟机)。Pod被创建后用一个UID来唯一标
Wesley13 Wesley13
2年前
K8S故障排查指南
问题产生在使用Kubernetes时,有时会遇到Pod状态一直处理Terminating。Pod一直没有正常退出,一般情况会使用命令kubectldeletepodspodnameforcegraceperiod0强制删除。如果按照上面命令强制删除Pod,有一定概率会报Orphanedp
Stella981 Stella981
2年前
Kubernetes 调度器实现初探
Kubernetes调度器Kubernetes是一个基于容器的分布式调度器,实现了自己的调度模块。在Kubernetes集群中,调度器作为一个独立模块通过pod运行。从几个方面介绍Kubernetes调度器。调度器工作方式Kubernetes中的调度器,是作为单独组件运行,一般运行在Master中,和Master数量保持
Stella981 Stella981
2年前
Kubernetes Pod OOM 排查日记
一、发现问题在一次系统上线后,我们发现某几个节点在长时间运行后会出现内存持续飙升的问题,导致的结果就是Kubernetes集群的这个节点会把所在的Pod进行驱逐OOM;如果调度到同样问题的节点上,也会出现Pod一直起不来的问题。我们尝试了杀死Pod后手动调度的办法(label),当然也可以排除调度节点。但是在一段时间后还会复现,我们通过监控
Crane-scheduler:基于真实负载进行调度
作者邱天,腾讯云高级工程师,负责腾讯云TKE动态调度器与重调度器产品。背景原生kubernetes调度器只能基于资源的resourcerequest进行调度,然而Pod的真实资源使用率,往往与其所申请资源的request/limit差异很大,这直接导致了集群负载不均的问题:1.集群中的部分节点,资源的真实使用率远低于resourc
Crane-scheduler:基于真实负载进行调度
作者邱天,腾讯云高级工程师,负责腾讯云TKE动态调度器与重调度器产品。背景原生kubernetes调度器只能基于资源的resourcerequest进行调度,然而Pod的真实资源使用率,往往与其所申请资源的request/limit差异很大,这直接导致了集群负载不均的问题:1.集群中的部分节点,资源的真实使用率远低于resourcerequest,却没有被调度更多的Pod,这造成了比较大的资源浪费;2.而集群中的另外一些节点,其资源的真实使用率事实上已经过载,却无法为调