Kubernetes & Autoscaler
通过手工执行kubectl scale命令，我们可以实现Pod扩容或缩容。如果仅仅到此为止，显然不符合谷歌对Kubernetes的定位目标—自动化、智能化。在谷歌看来，分布式系统要能够根据当前负载的变化自动触发水平扩容或缩容，因为这一过程可能是频繁发生的、不可预料的，所以手动控制的方式是不现实的。
因此，在Kubernetes的1.0版本实现后，就有人在默默研究Pod智能扩容的特性了，并在Kubernetes 1.1中首次发布重量级新特性—Horizontal Pod Autoscaling（Pod横向自动扩容，HPA）。在Kubernetes 1.2中HPA被升级为稳定版本（apiVersion: autoscaling/v1），但仍然保留了旧版本（apiVersion: extensions/v1beta1）。Kubernetes从1.6版本开始，增强了根据应用自定义的指标进行自动扩容和缩容的功能，API版本为autoscaling/v2alpha1，并不断演进。
HPA与之前的RC、Deployment一样，也属于一种Kubernetes资源对象。通过追踪分析指定RC控制的所有目标Pod的负载变化情况，来确定是否需要有针对性地调整目标Pod的副本数量，这是HPA的实现原理。当前，HPA有以下两种方式作为Pod负载的度量指标。
- CPU Utilization Percentage
- 应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）。
CPU Utilization Percentage是一个算术平均值，即目标Pod所有副本自身的CPU利用率的平均值。
一个Pod自身的CPU利用率是该Pod当前CPU的使用量除以它的Pod Request的值，比如定义一个Pod的Pod Request为0.4，而当前Pod的CPU使用量为0.2，则它的CPU使用率为50%，这样就可以算出一个RC控制的所有Pod副本的CPU利用率的算术平均值了。
如果某一时刻CPU Utilization Percentage的值超过80%，则意味着当前Pod副本数量很可能不足以支撑接下来更多的请求，需要进行动态扩容，而在请求高峰时段过去后，Pod的CPU利用率又会降下来，此时对应的Pod副本数应该自动减少到一个合理的水平。
如果目标Pod没有定义Pod Request的值，则无法使用CPU Utilization Percentage实现Pod横向自动扩容。除了使用CPU Utilization Percentage，Kubernetes从1.2版本开始也在尝试支持应用程序自定义的度量指标。
在CPU Utilization Percentage计算过程中使用到的Pod的CPU使用量通常是1min内的平均值，通常通过查询Heapster监控子系统来得到这个值，所以需要安装部署Heapster，这样便增加了系统的复杂度和实施HPA特性的复杂度。
因此，从1.7版本开始，Kubernetes自身孵化了一个基础性能数据采集监控框架——Kubernetes Monitoring Architecture，从而更好地支持HPA和其他需要用到基础性能数据的功能模块。在Kubernetes Monitoring Architecture中，Kubernetes定义了一套标准化的API接口Resource Metrics API，以方便客户端应用程序（如HPA）从Metrics Server中获取目标资源对象的性能数据，例如容器的CPU和内存使用数据。到了Kubernetes 1.8版本，Resource Metrics API被升级为metrics.k8s.io/v1beta1，已经接近生产环境中的可用目标了