Kubernetes 弹性伸缩全场景解读（二）- HPA 的原理与演进

 

前言

在上一篇文章 Kubernetes 弹性伸缩全场景解析 （一）：概念延伸与组件布局中，咱们介绍了在 Kubernetes 在处理弹性伸缩时的设计理念以及相关组件的布局，在今天这篇文章中，会为你们介绍在 Kubernetes 中弹性伸缩最经常使用的组件 HPA（Horizontal Pod Autoscaler）。HPA 是经过计算 Pod 的实际工做负载进行从新容量规划的组件，在资源池符合知足条件的前提下，HPA 能够很好的实现弹性伸缩的模型。HPA 到目前为止，已经演进了三个大版本，本文将会为你们详细解析 HPA 底层的原理以及在 Kubernetes 中弹性伸缩概念的演变历程。

HPA 基本原理

HPA 是根据实际工做负载水平伸缩容器数目的组件，从中能够提炼出两个很是重要的关键字：负载和数目。咱们能够用一个很是简单的数学公式进行概括：

下面举一个实际例子进行上述公式的阐述。

假设存在一个叫 A 的 Deployment，包含3个 Pod，每一个副本的 Request 值是 1 核，当前 3 个 Pod 的 CPU 利用率分别是 60%、70% 与 80%，此时咱们设置 HPA 阈值为 50%，最小副本为 3，最大副本为 10。接下来咱们将上述的数据带入公式中：

 

• 总的 Pod 的利用率是 60%+70%+80% = 210%；
• 当前的 Target 是 3；
• 算式的结果是 70%，大于50%阈值，所以当前的 Target 数目太小，须要进行扩容；
• 从新设置 Target 值为 5，此时算式的结果为 42% 低于 50%，判断还须要扩容两个容器；
• 此时 HPA 设置 Replicas 为 5，进行 Pod 的水平扩容。

 

通过上面的推演，能够协助开发者快速理解 HPA 最核心的原理，不过上面的推演结果和实际状况下是有所出入的，若是开发者进行试验的话，会发现 Replicas 最终的结果是 6 而不是 5。这是因为 HPA 中一些细节的处理致使的，主要包含以下三个主要的方面：

 

1. 噪声处理

经过上面的公式能够发现，Target 的数目很大程度上会影响最终的结果，而在 Kubernetes 中，不管是变动或者升级，都更倾向于使用 Recreate 而不是 Restart 的方式进行处理。这就致使了在 Deployment 的生命周期中，可能会出现某一个时间，Target 会因为计算了 Starting 或者 Stopping 的 Pod 而变得很大。这就会给 HPA 的计算带来很是大的噪声，在 HPA Controller 的计算中，若是发现当前的对象存在 Starting 或者 Stopping 的 Pod 会直接跳过当前的计算周期，等待状态都变为 Running 再进行计算。

 

2. 冷却周期

在弹性伸缩中，冷却周期是不能逃避的一个话题，不少时候咱们指望快速弹出与快速回收，而另外一方面，咱们又不但愿集群震荡，因此一个弹性伸缩活动冷却周期的具体数值是多少，一直被开发者所挑战。在 HPA 中，默认的扩容冷却周期是 3 分钟，缩容冷却周期是 5 分钟。

 

3. 边界值计算

咱们回到刚才的计算公式，第一次咱们算出须要弹出的容器数目是 5，此时扩容后总体的负载是 42%，可是咱们彷佛忽略了一个问题：一个全新的 Pod 启动会不会本身就占用了部分资源？此外，8% 的缓冲区是否就可以缓解总体的负载状况？要知道当一次弹性扩容完成后，下一次扩容要最少等待 3 分钟才能够继续扩容。为了解决这些问题，HPA 引入了边界值 △，目前在计算边界条件时，会自动加入 10% 的缓冲，这也是为何在刚才的例子中最终的计算结果为 6 的缘由。

HPA 的演进历程

在了解了 HPA 的基本原理后，咱们来聊一下 HPA 的演进历程，目前 HPA 已经支持了 autoscaling/v1、autoscaling/v1beta1 和 autoscaling/v1beta2 三个大版本。大部分的开发者目前比较熟悉的是autoscaling/v1 的版本，这个版本的特色是只支持 CPU 一个指标的弹性伸缩，大体的 yaml 内容以下：

 

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50

 

 

