kubernetes: HPA解析

什么是HPA

Horizontal Pod Autoscaling可以根据指标自动伸缩一个Replication Controller、Deployment 或者Replica Set中的Pod数量

HPA的工作模型

有哪些指标

目前主要分两个版本
1.autoscaling/v1
v1版本只支持 cpu
2.autoscaling/v2beta2
v2beta2版本支持 自定义 ，内存 ，但是目前也仅仅是处于beta阶段

指标从哪里来？
Horizontal Pod AutoScaler被实现为一个控制循环，周期由控制器管理器的–Horizontal Pod AutoScaler sync period标志（默认值为15秒）控制。

在每个期间，控制器管理器都会根据每个HorizontalPodAutoScaler定义中指定的度量来查询资源利用率。控制器管理器从资源度量api（针对每个pod的资源度量）或自定义度量api（针对所有其他度量）获取度量。

对于每个pod的资源度量（如cpu），控制器从horizontalpodautoscaler针对每个pod的资源度量api获取度量。然后，如果设置了目标利用率值，则控制器将利用率值计算为每个pod中容器上等效资源请求的百分比。如果设置了目标原始值，则直接使用原始度量值。然后，控制器获取所有目标pod的利用率平均值或原始值（取决于指定的目标类型），并生成用于缩放所需副本数量的比率。

为什么目前正在能使用的指标是 cpu？

v1的模板可能是大家平时见到最多的也是最简单的，v1版本的HPA只支持一种指标 —— CPU。传统意义上，弹性伸缩最少也会支持CPU与Memory两种指标，为什么在Kubernetes中只放开了CPU呢？其实最早的HPA是计划同时支持这两种指标的，但是实际的开发测试中发现，内存不是一个非常好的弹性伸缩判断条件。因为和CPU不同，很多内存型的应用，并不会因为HPA弹出新的容器而带来内存的快速回收，因为很多应用的内存都要交给语言层面的VM进行管理，也就是内存的回收是由VM的GC来决定的。这就有可能因为GC时间的差异导致HPA在不恰当的时间点震荡，因此在v1的版本中，HPA就只支持了CPU一种指标。

HPA与rolling update的区别
目前在kubernetes中，可以通过直接管理复制控制器来执行滚动更新，也可以使用deployment对象来管理底层副本集。HPA只支持后一种方法：HPA绑定到部署对象，设置部署对象的大小，部署负责设置底层副本集的大小。

HPA不能使用复制控制器的直接操作进行滚动更新，即不能将HPA绑定到复制控制器并进行滚动更新（例如，使用Kubectl滚动更新）。这不起作用的原因是，当滚动更新创建新的复制控制器时，HPA将不会绑定到新的复制控制器。

HPA怎么来使用？

1.使用kubectl的方式
kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10
2.使用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

发布
kubectl create -f hpa.yml
查看已经发布的HPA
kubectl get hpa

参考资料
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis
https://github.com/kubernetes-incubator/metrics-server/