预告：今天的故事是双结局的，有Happy Ending和Bad Ending，并且内容非常不讲武德，请大家做好思想准备。
在上期，我们分析了容器的弹性伸缩功能，发现了基于容器部署的服务能够扛住网黄明星出轨等爆炸新闻带来的冲击的奥秘的一半——Kubernetes的HPA组件，可以根据诸如Prometheus这样的性能监控平台反馈的数据，来决策是否要拉起更多的容器实例，或停止部分容器的运行。
HPA有V1和V2两个版本。由于HPA V1只支持基于CPU使用率进行伸缩调度，目前最常见的是HPA V2，它可以基于自定义的指标进行伸缩调度。
让我们看一个栗子：
小X为某视频网站P站，部署HPA V2实现容器的弹性伸缩，并采用Prometheus监控apache httpd的性能。
HPA V2的yaml描述如下：
代码语言：javascript复制apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
name: httpd-leitingzhanjiang
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: httpd-leitingzhanjiang
minReplicas: 3
maxReplicas: 20
metrics:
- type: Resource
resource:
name: cpu
targetAverageUtilization: 75
- type: Resource
resource:
name: memory
targetAverageValue: 80Mi可见，小X使用httpd作为web服务器端，最小3个容器，最大20个容器。
metrics字段体现了参照指标：
CPU利用率的目标为75%，内存占用量的目标为80MB。
很快，最新的抗日神剧《XX战将》播出，随着收视率的攀升，原本部署的3个httpd容器的CPU与RAM使用量也不断上升。
在某时刻，3个容器的CPU与RAM使用量如下：
CPU | RAM | |
|---|---|---|
容器1 | 77% | 75MB |
容器2 | 84% | 72MB |
容器3 | 88% | 70MB |
显然，CPU的使用量已经超过了75%，而RAM的使用量并没有超过80MB。
那么，此时HPA会触发容器伸缩吗？
答案是肯定的。
HPA在同时参考多个指标决策是否需要弹性伸缩的时候的，算法是这样的：
如果有A，B，C多个指标，会计算出满足各指标所需要的Pod数量，并以最大的为准。
假设HPA计算的结果为下表：
CPU | RAM | 响应时间 | |
|---|---|---|---|
目标值 | 75% | 80MB | 5ms |
Pod数量 | 8 | 6 | 7 |
显而易见地，8为最大的所需的Pod数量，所以HPA会拉起8个容器，满足CPU的目标值要求。
在HPA Prometheus的配合下，P站成功地扛住了热播剧集带来的大流量。
但是，好景不长，由于《XX战将》内容不讲武德，过于荒谬(洋文曰：ridiculous)，被有关部门勒令停播，要求P站耗子尾汁，尽快整改。
此时，HPA的行为是什么样的呢？
由于《XX战将》停播，大量用户转向XX荣耀、XX求生等娱乐，P站流量迅速腰斩，原有的20个容器占用的资源也迅速降低。HPA经过计算，决策销毁部分容器，以释放Kubernetes集群的资源。
Happy Ending：
Prometheus反馈的CPU和RAM使用如下表：
CPU | RAM | |
|---|---|---|
容器1 | 12% | 33MB |
容器2 | 9% | 18MB |
容器3 | 11% | 24MB |
…… | …… | …… |
容器20 | 9% | 21MB |
HPA经过销毁了17个容器，剩余3个容器，P站开始整改，世界恢复了平静。
Bad Ending：
Prometheus反馈的CPU和RAM使用如下表：
CPU | RAM | |
|---|---|---|
容器1 | 12% | 70MB |
容器2 | 9% | 74MB |
容器3 | 11% | 82MB |
…… | …… | …… |
容器20 | 9% | 81MB |
可见，大部分Pod的CPU占用率下来了，但并没有把申请的RAM资源还给操作系统。
由于HPA不能对付这种不讲武德的POD，因此也没有办法回收它们占用的资源。
POD，特别是装载了JAVA开发的应用的POD，为什么会不讲武德，干多吃多占的事儿呢？
这个问题留到以后的专题中解释