接下来咱们再来看一下 v2beta1 与 v2beta2 的 yaml，会发现里面支持的 metrics 类型增长了不少，结构也复杂了不少。

 

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        kind: AverageUtilization
        averageUtilization: 50
  - type: Pods
    pods:
      metric:
        name: packets-per-second
      targetAverageValue: 1k
  - type: Object
    object:
      metric:
        name: requests-per-second
      describedObject:
        apiVersion: extensions/v1beta1
        kind: Ingress
        name: main-route
      target:
        kind: Value
        value: 10k
---
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

 

 

而这些变化的产生不得不提的是 Kubernetes 社区中对监控与监控指标的认识与转变。在 Kubernetes 中，有两个核心的监控组件 Heapster 与 Metrics Server。Heapster 是早期 Kubernetes 社区中惟一的监控组件，它所包含的功能很强大，经过采集 kubelet 提供的 metrics 接口，并支持监控数据的离线与归档。

 

 

大体的架构图如上：source 的部分是不一样的数据来源，主要是 kubelet 的 common api 与后来提供的 summary api；processor 的做用是将采集的数据进行处理，分别在 namespace 级别、cluster 级别进行聚合，并建立新的聚合类型的监控数据；sink 的做用是数据离线与归档，常见的归档方式包括 influxdb、kafka 等等。Heapster 组件在至关长时间成为了 Kubernetes 社区中监控数据的惟一来源，也所以有很是多的和监控相关的组件经过 Heapster 的链路进行监控数据的消费。可是后来，Kubernetes 社区发现了 Heapster 存在很是严重的几个问题：

 

• 强大繁多的 Sink 由不一样的 Maintainer 进行维护，50% 以上的 Heapster Issues 都是关于 Sink 没法使用的，而因为 Maintainer 的活跃度不一样形成 Heapster 社区有大量的 issues 没法解决；
• 对于开发者而言，监控数据的类型已经再也不是 CPU、Memory 这么简单的几个指标项了，愈来愈多的开发者须要应用内或者接入层的监控指标，例如 ingress 的 QPS、应用的在线活跃人数等等。而这些指标的获取是 Heapster 没法实现的；
• Prometheus 的成熟让 Heapster 的生存空间不断被挤压，自从 Prometheus 被 CNCF 收录为孵化项目，Heapster 的不可替代地位被正式移除。

 

社区通过反思后，决定将监控的指标边界进行划分，分为 Resource、Custom 和 External 三种不一样的 Metrics，而 Heapster(Metrics Server) 的定位就只关心 Resource 这一种指标类型。为了解决代码维护性的问题，Metrics Server 对 Heapster 进行了裁剪，裁剪后的架构以下：

 

 

去掉了 Sink 的机制，并将调用方式改成标准的 API 注册的方式，这样的好处是既精简了核心代码的逻辑又提供了替代的可能，也就是说此时 Metrics Server 也是能够替代的，只要实现了相同的 API 接口，并注册到 API Server 上，就能够替代 Metrics Server。

 

接下来咱们解析一下三种不一样的 Metrics 与使用的场景：

	API	注释
Resource	metrics.k8s.io	Pod的资源指标，计算的时要除以Pod数目再对比阈值进行判断
Custom	custom.metrics.k8s.io	Object： CRD等对象的监控指标，直接计算指标比对阈值 Pods : 每一个Pod的自定义指标，计算时要除以Pods的数目
External	external.metrics.k8s.io	External：集群指标的监控指标，一般由云厂商实现

其中 autoscaling/v2beta1 支持 Resource 与 Custom 两种指标，而 autoscaling/v2beta2 中增长了 External 的指标的支持。

最后

HPA 目前已经进入了 GA 阶段，在大致的功能上面不会进行过多的变化，目前社区的主要发力点在如何配置化的调整细节参数、丰富监控 adapter 的实现等等。在本文中，咱们在概念上给你们介绍了 HPA 的一些原理以及发展的趋势，在下一篇文章中，咱们会为你们讲解如何开启 v2beta1 与 v2beta2 的。