K8S
彈性伸縮式K8S中的一大亮點功能，當負載大的時候，可以對應用進行擴容，提升pod的副本數來應對大量的流量，當負載小的時候可以對應用進行縮容，以避免資源浪費。功能是通過Kubernetes HPA(Horizontal Pod Autoscaling)Pod水平自動伸縮來實現，只需簡單的配置，集群便可以利用監控指標（cpu使用率等）自動的擴容或者縮容服務中Pod數量，當業務需求增加時，系統將會無縫地自動增加適量容器 ，提高系統穩定性。
彈性伸縮分類
K8S彈性伸縮分為兩類：
- 資源維度：保障集群資源池大小滿足整體規劃，當集群內的資源不足以支撐產出新的pod時，就會觸發邊界進行擴容
- 應用維度：保障應用的負載處在預期的容量規劃內
伸縮策略：
水平伸縮：
- 集群維度：自動調整資源池規模（新增/刪除Worker節點）
- Pod維度：自動調整Pod的副本集數量
垂直伸縮：
- 集群維度：不支持
- Pod維度：自動調整應用的資源分配（增大/減少pod的cpu、內存佔用）
其中最為成熟也是最為常用的伸縮策略就是HPA（水平Pod伸縮）。
HPA概述
HPA水平縮容擴容架構圖
HPA在kubernetes中被設計為一個controller，可以簡單的使用kubectl autoscale命令來創建。HPA Controller默認15秒輪詢一次，查詢指定的resource中（Deployment,RC）的資源使用率，並且與創建時設定的值和指標做對比，從而實現自動伸縮的功能。
Pod只有設置request後，HPA才會工作。
目前HPA默認採集指標的實現是Heapster，它主要採集CPU的使用率，因此可以簡單認為，HPA就是通過CPU的使用率作為監控指標的。
HPA自動伸縮算法
具體的每次擴容或者縮容的多少Pod的算法為：
Ceil(前採集到的使用率 / 用戶自定義的使用率) * Pod數量)
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
ceil表示向上取整，舉個實際例子，假設某個服務運行了6個Pod，當前的CPU使用率為50%，預期的CPU使用率為25%，那麼滿足預期的實際Pod數量就是6 * (50% / 25%) = 12個，即需要將Pod容量擴大一倍，增加6個Pod來滿足需求。
K8S會盡可能的讓指標往期望值靠近，而不是完全相等，HPA Controller中有一個tolerance（容忍力）的概念，它允許一定範圍內的使用量的不穩定，現在默認為0.1，這也是出於維護系統穩定性的考慮。例如，設定HPA調度策略為cpu使用率高於50%觸發擴容，那麼只有當使用率大於55%或者小於45%才會觸發伸縮活動，HPA會盡力把Pod的使用率控制在這個範圍之間（容忍度可以通過--horizontal-pod-autoscaler-tolerance來調整）。
當pod所需要的CPU負荷過大，從而在創建一個新pod的過程中，系統的CPU使用量可能會同樣在有一個攀升的過程。所以，在每一次作出決策後的一段時間內，將不再進行擴展決策。對於擴容而言，這個時間段為3分鐘，縮容為5分鐘。
每次最大擴容pod數量不會超過當前副本數量的2倍。
HPA YAML文件概述
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
creationTimestamp: 2019-12-11T11:04:08Z
name: nginxtest
namespace: default
resourceVersion: "1234567"
selfLink: /apis/autoscaling/v1/namespaces/default/horizontalpodautoscalers/nginxtest
uid: 86febb63-5ca1-11e7-abef-5254gyui79a3
spec:
maxReplicas: 5 //資源最大副本數
minReplicas: 1 //資源最小副本數
scaleTargetRef:
apiVersion: extensions/v1beta1
kind: Deployment //需要伸縮的資源類型
name: test //需要伸縮的資源名稱
targetCPUUtilizationPercentage: 50 //觸發伸縮的cpu使用率
status:
currentCPUUtilizationPercentage: 48 //當前資源下pod的cpu使用率
currentReplicas: 1 //當前的副本數
desiredReplicas: 2 //期望的副本數
題外話
HPA雖好，但是也有弊端，它可以對服務的容器數量做自動伸縮，這對於服務穩定性是一個很好提升，但是也有弊端，目前穩定版只有CPU這一個指標，所以可能會發生判斷不準確而導致不必要的自動伸縮。如何使用，還是在我們自己。
閱讀更多 DevOps筆記 的文章
