Kubernetes 的 HPA 原理详解

1. HPA解决的问题

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

k8s被誉为新一代数据中心操作系统（DCOS），说到操作系统我们自然想到其定义：管理计算机的软硬件资源的系统，k8s也一样其核心工作也是管理整个集群的计算资源，并按需合理分配给系统里的程序（以Pod为基础的各种workload）。

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

为了解决业务服务负载时刻存在的巨大波动和资源实际使用与预估之间差距，就有了针对业务本身的“扩缩容”解决方案： Horizontal Pod Autoscaler（HPA）和 Vertical Pod Autoscaler（VPA）。

为了充分利用集群现有资源优化成本，当一个资源占用已经很大的业务需要扩容时，其实可以先尝试优化业务负载自身的资源需求配置（request与实际的差距），只有当集群的资源池确实已经无法满足负载的实际的资源需求时，再调整资源池的总量保证资源的可用性，这样可以将资源用到极致。

所以总的来说弹性伸缩应该包括：

1. Cluster-Autoscale: 集群容量（node数量）自动伸缩，跟自动化部署相关的，依赖iaas的弹性伸缩，主要用于虚拟机容器集群
2. Vertical Pod Autoscaler: 工作负载Pod垂直（资源配置）自动伸缩，如自动计算或调整deployment的Pod模板limit/request，依赖业务历史负载指标
3. Horizontal-Pod-Autoscaler: 工作负载Pod水平自动伸缩，如自动scale deployment的replicas，依赖业务实时负载指标

其中VPA和HPA都是从业务负载角度从发的优化，VPA是解决资源配额（Pod的CPU、内存的limit/request）评估不准的问题，HPA则要解决的是业务负载压力波动很大，需要人工根据监控报警来不断调整副本数的问题，有了HPA后，被关联上HPA的deployment，后续副本数修改就不用人工管理，HPA controller将会根据业务忙闲情况自动帮你动态调整。当然还有一种固定策略的特殊HPA: cronHPA，也就是直接按照cron的格式设定扩容和缩容时间及对应副本数，这种不需要动态识别业务繁忙度属于静态HPA，适用于业务流量变化有固定时间周期规律的情况，这种比较简单可以算做HPA的一种简单特例。

2. 原理架构

既然是自动根据业务忙闲来调整业务工作负载的副本数，其实HPA的实现思路很容易想到：通过监控业务繁忙情况，在业务忙时，就要对workload扩容副本数；等到业务闲下来时，自然又要把副本数再缩下去。所以实现水平扩缩容的关键就在于：

• 如何识别业务的忙闲程度
• 使用什么样的副本调整策略

kubernetes提供了一种标准metrics接口（整个HPA及metrics架构如下图所示），HPA controller通过这个统一metrics接口可以查询到任意一个HPA对象关联的deployment业务的繁忙指标metrics数据，不同的业务的繁忙指标均可以自定义，只需要在对应的HPA里定义关联deployment对应的metrics即可。

标准的metrics查询接口有了，还需要实现metrics API的服务端，并提供各种metrics数据，我们知道k8s的所有核心组件之间都是通过apiserver进行通信，所以作为k8s API的扩展，metrics APIserver自然选择了基于API Aggregation聚合层，这样HPA controller的metrics查询请求就自动通过apiserver的聚合层转发到后端真实的metrics API的服务端（对应下图的Promesheus adapter和Metrics server）。

最早的metrics数据是由metrics-server提供的，只支持CPU和内存的使用指标，metrics-serve通过将各node端kubelet提供的metrics接口采集到的数据汇总到本地，因为metrics-server是没有持久模块的，数据全在内存中所以也没有保留历史数据，只提供当前最新采集的数据查询，这个版本的metrics对应HPA的版本是autoscaling/v1（HPA v1只支持CPU指标）。

后来为了适应更灵活的需求，metrics API开始扩展支持用户自定义metrics指标（custom metrics），自定义数据则需要用户自行开发custom metrics server，社区有提供专门的custom adpater框架 custom-metrics-apiserver ，该框架定义了Custom和External的MetricsProvider接口（如下所示），需要自行实现对应的接口。

type MetricsProvider interface {
  CustomMetricsProvider
  ExternalMetricsProvider
}

type CustomMetricsProvider interface {
        // GetMetricByName fetches a particular metric for a particular object.
        // The namespace will be empty if the metric is root-scoped.
        GetMetricByName(name types.NamespacedName, info CustomMetricInfo, metricSelector labels.Selector) (*custom_metrics.MetricValue, error)

        // GetMetricBySelector fetches a particular metric for a set of objects matching
        // the given label selector.  The namespace will be empty if the metric is root-scoped.
        GetMetricBySelector(namespace string, selector labels.Selector, info CustomMetricInfo, metricSelector labels.Selector) (