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

【摘要】

原生的K8S集群系统架构优化——弹性能力优化，针对集群无法自动伸缩问题，进行梳理优化。

【案例正文】

【背景】

K8S云原生系统架构优化_xuyijing0103的博客-CSDN博客https://blog.csdn.net/weixin_53439529/article/details/132565188

在互联网时代，企业 IT 系统经常需要面对突发事件，各种预期内外的爆发性流量增长。通过容器技术部署密度提升和弹性降低计算成本。 K8s 可以监测业务上所承担的负载，如果这个业务本身的 CPU 利用率过高，或者响应时间过长， 它可以对这个业务进行自动扩容。

【问题】

集群已具备观测性的前提下，如何具备弹性伸缩能力？

【过程与结果】

【初步解决思路】

弹性伸缩能力非常简单，在达到可观测的基础上，设置弹性伸缩策略即可。

【解决方案】

        我们常说的K8S弹性伸缩，其实包含两个维度：

        工作负载弹性伸缩 ：即调度层弹性，主要是负责修改负载的调度容量变化。例如，HPA 是典型的调度层弹性组件，通过HPA 可以调整应用的副本数，调整的副本数会改变当前负载占用的调度容量，从而实现调度层的伸缩。

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

        两个维度的弹性组件与能力可以分开使用，也可以结合在一起使用，并且两者之间可以通过调度层面的容量状态进行解耦。一般来说大型业务系统在购买基础资源时不会按当前实际的资源占用量购买，而是预留充足的峰值占用资源量，这样就产生了资源的闲置和成本的浪费。所以比较合理的方案是预留峰值所需的容量，例如10台服务器的节点池，但是当下可能只使用3-5台，然后设置节点弹性伸缩，平时只按需使用少量资源，在业务高峰期可以迅速扩容到充足的容量。

      1. 节点弹性伸缩

       系统是使用固定容量的物理机，目前资源也达不到扩大和虚拟化，所以暂时不做节点弹性伸缩策略。但是可以简单介绍一下节点弹性伸缩设置：Autoscaler （简称 AS）是 Kubernetes 提供的集群节点弹性伸缩组件，可以插件形式安装，安装后设置弹性伸缩策略即可。

      2.负载弹性伸缩

      负载弹性伸缩是在实际中更常用的伸缩策略。

想要做到自动弹性伸缩，先决条件就是能感知到各种运行数据，例如集群节点、 Pod 、容器的 CPU 、内存使用率等等。而这些数据的监控能力Kubernetes 也没有自己实现，而是通过其他项目来扩展 Kubernetes 的能力，可以选以下 两个组件来实现该能力：

      1）Prometheus 是一套开源的系统监控报警框架，能够采集丰富的 Metrics （度量数据），目前已经基本是 Kubernetes 的标准监控方案。

      2） Metrics Server 是 Kubernetes 集群范围资源使用数据的聚合器。 Metrics Server 从 kubelet 公开的 Summary API 中采集度量数据，能够收集包括了 Pod 、 Node 、容器、Service 等主要 Kubernetes 核心资源的度量数据，且对外提供一套标准的 API 。

       安装metrics或prometheus后，需创建HPA对象来描述伸缩策略。HPA（Horizontal Pod Autoscaler）是用来控制Pod水平伸缩的控制器，HPA周期性检查Pod的度量数据，计算满足HPA资源所配置的目标数值所需的副本数量，进而调整目标资源（如Deployment）的replicas字段。

       

        使用 HPA （ Horizontal Pod Autoscaler ）配合 Metrics Server 可以实现基于CPU 和内存的自动弹性伸缩，再配合 Prometheus 还可以实现自定义监控指标的自动弹性伸缩。yaml参考：

      

kind: HorizontalPodAutoscaler
apiVersion: autoscaling/v2beta1
metadata:
  name: hpa
  namespace: default
  annotations:
    extendedhpa.metrics: '[{"type":"Resource","name":"cpu","targetType":"Utilization","targetRange":{"low":"20","high":"50"}},{"type":"Resource","name":"memory","targetType":"Utilization","targetRange":{"low":"20","high":"50"}}]'
    extendedhpa.option: '{"downscaleWindow":"5m","upscaleWindow":"3m"}'
spec:
  scaleTargetRef:
    kind: Deployment
    name: wordpress
    apiVersion: apps/v1
  minReplicas: 1
  maxReplicas: 4
  metrics:
    - type: Resource
      resource:
        name: memory
        targetAverageUtilization: 30
    - type: Resource
      resource:
        name: cpu
        targetAverageUtilization: 30

实现的目标是给wordpress这个deployment负载设置了基于内存和CPU的弹性伸缩，目标CPU和内存使用率都是 30%，上限是4，下限是1个。K8S会在负载的容器CPU和内存使用率达到这个值时自动弹性伸缩，但不会超过4个副本。

        要实现弹性伸缩，还需要一个重要的前提，那就是该负载有资源申请，否则metrics会报错：invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: missing request for cpu

意思是说负载没有申请CPU资源，都没有申请资源怎么判断是否超过资源上限呢？

        在yaml的spec.resources字段配置，limits 表示上限值，requests表示申请值。CPU和内存的计量单位分别是：

       1）Kubernetes 中，0.5 代表请求半个 CPU 资源。表达式 0.1 等价于 表达式 100m。CPU 的计量代表的是绝对值，而非相对值，例如，您请求了 0.1 个 CPU，无论您的节点是单核、双核、48核，您得到的 CPU 资源都是 0.1 核。

        2）内存的计量单位是 byte 字节。可以使用一个整数来表达内存的大小，也可以使用后缀来表示（E、P、T、G、M、K）。也可以使用 2 的幂数来表示内存大小，其后缀为（Ei、Pi、Ti、Gi、Mi、Ki）。单位写错会导致容器启动不起来。

        另外，不是所有的负载都需要做弹性伸缩，某些CPU使用量很低的服务会探测不到：invalid metrics (1 invalid out of 1), first error is: failed to get cpu utilization: unable to get metrics for resource cpu: no metrics returned from resource metrics API。意思是使用量太低了，该服务可能没有在用。可以用top pod指令找到所有的高资源消耗负载，然后有针对性地给这些负载设置资源申请和弹性伸缩策略。

        测试小tip：进入要弹性的负载容器，用以下命令加压：i=0 ;while true ; do i=i+1 ; done   这个循环会很快升高CPU使用率，看到副本弹到设定值停止即可。

【总结】

        当前还有一个遗留问题，那就是HorizontalPodAutoscaler（简称hpa）的版本，Kuboard的版本原因，只能显示autoscaling/v1版本的hpa，但是该版本只能扩容不能缩容，当停止加压CPU使用率降低下来，应该缩容到1个副本的，但是hpa状态是：

      status: 'False'
      lastTransitionTime: '2023-07-26T08:26:11Z'
      reason: DesiredWithinRange
      message: the desired count is within the acceptable range

意思是当前副本数满足期望数，因此hpa不会变更副本数了。使用很多办法尝试修改过很多次hpa版本，但是因为Kuboard限制始终无法生效。

        实测华为云CCE用的是autoscaling/v2beta1 版本的hpa，CPU使用率可以设置期望范围，比如50%-80%之间，低于50%的时候会自动缩容到1个。