kubernetes: HPA解析

什么是HPA

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

HPA的工作模型
kubernetes: HPA解析_第1张图片

有哪些指标

目前主要分两个版本
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/

你可能感兴趣的:(kubernetes)