横向伸缩：调大replicas副本数

纵向伸缩：扩充pod的资源请求和限制，仅在创建时

一、pod横向自动伸缩

由Horizontal控制器执行，我们通过创建一个HorizontalpodAutoscaler（HPA）资源来启用和配置Horizontal控制器。该控制器周期性检查pod度量，计算满足HPA资源所配置的目标数值所需的副本数量，进而调整目标资源（如Deployment、ReplicaSet、ReplicationController、StatefulSet等）的replicas字段

1、伸缩步骤

（1）获取被伸缩资源对象所管理的所有pod度量

HPA控制器向Heapster发起REST调用来获取所有pod度量数据，所以必须运行Heapster

（2）计算使度量数值到达（或接近）所指定目标数值所需的pod数量

Autoscaler 需要计算出一个合适的副本数量，以使所有副本上度量的平均值尽量接近配置的目标值

单个pod度量就是除了下图中的最后Max()一步，

多个pod度量：

（3）更新被伸缩资源的replicas字段

Autoscaler控制器通过Scale子资源来修改被伸缩资源的 replicas 字段。这样Autoscaler不必了解它所管理资源的细节，而只与Scale交互。

Deployment、ReplicaSet、ReplicationController、StatefulSet都暴露了Scale子资源

总伸缩过程：

2、基于CPU使用率进行自动伸缩

Autoscaler计算的CPU使用率是实际使用量/申请量（requests）

（1）创建：

创建HPA：

kubectl autoscale deployment kubia --cpu-percent=30 --min=1 --max=5

一开始没有请求，CPU利用率不到30%，会缩容到1

（2）扩容速率

Autoscaler两次扩容操作之间的时间间隔也有限制。目前，只有当3分钟内没有任何伸缩操作时才会触发扩容，缩容操作频率为5分钟

Autoscaler在单次扩容操作中可增加的副本数受到限制。如果当前副本数大于2,Autoscaler单次操作至多使副本数翻倍；如果副本数只有1或2,Autoscaler最多扩容到4个副本

3、基于内存使用进行自动伸缩

基于内存的自动伸缩比基于CPU的困难很多。主要原因在于，扩容之后原有的pod需要有办法释放内存。这只能由应用完成，系统无法代劳。系统所能做的只有杀死并重启应用，希望它能比之前少占用一些内存

比较复杂

4、0副本

空载（idling）与解除空载（un-idling）：即允许提供特定服务的pod被缩容到0副本。在新的请求到来时，请求会先被阻塞，直到pod被启动，从而请求被转发到新的pod为止。

HPA暂不支持0副本

二、pod纵向自动伸缩

扩充CPU和内存，不怎么用，实际使用时世界edit  pod的模板文件，调大cpu、memory的requests即可

三、集群节点横向伸缩

Cluster Autoscaler负责在由于所有节点资源都不足，而无法调度某pod到已有节点时，自动部署新节点。它也会在节点长时间使用率低下的情况下下线节点。

由云服务提供商支持

手动标记节点为不可调度、排空节点：

kubectl cordon <node> 标记节点为不可调度（但对其上的pod不做任何事）
kubectl drain <node> 标记节点为不可调度，随后疏散其上所有pod