不平衡问题排查
问题描述：
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的逻辑，其中驱逐分为软驱逐和硬驱逐，参数名为
--evited-hard=memory.available<100Mi
--evited-soft=memory.available<100Mi
其中memory.available设置了触发驱逐的阈值，也即大于等于此阈值则在当前node发生pod驱逐
案例分析
Pod分布不平衡（按内存使用率）
内存使用率范围（0%，85%），监控如下图：
驱逐
未明确设定驱逐参数，如下图：
改进方案
Pod分布不平衡（按内存使用率）
由第二章分析可知，目前集群使用的调度器是default-scheduler,而该调度器不会直接监控节点的内存使用率,因此需要将节点的内存使用率加入调度逻辑（一般是算分阶段，进而影响最终排序），考虑到改动时间成本等因素(可参考第五章使用第三方调度等，单改动较大，风险也大)，可以指定scheduler启动配置文件如下：
cat KubeSchedulerConfiguration.yamlapiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:- schedulerName: default-schedulerplugins:score:enabled:- name: PodTopologySpread- name: NodeResourcesFitpluginConfig:- args:scoringStrategy:resources:- name: cpuweight: 1- name: memoryweight: 10type: LeastAllocatedname: NodeResourcesFit- name: PodTopologySpreadargs:defaultingType: "List"defaultConstraints:- maxSkew: 1topologyKey: kubernetes.io/hostnamewhenUnsatisfiable: ScheduleAnywaymemoryWeight: 5 # 设置 memory 权重为 5，表示内存使用更重要参数形如： --config=/path/to/ KubeSchedulerConfiguration.yaml
启动形如：kube-scheduler --config=/path/to/ KubeSchedulerConfiguration.yaml <...其他参数>
效果：
驱逐
前提：需要安装集群monitor
根据分析过程分析可知，kubelet未指定驱逐参数，此时kubelet会以memory.available<100Mi 运行，而node节点的内存范围为[376G，750G],默认驱逐值明显不适用，因此建议设置合理值，目前推荐如下：
--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
