/avatar.webp

koordinator Descheduler的LowNodeLoad插件助力节点平衡与应用稳定性的提升

深度解析descheduler的highNodeUtilization和lowNodeUtilization插件的原理 中研究了kubernetes社区里的descheduler的两个Node utilization插件,而这两个插件用都存在使用request来计算节点的资源使用情况,无法解决节点过热(小部分节点的资源使用高于其他大部分节点)问题。而这篇文章介绍koordinator descheduler的LowNodeLoad插件就是解决这个问题的,它基于节点实际的资源使用值来区分高水位节点、正常节点和低水位节点。

koordinator descheduler兼容社区的descheduler,同时增加了两个插件MigrationController和LowNodeLoad(在Koordinator v1.1中增加的)。

koordinator的LowNodeLoad插件类似lowNodeUtilization插件,都是将高水位节点的pod驱逐到低水位节点上。跟lowNodeUtilization不同的是,它是基于节点的真实负载对节点进行分类,它能够真正解决节点资源过热问题。

MigrationController插件提供资源保留和仲裁机制(拦截机制),通过这两个能力保障descheduler驱逐pod时候的应用稳定性。

这篇文章只介绍LowNodeLoad插件,MigrationController插件后面文章会介绍,本文基于Koordinator v1.4版本和Descheduler v0.28.1

Kubernetes成本优化最佳实践

在降本增效的大环境下,Finops的理念非常符合这个需求。FinOps是一种结合财务、技术和业务的最佳实践方法,旨在优化云计算资源的成本、性能和价值。FinOps的目标是通过合理的资源管理和财务决策,使组织能够更好地理解、控制和优化云计算成本。

FinOps的阶段分为成本观测(Inform)、 成本分析(Recommend)和 成本优化(Operate)。

一般企业内部的成本平台会包含成本观测和成本分析,它将IT成本(云厂商的账单)按照服务类型维度和业务部门维度进行分析。

成本优化(Operate)从容易到难分为3个阶段:

  1. 处理空闲的机器和服务,合理选择服务和资源,包括适当的实例类型和计费模型(定价模型)和储值计划(Reserved Capacity)和套餐折扣。
  2. 应用服务缩容降配、减少冗余资源(三活变双活–“Twitter就是这么干”,双活变冷备,双活变单活、人员优化)
  3. 技术手段优化(提高利用率)

本文关注的技术优化成本阶段,在kubernets下的云原生降本策略。

为什么被驱逐evicted pod未被删除以及如何清理

最近我发现了一个出乎意料的现象:当deployment的replicas缩减为0时,被kubelet驱逐的pod并没有被自动删除。通常情况下,当deployment有副本数时,被驱逐的pod不会被删除,这与我的预期相符。然而,在replicas为0的情况下,驱逐的pod没有被删除,这让我感到意外。这篇文章来讨论evicted pod移除相关的话题。

2023年总结

2023总体感觉自己还在困境中不断的挣扎,但是慢慢看到了一丝希望。就像步履蹒跚的往上爬,抬头看到了坡顶。自己感觉在云原生领域小有积累,可以慢慢的输出自己的知识和思考,同时提升自己的技术影响力。

深度解析descheduler的highNodeUtilization和lowNodeUtilization插件的原理

最近在研究descheduler,主要为了解决node节点出现cpu热点问题,即节点的cpu使用率相差特别大,而节点的request分布均匀。我们知道kube-scheduler将pod调度到节点上,而descheduler将pod进行移除,让workload控制器重新生成pod,并再次触发pod调度流程将pod调度到节点。通过这个方法达到pod重调度和节点的平衡目的。

社区的descheduler项目为了解决以下场景:

  1. 部分节点利用率过高,需要平衡节点的利用率
  2. 在pod调度之后,节点的label、taint不满足pod的pod/node affinity,需要将pod移动到符合的节点
  3. 新节点加入集群,需要平衡节点的利用率
  4. pod处于failed状态但是没有清理
  5. 同一个workload的pod集中在同一节点上

descheduler利用插件机制来扩展它的能力,插件分为Balance(节点平衡)和Deschedule(pod重调度)两个类型。

深度解析Static Pod在kubelet中的移除流程

上篇文章讲了有意思的mirror pod的移除流程,这篇文章来研究static pod的移除流程。

static pod可以来自文件和HTTP服务,而且static pod只在kubelet内部可见,mirror pod是static pod的镜像让外部组件能够捕获static状态。

上篇文章讲了删除mirror pod并不会删除static pod,执行static pod的删除需要通过删除--pod-manifest-path目录下的文件或让--manifest-url的http server返回response body里移除这个pod。

深入探索Kubernetes中的Mirror Pod删除过程及其对Static Pod 的影响

这也是一篇研究pod移除流程的文章,这个文章专注mirror pod的移除。mirror pod这个名词可能很陌生,中文直译就是镜像pod,它是pod里的一种类型。

那我们先介绍pod的分类,pod来源分为file、http、apiserver。其中来自apiserver中的pod称为普通pod,其他来源的pod称为static pod(使用kubeadm安装集群的控制平面就是用static pod运行的)。为了管理pod方便,kubelet会在apiserver上为static pod生成对应的pod,这类型pod称为mirror pod,即可以理解是这个pod的替身(基本上跟static pod一模一样,只有uid不一样和annotations里多了"kubernetes.io/config.mirror")。

那么删除mirror pod会发生什么?对节点上static pod有没有影响,会不会移除节点上的static pod?