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

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 解救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

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
Kubernetes 监控 调度
在K8S中,DaemonSet类型资源特性?
在K8S中,DaemonSet类型资源特性?
|
1月前
|
存储 Kubernetes 数据中心
在K8S中,同⼀个Pod内不同容器哪些资源是共用的,哪些资源是隔离的?
在K8S中,同⼀个Pod内不同容器哪些资源是共用的,哪些资源是隔离的?
|
1月前
|
边缘计算 人工智能 Kubernetes
边缘计算问题之理解 Kubernetes 节点资源的四层分配结构如何解决
边缘计算问题之理解 Kubernetes 节点资源的四层分配结构如何解决
13 1
|
1月前
|
存储 Kubernetes API
|
1月前
|
Kubernetes Linux 调度
在k8S中,Pod如何实现对节点的资源控制?
在k8S中,Pod如何实现对节点的资源控制?
|
1月前
|
Kubernetes 监控 API
在K8S中,RS资源如何实现升级和回滚?
在K8S中,RS资源如何实现升级和回滚?
|
1月前
|
Kubernetes 网络协议 应用服务中间件
在K8S中,SVC资源是否支持在K8S集群外部访问?
在K8S中,SVC资源是否支持在K8S集群外部访问?
|
1月前
|
Kubernetes 监控 Cloud Native
"解锁K8s新姿势!Cobra+Client-go强强联手,打造你的专属K8s监控神器,让资源优化与性能监控尽在掌握!"
【8月更文挑战第14天】在云原生领域,Kubernetes以出色的扩展性和定制化能力引领潮流。面对独特需求,自定义插件成为必要。本文通过Cobra与Client-go两大利器,打造一款监测特定标签Pods资源使用的K8s插件。Cobra简化CLI开发,Client-go则负责与K8s API交互。从初始化项目到实现查询逻辑,一步步引导你构建个性化工具,开启K8s集群智能化管理之旅。
39 2
|
1月前
|
运维 Kubernetes 大数据
Kubernetes 的架构问题之在Serverless Container场景下尚不支持资源超售如何解决
Kubernetes 的架构问题之在Serverless Container场景下尚不支持资源超售如何解决
55 0
|
1月前
|
弹性计算 Kubernetes 算法
AHPA:Kubernetes弹性伸缩的预言家,揭秘未来资源使用的神秘面纱!
【8月更文挑战第8天】在云原生应用中,Kubernetes已成为部署标准。面对不断扩大的集群与应用规模,有效资源管理和弹性伸缩成为关键。AHPA(自适应历史感知预测算法)作为先进的预测技术,通过分析历史数据预测资源需求并自动调整Kubernetes资源分配。以一个在线零售平台为例,通过AHPA识别流量周期性变化,在节假日高峰期前自动增加Pod数量,保证服务稳定;而在平峰期减少Pod数量,节省资源。AHPA为Kubernetes提供了智能化的弹性伸缩方案,提高了应用稳定性和资源利用率。
54 7