簡介
通過手工執行 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