云原生系统架构优化（三）节点弹性伸缩

 之前写过一篇K8S云原生系统的弹性伸缩优化方案

K8S云原生系统架构优化（三）弹性伸缩_extendedhpa.option: '{"downscalewindow-CSDN博客https://blog.csdn.net/weixin_53439529/article/details/132618655在这篇文章中只描述了负载（pod）弹性伸缩的方式，而没有详细介绍节点弹性伸缩，原因如下：

系统是使用固定容量的物理机，目前资源也达不到扩大和虚拟化，所以暂时不做节点弹性伸缩策略。

其实这也是自建K8S集群的一个普遍的问题，那就是很难实现节点层也就是虚拟机层面的弹性伸缩，集群的规模是固定大小的（后面再解释为什么自建的很难实现）。

什么是节点弹性伸缩？

节点弹性伸缩 即资源层弹性， 主要是集群的容量规划不能满足集群调度容量时，会通过弹出云服务器或 云容器实例 等资源的方式进行调度容量的补充。

有人可能会疑惑，弹性伸缩不就是pod容器的弹性吗？其实这只是云原生弹性的一种，有很多从业者（特别是从业爱好者，对概念很热爱，但是实操基本靠嘴的在我这里都是从业爱好者）跟风学了几个术语就天天吆喝，实际上连自家的产品可能都没用过（说的就是那几个大云的售前、销售、方案等等），分不清水平弹性伸缩和垂直弹性伸缩的就别参与云原生的讨论了，还得给你扫盲。

当然，水平弹性伸缩和垂直弹性伸缩也只是便于理解的说法，严格来说，云原生的弹性应该包括：工作负载弹性伸缩（HPA）和节点弹性伸缩（CA）。工作负载弹性伸缩即调度层弹性，主要是负责修改负载的调度容量变化，可以直接手动调整应用的副本数，也可以通过插件和策略调整副本数，调整的副本数会改变当前负载占用的调度容量，从而实现调度层的伸缩，在之前那篇文章就是讲这个功能。

为什么要实现节点的弹性伸缩？

很多人不了解这个功能的重要性，其实可以说没有节点弹性伸缩能力的系统不算真正的云原生系统。可以反向思考一下：如果一个系统没有节点弹性伸缩能力，会发生什么？

第一个问题就是资源利用率低。

如果系统不具备节点弹性伸缩的能力，那么用户只能按照业务高峰期预留资源，除非业务高峰期是在固定时间出现且在该时间之前能保证交付需要的虚拟机资源，否则一定会存在超配问题，即按照预估业务高峰期需求申请资源，但是这些虚拟机长期利用率很低，等于大量的资源和成本浪费了。

第二个问题就是扩容比较麻烦。

这个问题和一开始说的自建K8S无法节点弹性伸缩是一个原因，无法弹性伸缩的集群可以视为固定容量的集群，这个集群释放虚拟机也就是缩容比较简单，因为云原生系统是支持pod的自动漂移的，不能实现的可以看这一篇。

K8S云原生系统架构优化（一）可用性_statefulset部署无法自动转移-CSDN博客https://blog.csdn.net/weixin_53439529/article/details/132575756但是集群新增虚拟机也就是扩容需要解决一个问题，那就是怎么把这个虚拟机加到集群里面去？K8S在部署的时候会往master节点和worker节点部署不同的组件，组件之间有关联关系，是K8S部署的时候自行建立的，作为用户，后续新增进去的节点如何建立这个关联关系？这个问题我也不知道，因为我自建的集群确实没这么做过。

那么云服务的这个功能是怎么实现的呢？

以HW公有云为例，云容器引擎服务（CCE）在购买的时候只交付一个K8S的master集群，应该是三服务器的，但是三个服务器不开放给用户，用户只能从控制台操作。只有master节点当然是不可用的，所以还需要用户再购买worker节点，这时候可以选择固定的几个节点，或者选择有上限的节点池（这个上限是整个集群可用的最大规模上限），比如用户通过对业务预估认为全年业务高峰也不超过10台服务器，日常稳定在5台服务器左右，那么可以先购买5台服务器，节点池上限设为10或超过10一点。这个3master+5worker的集群如果正常运行业务，观察一下资源利用情况，可以设置弹性伸缩，实现步骤看下文。对于自动加进来的节点，开通虚拟机的过程中就会自动部署K8S需要的组件，加进这个集群，同时部署一些厂商需要的东西（计费什么的）。虚拟机正常运行起来，pod就可以自动漂移到这个节点，原来的几个节点的压力就会减小，如果设置CPU利用率在30-70%之间伸缩，那么最终就是让每个worker的资源利用率都处于30-70%之间。

