[整个过程行云流水]整个过程##如下：根据预测值计划pod

# # # #根据预测值计划Pod

该框架将调度过程分为以下五个阶段：排序过滤分数批准绑定。

排序：调度队列中的Pod排序筛选：过滤不符合Pod执行要求的节点分数：批准通过筛选阶段的节点分数：选择分数最高的节点并确定是否绑定：将Pod调度到最后选择的节点

# # #多维资源支持

对于业务安全传统服务，除了CPU内存和磁盘大小之外，磁盘IO网络IO也对业务运营至关重要。因此，在收集Pod监视数据时，将进一步收集这两个维的数据，并根据时间表进行计算。此外，即使业务有额外的资源维度，也可以轻松扩展。这解决了有限资源层面的问题。

# # # #整个阵列

资源平衡是解决同一Pod资源使用差异的重要方法。其中，资源平衡必须考虑到不同层面的资源平衡。如果Pod仅在需要调度时考虑平衡，则在Pod调度后群集的总体部署情况发生变化时，平衡也会受到破坏。因此，为了实现整个群集的长期资源平衡，必须定期重新计划整个群集。这种整体编制还可以解决多维闲置资源碎片化问题。整体编制大致分为两个阶段。

# # #计算部署方案

部署方案主要需要实现两个目标。

压缩多个维度的资源，以便在节点层级平均分配多个维度的资源

这种目标抽象是多维包装问题，在包装的同时必须保持多维平衡。为了解决这种类型的问题，主要有以下算法：

多维包装问题的难点之一是求解容易陷入局部最优解。此外，集群中的Pod数量一般为数万个，在包装问题上规模较大，因此决定使用遗传算法解决最佳部署方案。这是因为它具有超越局部最佳解决方案的特性，并且与大型解决方案相比性能更好。。

对于遗传算法，多维包装问题的可行解决方案可以设计成染色体。

算法的整个过程大致如下：

以我们在线环境中的重庆集群为例，目前集群使用69个节点，计算部署方案后，只要使用27个节点，就可以满足所有Pod运营，系统成本将减少**61%**。此外，为了确保服务质量，在计算部署方案时，节点的每个维资源的最大利用率设置为80%以下，有可能进一步压缩。同时，各资源层面也很均衡。下图以CPU内存为例，显示了部署方案中的资源平衡。

如图所示，除了最后一个节点不符合的情况外，其他节点接近目标的80%利用率。对于内存，大多数节点也在60%到80%的间隔内。

# # #应用部署方案

部署方案旨在使用最少的节点来容纳当前所有Pod，并尽可能压缩资源的使用。这将节点分为两部分。

热节点：在架构中放置Pod的节点冷节点：在架构中释放空间的可用节点，可用于降低机架或冗馀。

对于大型群集，实施部署方案是一个耗时的过程，在此期间，以前的Pod可能会发生变化，例如容量扩展。缩小的话，本来压缩的资源的使用就不会那么密集了。对于扩展或新业务部署，必须释放节点资源以容纳新创建的Pod。在实际使用中，建议评估未来使用情况，然后在冷节点上分割此部分保留资源。剩下的冷节点禁止新的Pod调度，从而防止在部署方案生效后上一步中清空的空闲节点被新创建的Pod占用，从而无法直接降低。

此外，在节点上实际应用部署方案面临两个主要挑战。

如何在架构中指定的节点上调度Pod，以便在调度Pod时不影响业务运营。

# # # # #时间表

筛选：根据待定Pod的部署方案，筛选已有足够Pod数的节点分数。也就是说，增加热节点分数减少冷节点分数给热节点分配Pod优先级

# # # # #确保业务正常运行

应用部署方案无法避免群集中的某些Pod被重新配置。这里的核心目标除了实现部署方案外，还必须确保正常运行，不影响业务。不影响业务运营的一个重要前提是服务网格的改造。这一内容在IEG-大规模游戏安全实时计算服务的祥云实践的第3.2节中简要介绍。这里不再详细说明。

另外，为了避免日程影响业务的正常运行，必须根据业务类型实施不同的日程政策。

# #无状态服务

无状态服务意味着即使Pod立即停止，也不会影响当前业务。对于这些类型的服务，必须确保在同一时间点指定比例的Pod正常提供服务。这项工作可以通过设置准备探针和生存探针来完成，同时企业方面必须支持灰度。这样，在调度下一个Pod批时，新启动的Pod可以正常提供服务。

# #弱状态服务

弱状态服务意味着立即停止Pod会影响当前业务，但不会致命。对于此服务，您可以在服务访问较少的时间内安排时间，从而进一步优化。

# #强大的状态服务

# #灾难恢复

基于Pod预测值的计划存在以下风险：

在第一种情况下，可以在Pod上安装生存探针，以监视Pod的状态。如果Pod经常不健康，则需要进一步确认原因是否存在其他主要资源维度，或者是否需要调整节点的预计资源利用率。

# #废除低负载节点

如上所述，通过整体编制解决多维闲置资源碎片化问题，但整体编制的整个过程需要很长时间，无法快速回收资源。在实际生产环境中，对于一些可预测的流量峰值，业务会提前扩展，因此需要添加新的节点资源。如果流量激增，业务将再次缩减，以前添加的节点资源将闲置。但是，这些闲置资源不能直接收回。因为“塌陷”不能准确地塌陷以前扩展的Pod，而且在新节点架期间，旧Pod也可能被保留。(威廉莎士比亚，Northern Exposure因此，业务缩减后经常发生的情况是，直接添加的节点负载很低，但上面只有少量的业务Pod仍在运行。

在这种情况下，如果为了解决大炮打蚊子的嫌疑，采用以前的总体编制方案，我们就选择了另一个简单直接的解决方案。。

筛选低负载节点要驱逐上面的Pod，必须在不影响业务服务质量的情况下执行。正式降低节点，完成成本节约。