云原生：使用HPA和VPA实现集群扩缩容
1 背景
我们之前介绍过，随着业务流量上涨之后，我们的系统需要适时的进行扩容。
数据存储层我们也介绍过MySQL的扩容 Scale UP（纵向扩展） 和 Scale Out（横向扩展）
- 垂直拆分（Scale Up 纵向扩展）：包括垂直分库、垂直分表
- 水平拆分（Scale Out 横向扩展）：包括库内分表、分库分表
详细可以参考笔者这几篇：
《MySQL全面瓦解28：分库分表 》
《MySQL全面瓦解29：分库分表之Partition功能详解》
《数据库系列：数据库高可用及无损扩容》
存储层有高效动态的扩缩容机制，那计算服务也应该同步有这种能力，这样才能保证流量上涨时能够快速扩容。
如下图， 蓝色部件是扩容的部分，每一分层都有自己的扩容机制。
现在服务大都为云上服务，所以接下来我们详细介绍下Kubernetes中的HPA和VPA。
2 容器扩缩容介绍
2.1 先看下 HPA 和 VPA 的概念
VPA（Vertical Pod Autoscaler）和HPA（Horizontal Pod Autoscaler）都是Kubernetes中的自动扩展功能，但它们的作用对象和扩展方式不同。
HPA（纵向）的作用对象是Pod的数量。 它通过监控CPU使用率、内存使用率等指标，根据预设的阈值自动调整Pod的数量（即当个集群副本的数量）。当Pod的CPU和内存使用率超过阈值时，HPA会自动增加Pod的数量；当使用率下降时，HPA会自动减少Pod的数量。
VPA的作用对象是Pod的资源需求，如CPU、内存等。 它通过监控Pod的资源使用情况，根据实际的资源需求自动调整Pod的资源限制和请求。当Pod的资源使用率高于资源请求时，VPA会自动增加Pod的资源Request和Limit；当资源使用率下降时，VPA会自动减少Pod的资源Requist和Limit。这种方式可以帮助优化资源利用率，避免资源浪费。
2.2 HPA实现详解
HPA（纵向）的作用对象是Pod的数量。可针对CPU使用率、内存使用率进行扩缩容配置，会根据期望指标，会触发扩容或者缩容，若同时有多个指标，会取Max值。
如下图：
解读下：
- 设计HPA资源，包含实现扩容的条件
- 策略Yaml应用到HPA控制器中
- HPA控制器监听Prometheus，获取多个Metrix指标，如内存、CPU、连接数等
- 当监听的数据值大于等于扩容条件的阈值的时候，执行扩容操作
- 修改 replication controller, deployment, replica set, stateful set 中的pod数量
- 控制器定期调整 副本控制器（replica set） 或 部署（deploy） 中副本的数量
算法解析：
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
即 (当前指标值 ➗ 期望指标值) ✖️ 当前副本数 ，结果再向上取整，最终结果就是期望的副本数量
举例说明：
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-example
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: hpa-example
minReplicas: 10 # Pod副本数下限
maxReplicas: 20 # Pod副本数上限
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 60 # 当CPU利用率大于60%或者内存占用大于60%的时候，执行调整
- 假设当前指标：CPU利用率 70%
- 期望指标：CPU利用率60%
- 假设当前副本数：10
- 期望副本数：ceil(10*(70/60))=12
- 最终总的Pod副本数应该是12，即扩容数量为2
- 注意扩容和缩容幅度不能超过 HorizontalPodAutoscaler 资源中的副本上下限
2.3 VPA实现详解
因为VPA影响的是Pod的Request和Limit这两个参数，所以我们先了解下这两个属性的含义。
1. Request表示容器在运行过程中所需的最小资源量，即容器启动时的资源保证。
当Pod被调度到节点上时，Kubernetes会确保该节点上至少有足够的资源来满足Pod中所有容器的Request值。如果节点的可用资源无法满足Pod的Request值，则不会被调度到该节点上，而是保持在Pending状态，直到找到满足条件的节点为止。
因此，合理设置Request值可以确保Pod的稳定性和可靠性。
2. Limit则表示容器在运行过程中可以使用的最大资源量，即容器可以消耗的资源上限。
如果容器的实际资源使用量超过了Limit值，Kubernetes会采取相应的措施来限制容器的资源使用，例如限制CPU使用率、杀死进程等，以确保不会因资源不足而导致系统崩溃或性能下降。
通过设置Limit值，可以有效地防止单个容器或整个Pod占用过多的资源，从而影响整个集群的性能和稳定性。
apiVersion: v1
kind: Pod
- apiVersion: v1
name: xx-default-756gh8588cc
namespace: xx-ns
spec:
containers:
name: xx-default
resources:
limits: # 对应上限最大值
cpu: "2"
memory: 8G
requests: # 对应下限最小值
cpu: 200m
memory: 500Mi
而 VPA 是Kubernetes的一种自动调整Pod资源请求(Request)配额的工具。通过VPA，您可以根据Pod的实际资源使用情况动态地调整其CPU和内存资源请求（Request），以实现更精细的资源管理和更好的资源利用率。
简单理解就是 取服务一定周期内（如8天内） CPU 和内存资源用量的 TP90 分位数据作为推荐值，可以参考kubernetes的算法
举例说明：
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
name: myapp-vpa-default
namespace: xx-ns
spec:
targetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp-vpa-default
updatePolicy:
updateMode: "Off" # 不直接进行修改
status:
recommendation:
containerRecommendations:
- containerName: msg-index-default
lowerBound: # 下限值
cpu: 480m
memory: "7117753323"
target: # 推荐值
cpu: 930m
memory: "8701517761"
uncappedTarget:
cpu: 930m
memory: "8701517761"
upperBound: # 上限值
cpu: 1100m
memory: "8841153193"
在这个配置中，我们定义了一个名为myapp-vpa的VPA，它将调整名为myapp的Deployment中的Pod的资源。
从输出信息可以看出，VPA对Pod给出了推荐值：Cpu: 930m，Memory: 8Gi，因为 updatePolicy 策略设置了updateMode: "Off"，所以不会主动更新Pod。
上面的案例可以通过下面的图进行演进：通过VPA的推荐，我们将Request值从 200m的CPU 和 500Mi 的内存，调整为 1 Core 的CPU 和 8Gi 的内存。
调优完成之后，资源分配更加合理，资源更充足，性能、稳定性更高。
3 总结
总的来说，HPA是通过自动调整Pod的数量来应对负载压力，而VPA是通过自动调整Pod的资源需求来优化资源利用率。它们可以配合使用，实现更加精细的自动扩展策略。保证流量动态变化的业务场景中实现资源的弹性伸缩，实现资源的最优合理性利用。
