简述
我们可以通过调高ReplicationController、 ReplicaSet、 Deployment等可伸缩资源的rep让cas字段， 来手动实现pod中应用的横向扩容。 我们也可以通过增加pod容器的资源请求和限制来纵向扩容pod (尽管目前该操作只能在pod创建时， 而非运行时进行）。 虽然如果你能预先知道负载何时会飘升， 或者如果负载的变化是较长时间内逐渐发生的， 手动扩容也是可以接受的， 但指望靠人工干预来处理突发而不可预测的流量增长， 仍然不够理想。
Kubemetes可以监控你的pod, 并在检测到CPU使用率或其他度量增长时自动对它们扩容。 如果Kubemetes运行在云端基础架构之上， 它甚至能在现有节点无法承载更多pod之时自动新建更多节点。
pod的横向自动伸缩
横向pod自动伸缩是指由控制器管理 的pod副本数量的自动伸 缩。 它由Horizontal控制器执行， 我们通过创建 一个HorizontalpodAutoscaler C HPA)资源来启用和配置Horizontal控制器。 该控制器周期性检查pod度量， 计算满足HPA资源所配置的目标数值所需的副本数量， 进而调整目标资源（如Deployment、ReplicaSet、 ReplicationController、StatefulSet等）的replicas字段。
自动伸缩过程
自动伸缩的过程可以分为三个步骤：
• 获取被伸缩资源对象所管理的所有pod度量。
• 计算使度量数值到达（或接近）所指定目标数值所需的pod数量。
• 更新被伸缩资源的replicas字段。
下面我们就来看看这三个步骤。
获取pod度量
Autoscaler本身并不负责采集pod度量数据 ， 而是从另外的来源获取。 正如之前提到的， pod与节点度量数据是由运行在每个节点的kubelet之上， 名为cAdvisor的agent采集的；这些数据将由 集群级的组件Heapster聚合。 HPA控制器向Heapster 发起REST调用来获取 所有pod度量数据。
计算所需的 pod 数量
一 旦Autoscaler获得了它所调整的资源(Deployment、 ReplicaSet、ReplicationController或State伈!Set)所辖pod的全部度量， 它便可以利用这些度量计算出所需的副本数量。 它需要计算出一个合适的副本数量， 以使所有副本上度量的平均值尽量接近配置的目标值。 该计算的输入是一组pod度量（每个pod可能有多个）， 输出则是一个整数(pod副本数量）。
当Autoscaler配置为只考虑单个度量时， 计算所需 副本数很简单。 只要将所有pod的度量求和后除以HPA资源上配置的目标值， 再向上取整即可。 实际的计算稍微复杂一些； Autoscaler还保证了度量数值不稳定、 迅速抖动时不会导致系统抖动（thrash)。
基于多个pod度量的自动伸缩（例如： CPU使用率和每秒查询率[QPS])的计算也并不复杂。 Autoscaler单独计算每个度量的副本数， 然后取最大值（例如：如果需要4个pod达到目标CPU使用率， 以及需要3个pod来达到目标QPS, 那么Autoscaler 将扩展到4个pod)。 下图展示了这个示例。
更新被伸缩资源的副本数
自动伸缩操作的最后 一 步是更新被伸缩资源对象（比如ReplicaSet)上的副本数字段 然后让ReplicaSet控制器负责启动更多pod或者删除多余的pod。Autoscaler控制器通过scale子资源来修改被伸缩资源的rep巨cas字段。 这样Autoscaler不必了解它所管理资源的细节，而只需要通过Scale子资源暴露的界面，就可以完成它的工作了,如下图
HPA只对Scale子资源进行更改 。
这意味着只要API服务器为某个可伸缩资源暴露了Scale子资源， Autoscaler即可操作该资源。 目前暴露了Scale子资源的资源有：
• Deployment
• ReplicaSet
• ReplicationController
• StatefulSet
目前也只有这些对象可以附着Autoscaler。
了解整个自动伸缩过程
从pod指向 cAdvisor, 再经过Heapster , 而最终到达HPA的箭头代表度量数据的流向。 值得注意的是， 每个组件从其他组件拉取数据的动作是周期性的 （即cAdvisor用 一个无限循环从pod中采集数据； Heapster与HPA控制器亦是如此）。这意味着度量数据的传播与相应动作的触发都需要相当一段时间， 不是立即发生的。接下来实地观察Autoscaler行为时要注意这一点。
基于CPU使用率进行自动伸缩
可能你最想用以指导自动伸缩的度量就是pod中进程的CPU使用率了。 假设你用几个pod来提供服务， 如果它们的CPU使用率达到了100%, 显然它们已经扛不住压力了， 要么进行纵向扩容(scale up), 增加它们可用的CPU时间， 要么进行横向扩容(scale out), 增加pod 数量 。 因为本章谈论的是HPA, 我们仅仅关注横向扩容。
这么一来， 平均CPU使用率就应该下降了。因为CPU使用通常是不稳定的， 比较靠谱的做法是在CPU被压垮之前就横向扩容一—可能平均负载达到或超过80%的时候就进行扩容。 但这里有个问题， 到底是谁的80%呢。
就 Autoscaler而言， 只有pod的保证CPU用量(CPU请求）才与确认pod的CPU使用有关。 Autoscaler对比pod的实际CPU使用与它的请求， 这意味着你需要给被伸缩的pod设置CPU请求，不管是直接设置还是通过LimitRange对象间接设置，这样Autoscaler才能确定CPU使用率。
基于CPU使用率创建HPA
创建deployment 资源 apiVersion: extensions/vlbetal kind: Deployment metadata: name: kubia spec: replicas: 3 #手动设置（初始）想要的副本数为3 template: metadata: name: kubia labels: app: kubia spec: containers: - image: luksa/kubia:vl name: nodejs resources: requests: cpu: 100m #每个pod请求100毫核的CPU 创建了Deployment之后， 为了给它的pod 启用横向自动伸缩 ， 需要创建一个 HorizontalpodAutoscaler (HPA)对象， 并把它指向该Deployment。 $ kubectl autoscale deploymen七kubia --cpu-percent=30 --min=l --max=5 这会帮你创建 HPA对象，并将叫作kubia的Deployment设置为伸缩目标。你还设置了pod的目标 CPU使用率为30%, 指定了副本的最小和最大数量。Autoscaler会持续调整副本的数量 以使CPU使用率接近30%, 但它永远不会调整到少于1个或者多于5个。 提示：一定要确保自动伸缩的目标是Deployinent 而不是底层的 ReplicaSet。 这样才能确保预期的副本数量在应用更新后继续保持（记着 Deployment 会给每个应用版本创建一个 新的 ReplicaSet)。 手动伸缩也是同样的道理。
修改一个已有 HPA 对象的目标度量值
可能你 开始设置的目标值30 有点太低了，我们把它提高到 你将使用 kubectl edit 命令来完成这项工作。文本编辑器打开之后，把 targetAverageUtilization 字段改为 60,
正如大多数其他资源 样，在你修改资源之后， Autosca er 控制器会检测到这一变更，并执行相应动作 也可以先删除 HPA 资源再用新的值创建一个，因为删除HPA 资源只会禁用目标资源的自动伸缩（本例中为 Deployment ，而它的伸缩规模会保持在删除资源的时刻 在你为 Deployment 创建一个新的 HPA 资源之后，自动伸缩过程就会继续进行
伸缩操作的最大速率
因为 Autosca 在单次扩容操作中可增加的副本数受到限制。如果当前副本数大于 2,Autoscaler 单次操作至多使副本数翻倍；如果副本数只有 2, Autoscaler 最多扩容到4个副
另外 Autoscaler 两次扩容操作之间的时间间隔是有限制。目前，只有当3钟内没有任何伸缩操作时才会触发扩容，缩容操作频率更低一－ 5分钟 记住这点，这样你再看到度量数据很明显应该触发伸缩却没有触发的时候，就不会感到奇怪了。