标签：避免 未使用 使用 imei 监控 tle 而且 添加 ati
在 K8s 集群运营过程中，常常会被节点 CPU 和内存的高使用率所困扰，既影响了节点上 Pod 的稳定运行，也会增加节点故障的几率。为了应对集群节点高负载的问题，平衡各个节点之间的资源使用率，应该基于节点的实际资源利用率监控信息，从以下两个策略入手：
为此，我们提供 动态调度器 + Descheduler 的方案来实现，目前在公有云 TKE 集群内【组件管理】- 【调度】分类下已经提供这两个插件的安装入口，文末还针对具体的客户案例提供了最佳实践的例子。
原生的 Kubernetes 调度器有一些很好的调度策略用来应对节点资源分配不均的问题，比如 BalancedResourceAllocation，但是存在一个问题是这样的资源分配是静态的，不能代表资源真实使用情况，节点的 CPU/内存利用率 经常处于不均衡的状态。所以，需要有一种策略可以基于节点的实际资源利用率进行调度。动态调度器所做的就是这样的工作。
原生 K8s 调度器提供了 scheduler extender 机制来提供调度扩展的能力。相比修改原生 scheduler 代码添加策略，或者实现一个自定义的调度器，使用 scheduler extender 的方式侵入性更少，实现更加灵活。所以我们选择基于 scheduler extender 的方式来添加基于节点的实际资源利用率进行调度的策略。
scheduler extender 可以在原生调度器的预选和优选阶段加入自定义的逻辑，提供和原生调度器内部策略同样的效果。
原生调度器的调度策略在优选阶段有一个权重配置，每个策略的评分乘以权重得到该策略的总得分。对权重越高的策略，符合条件的节点越容易调度上。默认所有策略配置权重为 1，为了提升动态调度器策略的效果，我们把动态调度器优选策略的权重设置为 2。
在集群中，如果出现一个新增的节点，为了防止新增的节点调度上过多的节点，我们会通过监听调度器调度成功事件，获取调度结果，标记每个节点过去一段时间的调度 Pod 数,比如 1min、5min、30min 内的调度 Pod 数量，衡量节点的热点值然后补偿到节点的优选评分中。
组件依赖较少，仅依赖基础的节点监控组件 node-exporter 和 Prometheus。Prometheus 支持托管和自建两种方式，使用托管方式可以一键安装动态调度器，而使用自建 Prometheus 也提供了监控指标配置方法。
调度策略目前可以基于 CPU 和内存两种资源利用率。
配置节点 5分钟内 CPU 利用率、1小时内最大 CPU 利用率，5分钟内平均内存利用率，1小时内最大内存利用率的阈值，超过了就会在预选阶段过滤节点。
动态调度器优选阶段的评分根据截图中 6个指标综合评分得出，6个指标各自的权重表示优选时更侧重于哪个指标的值，使用 1h 和 1d 内最大利用率的意义是要记录节点 1h 和 1d 内的利用率峰值，因为有的业务 Pod 的峰值周期可能是按照小时或者天，避免调度新的 Pod 时导致在峰值时间节点的负载进一步升高。
为了衡量动态调度器对增强 Pod 调度到低负载节点的提升效果，结合调度器的实际调度结果，获取所有调度到的节点在调度时刻的的 CPU/内存利用率以后统计以下几个指标：
| 指标 | 未开启动态调度 | 开启动态调度 |
|---|---|---|
| cpu_utilization_total_avg | 0.30 | 0.17 |
| memory_utilization_total_avg | 0.28 | 0.23 |
| effective_dynamic_schedule_count | 2160 | 3620 |
| total_schedule_count | 7860 | 7470 |
| effective_schedule_ratio | 0.273 | 0.486 |
现有的集群调度场景都是一次性调度，即一锤子买卖。后续出现节点 CPU 和内存利用率过高，也无法自动调整 Pod 的分布，除非触发节点的 eviction manager 后驱逐，或者人工干预。这样在节点 CPU/内存利用率高时，影响了节点上所有 Pod 的稳定性，而且负载低的节点资源还被浪费。
针对此场景，借鉴 K8s 社区 Descheduler 重调度的设计思想，给出基于各节点 CPU/内存实际利用率进行驱逐的策略。
Descheduler 从 apiserver 中获取 Node 和 Pod 信息，从 Prometheus 中获取 Node 和 Pod 监控信息，然后经过Descheduler 的驱逐策略，驱逐 CPU/内存使用率高的节点上的 Pod ，同时我们加强了 Descheduler 驱逐 Pod 时的排序规则和检查规则，确保驱逐 Pod 时服务不会出现故障。驱逐后的 Pod 经过动态调度器的调度会被调度到低水位的节点上，实现降低高水位节点故障率，提升整体资源利用率的目的。
依赖基础的节点监控组件 node-exporter 和Prometheus。Prometheus 支持托管和自建两种方式，使用托管方式可以一键安装 Descheduler，使用自建 Prometheus 也提供了监控指标配置方法。
Descheduler 根据用户配置的利用率阈值，超过阈值水位后开始驱逐 Pod ，使节点负载尽量降低到目标利用率水位以下。
通过 K8s 事件可以看到 Pod 被重调度的信息，所以可以开启集群事件持久化功能来查看 Pod 驱逐历史。
在类似如下节点 CPU 使用率监控视图内，可以看到在开始驱逐之后，节点的 CPU 利用率下降。
拿一个客户的集群为例，由于客户的业务大多是内存消耗型的，所以更容易出现内存利用率很高的节点，各个节点的内存利用率也很不平均，未使用动态调度器之前的各个节点监控是这样的： 
配置预选和优选阶段的参数如下：
在预选阶段过滤掉 5分钟内平均内存利用率超过 60%或者 1h内最大内存利用率超过 70%的节点，即 Pod 不会调度到这些这些节点上。
在优选阶段将 5分钟平均内存利用率权重配置为 0.8，1h 和1d 内最大内存利用率权重配置为 0.2、0.2，而将 CPU 的指标权重都配置为 0.1。这样优选时更优先选择调度到内存利用率低的节点上。
配置 Descheduler 的参数如下，当节点内存利用率超过 80%这个阈值的时候，Descheduler 开始对节点上的 Pod 进行驱逐，尽量使节点内存利用率降低到目标值 60% 为止。
通过以上的配置，运行一段时间后，集群内各节点的内存利用率数据如下，可以看到集群节点的内存利用率分布已经趋向于均衡：
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
被集群节点负载不均所困扰？TKE 重磅推出全链路调度解决方案
标签：避免 未使用 使用 imei 监控 tle 而且 添加 ati
原文地址：https://www.cnblogs.com/0591jb/p/14327034.html
