K8S调度不平衡问题分析过程和解决方案

不平衡问题排查

问题描述

1、业务部署大量pod(据反馈,基本为任务型进程)过程中,k8s node内存使用率表现不均衡,范围从80%到百分之几;

2、单个node内存使用率超过95%,仍未发生pod驱逐,存在node不可正常运维风险;
期望效果

尽量保持pod调度平衡;

node内存使用率达到一定阈值,开始触发pod驱逐

分析过程

原理依据

K8S调度涉及到亲和性、资源可用情况等因素,而本案例是可调度但是调度后造成节点内存使用率差距很大,也即pod分布(基于内存使用率)不平衡;

Kube-Scheduler作为控制面节点接触,负责pod如何绑定到node的逻辑执行,一般默认为default-scheduler,且支持插件化配置和开发;

Kubelet作为K8S Node Agent,实际执行着创建、销毁以及驱逐pod的逻辑,其中驱逐分为软驱逐和硬驱逐,参数名为

bash 复制代码
--evited-hard=memory.available<100Mi 
--evited-soft=memory.available<100Mi

其中memory.available设置了触发驱逐的阈值,也即大于等于此阈值则在当前node发生pod驱逐

案例分析

Pod分布不平衡(按内存使用率)

内存使用率范围(0%,85%),监控如下图:


驱逐

未明确设定驱逐参数,如下图:

改进方案

Pod分布不平衡(按内存使用率)

由第二章分析可知,目前集群使用的调度器是default-scheduler,而该调度器不会直接监控节点的内存使用率,因此需要将节点的内存使用率加入调度逻辑(一般是算分阶段,进而影响最终排序),考虑到改动时间成本等因素(可参考第五章使用第三方调度等,单改动较大,风险也大),可以指定scheduler启动配置文件如下:

bash 复制代码
cat KubeSchedulerConfiguration.yaml

apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: default-scheduler
    plugins:
      score:
        enabled:
          - name: PodTopologySpread
          - name: NodeResourcesFit
    pluginConfig:
      - args:
          scoringStrategy:
            resources:
            - name: cpu
              weight: 1
            - name: memory
              weight: 10
            type: LeastAllocated
        name: NodeResourcesFit
      - name: PodTopologySpread
        args:
          defaultingType: "List"
          defaultConstraints:
          - maxSkew: 1
            topologyKey: kubernetes.io/hostname
            whenUnsatisfiable: ScheduleAnyway
          memoryWeight: 5  # 设置 memory 权重为 5,表示内存使用更重要

参数形如: --config=/path/to/ KubeSchedulerConfiguration.yaml

启动形如:kube-scheduler --config=/path/to/ KubeSchedulerConfiguration.yaml <...其他参数>

效果:

驱逐

前提:需要安装集群monitor

根据分析过程分析可知,kubelet未指定驱逐参数,此时kubelet会以memory.available<100Mi 运行,而node节点的内存范围为[376G,750G],默认驱逐值明显不适用,因此建议设置合理值,目前推荐如下:

bash 复制代码
 --evited-hard=memory.available<40G 
 --evited-soft=memory.available<50G

或者按如下kubelet配置:

效果如下:

建议

此问题反映出资源分配和调度的问题,涉及范围较为综合,运维侧提供了较为稳定的iaas平台环境,很多场景可以保证资源的使用率,此时从资源充分使用角度落地方案;当节点数固定时,提出了资源使用平衡,则调度器需要较为实时感知到资源使用情况(此案例为内存使用率),以选择适合的节点进行绑定调度。

参考

案例参考:https://segmentfault.com/a/1190000042005893

其他组件:

Trimaran 官网地址:https://github.com/kubernetes-sigs/scheduler-plugins/tree/master/pkg/trimaran

descheduler 官网地址:https://github.com/kubernetes-sigs/descheduler

相关推荐
chuanauc4 小时前
Kubernets K8s 学习
java·学习·kubernetes
小张是铁粉4 小时前
docker学习二天之镜像操作与容器操作
学习·docker·容器
烟雨书信4 小时前
Docker文件操作、数据卷、挂载
运维·docker·容器
IT成长日记4 小时前
【Docker基础】Docker数据卷管理:docker volume prune及其参数详解
运维·docker·容器·volume·prune
这儿有一堆花4 小时前
Docker编译环境搭建与开发实战指南
运维·docker·容器
LuckyLay4 小时前
Compose 高级用法详解——AI教你学Docker
运维·docker·容器
Uluoyu4 小时前
redisSearch docker安装
运维·redis·docker·容器
IT成长日记9 小时前
【Docker基础】Docker数据持久化与卷(Volume)介绍
运维·docker·容器·数据持久化·volume·
疯子的模样13 小时前
Docker 安装 Neo4j 保姆级教程
docker·容器·neo4j
庸子16 小时前
基于Jenkins和Kubernetes构建DevOps自动化运维管理平台
运维·kubernetes·jenkins