HPA-提升k8s集群资源利用率实践

原创董杰雄之家技术

总篇135篇 2022年第10篇

前言

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让应用中的Pod个数自动调整呢？这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放。

简介

HPA全称是 Horizontal Pod Autoscaler，也就是对k8s的Pod进行自动水平扩缩容机制(scale)，也是k8s里使用需求最广泛的一种Autoscaler机制，在开始详细介绍HPA之前，先简单梳理下k8s autoscale的整个大背景。

其本质是解决资源与业务负载之间供需平衡的问题，随着业务需求和部署规模的增大，k8s集群就要相应扩容计算资源，集群扩容的最直接的办法是新增资源，一般单机器很难垂直扩展（k8s node也不支持），所以一般都是直接增加节点。但是随着机器的不断增加成本也不断加大，而实际上大量服务大部分时间负载很低导致机器的整体使用率很低，一方面业务为了应对每日随机流量高峰会把副本数尽量扩得很高，另一方面业务方并不能准确评估服务实际需要的CPU等资源，也出现大量浪费。

工作机制

核心的工作机制简单来说就是，先为应用设定一个期望的资源使用率或使用量，然后同过监控指标实时获取当前的资源使用率或使用量，然后计算出期望的副本数，对应用进行扩容或者缩容，监控指标主要来自各种metrics。

首先可以看一下HPA在k8s中的结构，这里找了一个k8s官方给出的HPA例子，我在关键字段上给出一些注释方便理解。

apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata:  name: php-apache  namespace: defaultspec:  # HPA的伸缩对象描述，HPA会动态修改该对象的pod数量  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: php-apache  # HPA的最小pod数量和最大pod数量  minReplicas: 1  maxReplicas: 10  # 监控的指标数组，支持多种类型的指标共存  metrics:  # Object类型的指标  - type: Object    object:      metric:        # 指标名称        name: requests-per-second      # 监控指标的对象描述，指标数据来源于该对象      describedObject:        apiVersion: networking.k8s.io/v1beta1        kind: Ingress        name: main-route      # Value类型的目标值，Object类型的指标只支持Value和AverageValue类型的目标值      target:        type: Value        value: 10k  # Resource类型的指标  - type: Resource    resource:      name: cpu      # Utilization类型的目标值，Resource类型的指标只支持Utilization和AverageValue类型的目标值      target:        type: Utilization        averageUtilization: 50  # Pods类型的指标  - type: Pods    pods:      metric:        name: packets-per-second      # AverageValue类型的目标值，Pods指标类型下只支持AverageValue类型的目标值      target:        type: AverageValue        averageValue: 1k  # External类型的指标  - type: External    external:      metric:        name: queue_messages_ready        # 该字段与第三方的指标标签相关联，（此处官方文档有问题，正确的写法如下）        selector:          matchLabels:            env: "stage"            app: "myapp"      # External指标类型下只支持Value和AverageValue类型的目标值      target:        type: AverageValue        averageValue: 30

Metrics的分类

Resource支持k8s里Pod的所有系统资源（包括cpu、memory等），但是一般只会用cpu，memory因为不太敏感而且跟语言相关：大多数语言都有内存池及内置GC机制导致进程内存监控不准确。
Pods类型的metrics表示cpu，memory等系统资源之外且是由Pod自身提供的自定义metrics数据，比如用户可以在web服务的pod里提供一个promesheus metrics的自定义接口，里面暴露了本pod的实时QPS监控指标，这种情况下就应该在HPA里直接使用Pods类型的metrics。
Object类型的metrics表示监控指标不是由Pod本身的服务提供，但是可以通过k8s的其他资源Object提供metrics查询，比如ingress等，一般Object是需要汇聚关联的Deployment下的所有的pods总的指标。
External类型的metrics也属于自定义指标，与Pods和Object不同的是，其监控指标的来源跟k8s本身无关，metrics的数据完全取自外部的系统。

核心代码

