Kubernetes & Autoscaler
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，已經接近生產環境中的可用目標了