按照伸缩粒度，分为服务伸缩和节点伸缩
-
服务伸缩
k8s 默认提供了多个服务粒度的弹性伸缩组件。主要有 VPA， addon resizer 和 HPA。
此外，各大云厂商也积极贡献提供了多种伸缩组件，例如阿里云提供的 cronHPA。
在服务粒度的伸缩中，依据执行触发时机不同，可分为：立即执行，定时执行和预测性执行
1.1 立即执行
立即执行又细分为垂直伸缩和水平伸缩
1.1.2 垂直伸缩
k8s 中的垂直伸缩一般是指调整 Pod 的内存和 CPU 配额
可用工具：k8s 官方 autoscaler 包中有两个类型的垂直伸缩组件：VPA(vertical pod autoscaler) 和 addon resizer：
addon resizer
可以根据集群节点数量来动态地调整某个其他 deployment 中的 pod 的配额。
addon resizer 周期性地查看集群节点数量，然后计算出监控的 pod 需要分配的内存和 CPU，如果 pod 的实际 pod 配额和所需配额超过某个阈值，则会修改 deployment 并触发生成新的 pod。addon resizer 的这种特性决定了它用来伸缩与集群规模密切相关的服务。一般， addon resizer 用来伸缩部署在集群内的 heapster， metrics-server， kube-state-metrics等监控组件。
VPA
设置 VPA 后，它能够自动为 pod 设定 request 和 limit 配额值，然后动态地将 pod 调度到合适的节点上去。
VPA 在 k8s 中定义类型为 VerticalPodAutoscaler 的 CRD，为每个需要开启垂直弹性伸缩功能的 deployment 创建一个 custom resource，然后 VPA 会定期查看对应 pod 的资源使用情况，结合历史数据，自动调整 pod 的配额。
VPA controller 由三部分组成。
Recommender：它监视当前和过去的资源消耗，并基于此提供容器的cpu和内存请求的推荐值。
Updater：它检查哪个托管的pod设置了正确的资源，如果没有，则杀死它们，以便它们的控制器可以用更新后的请求重新创建它们。
Admission Plugin：它在新pod上设置正确的资源请求(由于Updater的活动，它们的控制器只是创建或重新创建了这些请求)。
使用 VPA 监控 deployment 时，它并不会去改变 deployment 的配置，而是使用 admission plugin 以类似 pre hook 的方式
在创建 pod 时动态为其配置配额值。
使用 VPA 之前需要注意以下问题：
VPA 默认会从 metrics server 中采集历史数据，因此使用 VPA 之前，需要配置好 metrics server。VPA 也支持从 prometheus 中采集历史数据，不过需要额外的配置。
VPA 在伸缩调整过程中，是通过重启 pod 来使调整生效的，因此基础架构不同，可能会引起服务闪断，需要具体分析服务是否可接受使用 VPA 扩容有上限，具体受 pod 所在宿主机影响。为 pod 分配的资源无法超过宿主机的大小。如果 recommender 计算出的 pod 所需资源超过节点可用资源，将导致 pod 一直 pending。这点可与通过与 cluster autoscaler 共同使用来部分解决。VPA 目前不应与基于内存和 CPU 监控的水平Pod自动调度器(HPA)一起使用，否则可能产生预期外的行为。
1.1.3 水平伸缩
根据观察到的CPU使用率（或使用自定义指标支持，基于某些其他应用程序提供的指标）
自动缩放 replication 控制器，deployment，副本集或状态集中的 pod 数量。
Horizontal Pod Autoscaler 是 k8s 内置的水平伸缩控制器
使用 HPA 一般需要先搭建 metrics server，metrics server的搭建及使用将另起一篇文章专门讲述
HPA 实现为Kubernetes API资源和控制器。资源决定控制器的行为。控制器定期（默认为 15 秒）调整复制控制器或部署中的副本数量，以使所观察到的平均CPU利用率与用户指定的目标相匹配
1.2 定时伸缩
kubernetes 官方并没有提供定时伸缩相关的组件，但是其原理并不难，只需按照设定的时间调用 kubernetes 的 API 即可。
1.3 预测性伸缩
目前暂无成熟的技术方案。 -
节点伸缩
节点伸缩分为垂直伸缩、水平伸缩、定时伸缩（目前暂无成熟方案，本文不介绍）
2.1 垂直伸缩
与 kubernetes 本身关系不大，其功能主要取决于厂商。例如，厂商是否支持主机的升降配，以及升降配过程中是否需要重启主机等。如果需要重启主机，那么在进行伸缩之前，我们需要先把节点上的 pod 驱逐到其他主机。但是如果我们是由于机器资源不够用而扩容的话，这样会加剧资源不够用的情况，造成更大的 pending 状态的 pod。因此，如果如果厂商不支持不重启就能扩容的话，不建议采用这种方式进行节点扩容。
2.2 水平伸缩
CA(Cluster Autoscaler) 是 kubernetes 官方的节点水平伸缩组件。
它可以在下列条件之一为真时自动调整Kubernetes集群的大小：
集群中有 pod 由于资源不足而一直 pending
集群中有些节点在很长一段时间内没有得到充分利用，且其上的 pod 可以被调度到其他节点上。
cluster autoscaler 虽然是 kubernetes 官方标准，但是由于其对云厂商依赖较深，因此具体使用方法，功能以及限制以云厂商具体实现为准。目前支持以下云厂商: Google Cloud Platform, AWS, AliCloud, Azure, BaiduCloud。
以 AliCloud 为例，默认单个用户按量付费实例的配额是30台，单个VPC的路由表限额是50条；且每个可用区的同一类型的实例库存容量波动很大，如果短时间内大量购买同一区同一配置的实例，很容易出现库存不足导致扩容失败。建议在伸缩组中配置多种同规格的实例类型，提高节点伸缩成功率。
实际使用中，一般为 node 建立多个 node group，专门配置几个 group 来启用弹性伸缩应对突发流量进行扩缩容。主要的 group 并不进行扩缩容，来避免扩缩容导致对大范围的服务的影响。
此外，节点水平伸缩能否成功实施，与调度策略密切相关。kubernetes 在为 pod 选择可分配节点时，
是采用 LeastRequestedPriority 策略，简单来说就是就是尽可能把资源打散，把 pod 分配到资源利用率低的节点。这样会倒是有一批利用率较低，但未到缩容阈值的节点，因此会导致无法成功缩容，资源利用率低。因此实际使用时，需要调整 kubernetes 调度策略，来达到最优的结果。
参考文章：https://segmentfault.com/a/1190000021545907