简介
通过手工执行 kubectl scale 命令或者通过修改deployment的replicas数量，可以实现 Pod 扩容或缩容。但如果仅止于此，显然不符合 Google 对 Kubernetes 的定位目标 —— 自动化、智能化。在 Google 看来，分布式系统要能够根据当前负载的变化情况自动触发水平扩展或缩容的行为，因为这一过程可能是频繁发生的、不可预料的，所以手动控制的方式是不实现的。
因此，Kubernetes 的 v1.0 版本实现后，这帮大牛们就已经在默默研究 Pod 智能扩容的特性了，并在 Kubernetes v1.1 版本中首次发布了这一重量级新特性—— Horizontal Pod Autoscaling （Pod 横向自动扩容，简称 hPA）。随后的 v1.2 版本中 HPA 被升级为稳定版本（apiVersion: autoscaling/v1），但同时仍然保留旧版本（apiVersion: extensions/v1beta1）。从 v1.6 版本为 autoscaling/v2alpha1，仍在不断演进过程中。
HPA 与之前的 RC、Deployment 一样，也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况，来确定是否需要针对性地调整目标Pod的副本数，这是HPA的实现原理。
当前，HPA可以有以下两种方式作为 Pod 负载的调度指标：
- CPUUtilizationPercentage。
- 应用程序自定义的度量指标，比如服务在每秒内的相应的请求数（TPS 或 QPS）。
CPUUtilizationPercentage 是一个计算平均值，即目标 Pod 所有副本自身的 CPU 利用率的平均值。一个 Pod 自身的 CPU 利用率是该Pod当前的 CPU 的使用量除以它的 Pod Request 的值，比如定义一个 Pod 的 Pod Request 为0.4，而当前的 Pod 的CPU 使用量为 0.2，则它的 CPU 使用率为 50%，如此一来，就可以算出来一个 RC 控制的所有 Pod 副本的 CPU 利用率的算术平均值了。如果某一时刻 CPUUtilizationPercentage 的值超过 80%，则意味着当前的 Pod 副本数很可能不足以支撑接来下更多的请求，需要进行动态扩容，而当前请求高峰时段过去后，Pod 的 CPU 利用率又会降下来，此时对应的 Pod 副本数应该自动减少到一个合理的水平。
CPUUtilizationPercentage 计算过程中使用到的 Pod 的 CPU 使用量通常是1min内的平均值，目前通过查询 Heapster 扩展组件来得到这个值，所以需要安装部署 Heapster，这样一来便增加了系统的复杂度和实时HPA特性的复杂度，因此，未来的计划是 Kubernetes 自身实现一个基础性能数据采集某块，从而更好的支持 HPA 和其他需要用到基础性能数据的功能模块。此外，如果目标 Pod 没有定义 Pod Request 的值，则无法使用 CPUUtilizationPercentage 来实现 Pod 很想自动扩容的能力。除了使用 CPUUtilizationPercentage，Kubernetes 从 v1.2 版本开始尝试支持应用程序自定义的度量指标，目前仍然为实验特性，不建议在生产环境使用。
简单配置
下面是 HPA 定义的一个具体例子：
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: php-apache
namespace: default
spec:
maxReplicas: 10
minReplicas: 4
scaleTargetRef:
kind: Deployment
name: nginx-demo
targetCPUUtilizationPercentage: 90
根据上面的定义，可以知道这个 HPA 控制的目标对象为一个名叫 nginx-demo 的 Deployment 里的 Pod 副本，当这些 Pod 副本的 CPUUtilizationPercentage 的值超过 90% 时会触发自动动态扩容行为，扩容或缩容时必须满足一个约束条件是 Pod 的副本数要介于4与 10 之间。
除了可以通过之间定义 YAML 文件并且调用 kubectl create 的命令来创建一个 HPA 资源对象的方式，还能通过下面的简单命令直接创建等价的 HPA 对象：
kubectl autoscale deployment php-apache --cpu-percent=90 --min=1 --max=10