基于 kubernetes 1.13 版本解读部分HPA controller核心代码，版本不同行数变化，但基本逻辑变化不大。篇幅限制，将会省略部分非核心逻辑代码, 使核心逻辑更清晰。

1.Run函数

位于 /pkg/controller/podautoscaler/horizontal .go:152

func (a *HorizontalController) Run(stopCh <-chan struct{}) {	.....	// start a single worker (we may wish to start more in the future)	go wait.Until(a.worker, time.Second, stopCh)
	<-stopCh}

在 a.work 函数里执行for死循环，然后每次从队列里面提取item计算，最后决定是否要扩缩容。


func (a *HorizontalController) worker() {	for a.processNextWorkItem() {	}	klog.Infof("horizontal pod autoscaler controller worker shutting down")}
func (a *HorizontalController) processNextWorkItem() bool {	key, quit := a.queue.Get()	if quit {		return false	}	defer a.queue.Done(key)
	deleted, err := a.reconcileKey(key.(string))	if err != nil {		utilruntime.HandleError(err)	}	.....}

2.Reconcile

Reconcile（这个词是Kubernetes 的核心，翻译为“调整“，即将实例的状态调整为期望的状态。此处，对于 hpa 的实例的每个事件，都会按照特定的逻辑调整目标实例的 Pod 的副本数量）。

对 key 进行 reconcile 的调用栈：

reconcileKey ->

reconcileAutoscaler ->

computeReplicasForMetrics ->

ScaleInterface Update

简单来说就是先从Informer中拿到 key 对应的HorizontalPodAutoscaler资源实例；然后通过HorizontalPodAutoscaler实例中的信息，检查目标资源的Pod 负载以及当前的副本数，得到期望的 Pod 副本数；最终通过 Scale API 来调整 Pod 的副本数。最后会将调整的原因、计算的结果等信息写入HorizontalPodAutoscaler实例的 condition 中。

reconcileKey

func (a *HorizontalController) reconcileKey(key string) (deleted bool, err error) {	.....	hpa, err := a.hpaLister.HorizontalPodAutoscalers(namespace).Get(name)	.....	return false, a.reconcileAutoscaler(hpa, key)}

reconcileAutoscaler