弹性伸缩的关键

自建不考虑，只说云服务厂商提供的云容器引擎要实现节点的弹性伸缩，关键是什么？答案是弹性计费。弹性计费是一种计费方式，按照用户的实际使用时长*每小时单价来核算费用，先用再付。目前大部分用户是按照包年包月计费方式的，也就是一个月的费用或者一年的费用提前预付。

我们可以假设这么一种情况：如果按照大部分用户使用的包年包月计费，假设包月吧，然后你开通了弹性伸缩，白天业务量大，不定时会加进来几台虚拟机，然后晚上又释放掉了，月底云服务商找你核算费用，按照你使用的最高数量来核算月单价*数量你肯定不干，但是按照你一开始买的数量来核算云厂商肯定也不干，这时候就产生分歧，按多少来算呢？没有答案，因为不定期不定量地加进来的，谁也不知道是多少。

这就是为什么要配合弹性计费才能实现节点弹性伸缩，因为这个技术其实并不难，有点规模的云厂商都能做，问题就是弹性计费的实现才难，这关系到另一个部门就是成本核算部门，业务上打通了技术上才能实现对吗。

说到这里提醒一下，有想要用这个功能的最好慎重，这个功能很好，但是问题在于弹性计费的单价太贵了！有的用户可能为了节省成本才开通节点弹性伸缩的，为的是业务低谷期可以释放掉一部分服务器，但是那句话怎么说？你可能小赚，卖家永远不亏。人家可以把弹性计费的虚拟机单价提高一倍甚至几倍，这样算下来就把费用找回去了。

怎么实现节点弹性伸缩？

节点弹性伸缩就是这篇文章主要介绍的功能。节点弹性伸缩实现方式：Autoscaler （简称 AS）是 Kubernetes 提供的集群节点弹性伸缩组件，可以插件形式安装，安装后设置弹性伸缩策略。

通常情况下，工作负载弹性伸缩和节点弹性伸缩 需要配合使用，因为 HPA 需要集群有足够的资源才能扩容成功，当集群资源不够时需要 CA 扩容节点，使得集群有足够资源；而当HPA 缩容后集群会有大量空余资源，这时需要 CA 缩容节点释放资源，才不至于造成浪费。

只用HPA行不行？

其实也不是不行，但是要注意HPA策略不要设太大的副本上限，且及时监控资源的使用情况，因为当业务高峰期到来，压力剧增的情况下，HPA策略设置比较高的副本上限可能会导致副本在极短时间内达到这个上限，对集群的资源压力较大。

只用CA行不行？

其实也行，但是意义不太大，除非是在开发部署阶段的系统，或者迭代期的系统，会在极短时间内新增大量的负载，这样对虚拟机的压力较大，用CA及时扩容分担虚拟机的压力。但是如果集群内负载数量稳定，且每个负载的副本数也稳定，加上CA功能更可能长期没有什么变化，加不加一个样。能不能应对业务的高峰期呢？不行。因为没有HPA对副本弹性伸缩，只会让某些负载的压力打满，而且持续满负荷而已，超负荷会宕掉服务。

上图是HPA+CA联合工作的流程， HPA 根据监控指标进行扩容，当集群资源不够时，新创建的 Pod 会处于 Pending 状态， CA 会检查所有 Pending状态的Pod ，根据用户配置的扩缩容策略，选择出一个最合适的节点池，在这个节点池扩容。

预期效果

以一个公有云容器服务中运行的测试系统为例，节点弹性伸缩的过程如下：

模拟业务稳定运行中

开通弹性伸缩并设置伸缩策略

模拟业务压力增大：

自动弹出2虚拟机，按运行开始时间计费

模拟业务压力减小

自动释放多余虚拟机