解救Kubernetes混乱:Descheduler快速实现资源平衡

By default, Kubernetes doesn't recompute and rebalance workloads. You could have a cluster with fewer overutilized nodes and others with a handful of pods How can you fix this?

关注【云原生百宝箱】公众号,快速掌握云原生

默认情况下,Kubernetes不会重新计算和重新平衡工作负载。

你可能会遇到一些节点过度利用的集群,而其他节点只有少量的Pod。

你可以如何解决这个问题呢?

1:只有一个节点的集群

Let's consider a cluster with a single node that can host 2 Pods You maxed out all available resources so you can scale the cluster to have a second node and spread the load

让我们考虑一个只有一个节点可以承载2个Pod的集群。

你已经使用了所有可用资源,所以你可以扩展集群,增加一个第二个节点来分担负载。

2:准备第二个节点

You provision a second node; what happens next? Does Kubernetes notice that there's a space for your Pod? Does it move the second Pod and rebalance the cluster?

Unfortunately, it does not. But why?

你准备了第二个节点,接下来会发生什么?Kubernetes会注意到有一个Pod的空间吗?它会移动第二个Pod并重新平衡集群吗?

不幸的是,它不会这样做。但为什么呢?

3:部署Deployment

When you define a Deployment, you specify:

  • The template for the Pod
  • The number of copies (replicas)

当你定义一个部署(Deployment)时,你需要指定:

  • Pod的模板(template)
  • 副本数量(replicas)

4:Kubernetes不会自动重新平衡你的Pod

But nowhere in that file, you said you want one replica for each node! The ReplicaSet counts 2 Pods, and that matches the desired state Kubernetes won't take any further action

但是在文件中你并没有指定每个节点一个副本!ReplicaSet 计数为2个Pod,这与期望的状态相匹配,Kubernetes 不会采取任何进一步的动作。

5:Descheduler定期扫描集群

In other words, Kubernetes does not rebalance your pods automatically But you can fix this with the descheduler The Descheduler scans your cluster at regular intervals, and if it finds a node that is more utilized than others, it deletes a pod in that node

换句话说,Kubernetes不会自动重新平衡你的Pod。但是你可以通过使用Descheduler来解决这个问题

Descheduler会定期扫描你的集群,如果发现某个节点的利用率高于其他节点,它会删除该节点上的一个Pod。

6:一个Pod被删除

What happens when a Pod is deleted? The ReplicaSet will create a new Pod, and the scheduler will likely place it in a less utilized node

当一个Pod被删除时会发生什么?

ReplicaSet会创建一个新的Pod,调度器(scheduler)很可能会将其放置在一个利用率较低的节点上。

7:Descheduler按策略驱逐

The Descheduler can evict pods based on policies such as:

  • Node utilization
  • Pod age
  • Failed pods
  • Duplicates
  • Affinity or taints violations

Descheduler可以根据以下策略驱逐Pod:

  • 节点利用率
  • Pod的年龄
  • 失败的Pod
  • 重复的Pod
  • 亲和性或污点违规

8:策略1:CPU、内存或Pod数量

If your cluster has been running long, the resource utilization is not very balanced The following two strategies can be used to rebalance your cluster based on CPU, memory or number of pods

如果你的集群已经运行了一段时间,资源利用可能不太平衡。

以下两种策略可以根据CPU、内存或Pod数量来重新平衡你的集群。

9:策略2:删除超过特定时间阈值的Pod

Another practical policy is deleting pods older than a certain threshold In this example, pods running for more than seven days are deleted

另一个实用的策略是删除超过特定时间阈值的Pod。在这个例子中,运行超过七天的Pod将被删除。

10:策略3:RemoveDuplicate插件

Or you can use the RemoveDuplicate plugin to remove similar Pods from running on the same node This is useful to ensure higher availability if a node is lost

或者你可以使用RemoveDuplicate插件 来删除在同一个节点上运行的相似Pod。

这对于确保更高的可用性非常有用,特别是当一个节点丢失时。

11:集成Node Problem Detector

And lastly, you can combine the Descheduler with Node Problem Detector and Cluster Autoscaler to automatically remove Nodes with problems Let me explain with an example

最后,你可以将Descheduler与Node Problem Detector和Cluster Autoscaler结合使用,以自动删除出现问题的节点。

让我通过一个例子来解释。

Node Problem Detector can detect specific Node problems such as PIDPressure, MemoryPressure, etc. and report them to the API server The node controller can be configured to apply a taint to a node for a given state (TaintNodeByCondition)

Node Problem Detector可以检测特定的节点问题,例如PIDPressure、MemoryPressure等,并将它们报告给API服务器。

节点控制器可以配置为根据给定状态对节点施加污点(TaintNodeByCondition)。

12:使用RemovePodsViolatingNodeTaints策略

After the taint is assigned to the node, you can have the Descheduler evict workloads from that tainted node using the RemovePodsViolatingNodeTaints strategy

在节点被标记(taint)之后,你可以使用RemovePodsViolatingNodeTaints策略让Descheduler从被标记的节点上驱逐工作负载(workload)。

The pods can't be allocated to the same node since they don't tolerate the taint So, they are scheduled elsewhere in the cluster

由于Pods不容忍(tolerate)该污点,它们无法分配到相同的节点上。

因此,它们会在集群中的其他地方进行调度。

Finally, the node is likely to fall below the Cluster Autoscaler's scale-down threshold and become a scale-down candidate and can be removed by Cluster Autoscaler

最后,该节点很可能会低于Cluster Autoscaler的缩容阈值,成为一个缩容候选节点,并可以被Cluster Autoscaler移除。

13:总结

The Descheduler is an excellent choice to keep your cluster efficiency in check, but it isn't installed by default It can be deployed as a Job, CronJob or Deployment More info:

Descheduler是一个很好的选择,可以保持集群的效率,但它不是默认安装的。

它可以作为Job、CronJob或Deployment部署。

更多信息:https://github.com/kubernetes-sigs/descheduler

相关推荐
灼烧的疯狂8 分钟前
K8S + Jenkins 做CICD
容器·kubernetes·jenkins
wenyue11211 小时前
Revolutionize Your Kubernetes Experience with Easegress: Kubernetes Gateway API
容器·kubernetes·gateway
Python私教4 小时前
ubuntu搭建k8s环境详细教程
linux·ubuntu·kubernetes
O&REO5 小时前
单机部署kubernetes环境下Overleaf-基于MicroK8s的Overleaf应用部署指南
云原生·容器·kubernetes
politeboy5 小时前
k8s启动springboot容器的时候,显示找不到application.yml文件
java·spring boot·kubernetes
运维小文6 小时前
K8S资源限制之LimitRange
云原生·容器·kubernetes·k8s资源限制
登云时刻6 小时前
Kubernetes集群外连接redis集群和使用redis-shake工具迁移数据(二)
redis·容器·kubernetes
wuxingge15 小时前
k8s1.30.0高可用集群部署
云原生·容器·kubernetes
志凌海纳SmartX16 小时前
趋势洞察|AI 能否带动裸金属 K8s 强势崛起?
云原生·容器·kubernetes
锅总16 小时前
nacos与k8s service健康检查详解
云原生·容器·kubernetes