func (a *HorizontalController) reconcileAutoscaler(hpav1Shared *autoscalingv1.HorizontalPodAutoscaler, key string) error {	//1.转换hpav1到autoscalingv2.HorizontalPodAutoscaler版本，便于后面的逻辑处理；	hpaRaw, err := unsafeConvertToVersionVia(hpav1, autoscalingv2.SchemeGroupVersion)	......	//2. 获取scale，包含当前的副本数和定义副本数等信息；	scale, targetGR, err := a.scaleForResourceMappings(hpa.Namespace, hpa.Spec.ScaleTargetRef.Name, mappings)	.....	rescale := true	//3.对比scale中定于副本及当前副本和hpa中的MaxReplicas和MinReplicas	if scale.Spec.Replicas == 0 {
		//如果scale定义副本数等于0，则此次不做scale操作；		desiredReplicas = 0		rescale = false
	} else if currentReplicas > hpa.Spec.MaxReplicas {
		//如果scale定义副本数大于hpa定义的MaxReplicas，将期望副本数设定为MaxReplicas		desiredReplicas = hpa.Spec.MaxReplicas
	} else if hpa.Spec.MinReplicas != nil && currentReplicas < *hpa.Spec.MinReplicas {		//如果scale定义副本数小于hpa定义的MinReplicas，将期望副本数设定为MinReplicas		desiredReplicas = *hpa.Spec.MinReplicas	} else if currentReplicas == 0 {		//如果scale当前副本数等于0，将期望副本数设定为1		rescaleReason = "Current number of replicas must be greater than 0"		desiredReplicas = 1	} else {		//通过hpa和metric计算副本数		metricDesiredReplicas, metricName, metricStatuses, metricTimestamp, err 		= a.computeReplicasForMetrics(hpa, scale, hpa.Spec.Metrics)		.....		rescaleMetric := ""		if metricDesiredReplicas > desiredReplicas {			desiredReplicas = metricDesiredReplicas			timestamp = metricTimestamp			rescaleMetric = metricName		}		if desiredReplicas > currentReplicas {			rescaleReason = fmt.Sprintf("%s above target", rescaleMetric)		}		if desiredReplicas < currentReplicas {			rescaleReason = "All metrics below target"		}		desiredReplicas = a.normalizeDesiredReplicas(hpa, key, currentReplicas, desiredReplicas)		rescale = desiredReplicas != currentReplicas	}
	if rescale {		//更新副本数		scale.Spec.Replicas = desiredReplicas		_, err = a.scaleNamespacer.Scales(hpa.Namespace).Update(targetGR, scale)		.....	} else {		klog.V(4).Infof("decided not to scale %s to %v (last scale time was %s)", reference, desiredReplicas, hpa.Status.LastScaleTime)		desiredReplicas = currentReplicas	}
	a.setStatus(hpa, currentReplicas, desiredReplicas, metricStatuses, rescale)	return a.updateStatusIfNeeded(hpaStatusOriginal, hpa)}

computeReplicasForMetrics

根据Metric和hpa的设定的期望值计算实际的副本数进行更新。由于Metric的种类较多，代码较多，本文就不一一展示了。但是逻辑并不是很复杂，核心算法如下：

期望副本数 = ceil[当前副本数 * (当前指标 / 期望指标)]

例如如果配置 target value 是100m，当前从metrics接口读取到的 metrics value 是 200m，说明最新的副本数应该是当前的 200m/100m=2.0倍，如果当前副本数为 2，则HPA计算后的期望副本数是2*2.0=4；而如果当前从metrics接口读取到的 metrics value是 50m，说明最新的副本数应该是当前的 50m/100m=0.5倍，也就是最终scale的副本数将为1。当然实际上当前的metrics value并不一定就只有一个值，如果是 Resource或者Pods类型的metrics，实际上 GetMetrics 会返回一批关联的Pods对应的metrics数据，一般需要做一个平均后再与target的metrics的做比较。

此外，为了保证结果尽量精确，metrics的计算都是浮点数计算，但是最终的副本数肯定要是整数，为了统一HPA控制器在最后，都会对计算出的浮点数副本数向上取整，也就是上面公式里最外层的ceil函数。

存在的问题

1.HPA在启动时单集群单协程，在大规模集群或应用使用波动频繁的场景下，会有一定的性能问题，后续官方可能会进行优化。

func (a *HorizontalController) Run(stopCh <-chan struct{}) {	.....	// start a single worker (we may wish to start more in the future)	go wait.Until(a.worker, time.Second, stopCh)
	<-stopCh}

2.HPA目前只支持通过Requst资源进行计算，在特定场景下可能需要通过Limit计算。

之家云实践

之家云容器应用资源和副本数的设置限制较少，存在很多副本数设置不合理的情况。目前已有近100个应用配置了HPA，但无论是应用占比还是策略触发活跃度，仍处于初、中级阶段。后续将会通过监控筛选出资源利用率低、副本数设置过大的应用，通过运营推广更多的应用使用HPA。于此同时我们将会有程序实时记录每一次 HPA伸缩的情况（副本变化情况、触发原因等）来评估HPA对资源优化产生的效果，并持续对HPA进行优化。

总结

这篇文章主要是给大家介绍HPA的工作机制及核心源码，HPA作为Kubernetes原生支持的特性，基本能满足大多数自动水平伸缩的场景，但在一些极端情况下仍存在一些性能问题，需要根据实际情况进行优化。

参考资料

https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/

https://github.com/kubernetes/kubernetes/tree/master/pkg/controller/podautoscaler

作者简介

汽车之家

董杰雄

云平台部

2020年加入汽车之家，负责容器云开发与维护工作

阅读更多

▼ 关注「之家技术」，获取更多技术干货 ▼

继续滑动看下一个