leason的博客

Pod的优雅上下线依赖k8s的监控检查机制，以及 Pod lifecycle Hooks，通过这些kubernetes的机制，配合服务发现的流量管理机制，实现业务的优雅上下线。

相对于 Koordinator 专门为混部而生的软件，Crane以 Finops 为出发点，二者相比Koordinator更适合我们，在离线混部也是下一步计划。基于上述情况，高峰时 Cpu 利用率仅25%肯定不是合理的情况，业界做的好的50%+。2. 在1中的情况下，扩容部分节点缓解集群压力时，新上的节点会迅速被热点Pod占满，导致节点负载升高，再次触发重调度。需要前置打散热点节点，这就需要对应用进行资源画像，在调度中分散这种类型的应用，避免业务高峰热点节点的产生。本文由博客一文多发平台。

Webhook就是一种HTTP回调，用于在某种情况下执行某些动作，Webhook不是K8S独有的，很多场景下都可以进行Webhook，比如在提交完代码后调用一个Webhook自动构建docker镜像准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。可以定义两种类型的准入 Webhook， 即验证性质的准入 Webhook 和变更性质的准入 Webhook。变更性质的准入 Webhook 会先被调用。它们可以修改发送到 API 服务器的对象以执行自定义的设置默认值操作。

调用下线完毕之后，再修改Pod的标签，这个标签的修改可以让Pod脱离Workload的控制，变成孤儿Pod，注意修改Pod标签也要让service的selector选择不到这个Pod，这样Pod也就从endpoint中移除，服务发现也就感知不到这个节点了。首先要主动调用服务下线的方法，理论上这个调用应该会配再Pod的prestop钩子中，这样Pod被删除的时候，会先调用这个方法，然后再删除Pod。线上集群中，业务跑着跑着，突然发现有个Pod上出现大量错误日志，其他的Pod是正常的，该如何处理呢？

GPUManager支持共享和独占两种模式，当负载里tencent.com/vcuda-core request 值在0-100情况下，采用共享模式调度，优先将碎片资源集中到一张卡上，当负载里的tencent.com/vcuda-core request为100的倍数时，采用独占模式调度，需要注意的是GPUManager仅支持0~100和100的整数倍的GPU需求调度，无法支持150，220类的非100整数倍的GPU需求调度。进程和进程间的显存和算力没有任何限制，谁抢到就是谁的。