关于混合部署方案的设想

发表于 分类于 阅读次数：

理论依据

在时效性上来区分任务，常规的任务一般分为在线任务和离线任务。其中在线任务消耗的资源相对较少，但是要求相应时间较短，比如web服务；而离线任务则对时效性要求不高，但是任务量大，需要的资源更多。因此把两种项目混合部署在一起就叫做混合部署。

大多数进程可以分为I/O密集型和CPU密集型。I/O密集型程序将大多数时间都花在了I/O操作而不是运算上，而CPU密集型程序正好相反，将大多数时间花在了运算上，而很少产生I/O操作。选出一个I/O密集型和CPU密集型程序的良好组合，对于长期调度器是非常重要的。否则，假如所有的程序都是CPU密集型的，那么I/O队列将会几乎永远都是空的，这样就会导致一些设备从来没被使用过，系统资源分配就是不均衡的。显然，性能极佳的系统必然是CPU密集型和I/O密集型程序的组合。在现代操作系统中，这被用来保证实时进程能获得足够的CPU时间来完成任务。但我们的当前绝大部分项目并不能做到资源的和谐组合——cpu使用率远低于内存使用率。这样的特点也方便混合部署的时候只需要考虑内存的瓶颈即可。

资源使用率现状

通俗来讲，我们希望使用提高资源使用率的同时降低成本。任务类型的分类是提高资源利用率的理论依据，只不过迫于现实，实践过程中会有些偏差。
当前的现状，大部分CPU平均使用率长期在30%以内徘徊，极大的浪费资源。

而对于内存调整的空间较为有限，个别实例有操作空间。

当前的实例用途类型基本分为三类：

  • 大数据集群
    • 夜间使用率高，白天使用率低
    • CPU和内存需求较高
  • 微服务
    • 白天使用率微高，夜间极低
    • CPU使用率较低，内存使用率微高
  • 中间件
    • 波动较小
      自2021年起始，累计增加了约8~10个微服务项目，关停1台主机但并没有增加新的实例主机。单纯的微服务集群内存使用率峰值只增加了不到5个百分点。这些数字说明了一些可能的现象：
  • 业务量有降低
  • 代码性能更好
    当前保有实例45台，每年的开支大约在32万，是不是有可能降低10%~15%？

解决方案

现有ECS基本可以分为2种类型的实例，离线型和在线型。其中离线型的实例配置较高，常规配置为16核32G，近期保有量为3~5台。因此之后一段时间可以将部分微服务部署在相应的节点。

规划节点

节点角色

  • 003~005 轻量级节点
  • 006~007 常规级节点

潜在问题

轻量级的实例部署了多种大数据相关的服务，因此只可部署少量的微服务，避免极端情况下微服务和大数据服务资源的抢夺。常规级的节点可以部署更多pod。。同时，两类服务共存会带来一些潜在的问题：

  1. 极端调度；
  2. 抢夺资源；
  3. 网络关系.

以上三个问题中最重要的是第一个问题，第一个问题处理好后，第二个问题就会很好处理。而第三个则是永远无法避免的，能做的只能是选择网络依赖最小的微服务。因此，重点解决调度的问题。

  1. 节点选择。在默认情况下，pod的调度是由scheduler-crontroller根据节点资源和有限制来自动完成的。但是在目前的情况下我们希望微服务部署在某些节点和少量部署在另一部分节点上。对于指定节点部署可以使用NodeSelector设定的标签来选择节点，原理是给node设置标签，scheduler就会把pod调度到具有该标签的node上。
  2. 资源限制。每个pod都会有cpu和memory的limits限制，因此再加上pod的数量限制，就可以避免服务间的资源抢夺了。设置–max-pods较为简单，修改各node kubelet启动参数即可，较容易实现。
  3. 均匀调度。每个微服务默认期望部署在至少两个节点，常规实例和大数据实例。对于这个问题需要用节点亲和性和pod亲和性来处理。节点亲和性指定了将pod调度到节点的权重或其他规则。pod亲和性基于已经在节点上运行的pod的标签来约束pod可以调度到的节点，而不是基于节点的标签。但是这这两种方式不适合当前版本的kubernetes，只能在高版本的集群上使用。
    综上所述，潜在问题可以大部分通过参数调整达到期望的状态，基本满足正常使用。如果期望达到更好的状态，则必须升级kubernetes集群。

部署节点

部署kubelete client

常规部署，无特殊处理，修改--max-pods。

网络安全

  • 需注意大数据集群和业务服务的网络互通，重点在安全组的配置

预期目标

目前保有143个pod，加上部分服务的编排处理，预计全部的pod会到达160个。通过混合部署，预计能释放20~30个pod的资源潜力，约至少32G内存。

总结

当年内预期目标ECS部分的开支控制在30万内，去年约31万。当前阶段通过资源混部来实现资源的错位运用可以提高一些资源利用率。接下来通过pod的资源利用率监控可以更合理的进行资源限制，释放过剩资源。之后kubernetes的版本升级之后带来的亲和性功能和hpa、vpa、ca则会带来更多的想象空间。