关于混合部署方案的设想

发表于 分类于 阅读次数：

理论依据

在时效性上来区分任务，常规的任务一般分为在线任务和离线任务。其中在线任务消耗的资源相对较少，但是要求相应时间较短，比如 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 则会带来更多的想象空间。