继续上篇的ChatGPT demo4不能完成的需求。分析下实现思路。
demo4
让ChatGPT写个kubernetes调度器。实现在生产环境中常提的一个扩展scheduler需求：根据节点的真实负载调度pod，而不是根据默认的pod request和node capacity（过滤和计算权重后）调度pod。
写了一半写不下去了，重新问，这次干脆用。。。省略了实现
需求的实现思路
这种需求调度器的设计工作可大可小。往小了设计，就是监测几个关键指标，比如节点cpu的负载，调度pod。具体点说就是写一个cpu的监控脚本，根据cpu的使用情况对节点进行打分，优先调度到cpu使用率低的节点，再复杂点设计，可以通过pod的yaml配置属性对cpu设定阈值，比如超过70%，则过滤掉该节点，然后将过滤后的节点，按照cpu使用情况打分，cpu使用率越低的节点分值越高，最后将pod调度到分值最高的节点。
往大了设计。多维度监测节点的很多指标，这时候自己写监控工作量就太大了，往往需要用上普罗米修斯。配置的维度也可以复杂化，比如配置可以配置根据某一个或某几个监控指标进行调度，可配置是瞬时的负载，还是过去一分钟，过去30分钟或者其他一段时间的平均负载。可以配置权重打分的时候是否要考虑过去一段时间的负载的波动，波动大的分值就低些，波动小的分值就高些。
因为节点负载时动态变化的，还可以加入预测模型，预测算法，甚至AI来预测。
如果希望随着负载的动态变化而动态调整pod，还要加上定时任务，动态调整pod而不是仅仅在创建pod的时候依靠负载调度器调度pod。这个功能腾讯云，阿里云都有，看了看他们对产品的动态调度的介绍以及configmap的格式参数，基本就是社区的动态调度直接拿来用了。
为何要提这样的需求
为何要提这样的需求，就是一个字钱。
原生的调度器对pod的调度是根据资源请求和节点可分配资源来调度的。资源请求是创建pod的时候配置的，是人为设定的，往往是预留了应用pod足够的资源余量，绝大多数情况实际pod运行中的平均负载远远低于这个值，就会导致资源极大浪费。另外，就算是预估应用的实际负载后配置的pod最低request，或者干脆不配置pod request。这样做是可以提高资源利用率，并且基本pod也能运行，但是不加管控，很容易导致资源耗尽pod频繁被驱逐。在资源耗尽时，kubernetes原生自带节点压力驱逐功能通过驱逐pod保持其他pod正常运行。
从上面看出来，通过原生调度器，要么会造成资源极大浪费，要么造成资源分配不公平（有的节点忙，有的节点闲），要么会导致pod频繁驱逐。
设计一个好的根据节点使用情况来调度的调度器，可以既提高吞吐量（就是节点资源的利用率），又避免不必要的资源竞争。
Kubernetes集群自用就是提高资源利用率降低成本，对外售卖就可以如同Openstack Nova实现的虚拟机超分配置，让云厂商超卖虚拟机一样超卖容器，实现丰厚的利润。
转载请注明来源，欢迎指出任何有错误或不够清晰的表达。可以邮件至 backendcloud@gmail.com
