k8s彈性伸縮概念以及測試用例
本文原文出處：https://juejin.im/post/5c82367ff265da2d85330d4f
彈性伸縮式k8s中的一大亮點功能，當負載大的時候，你可以對應用進行擴容，提升pod的副本數來應對大量的流量，當負載小的時候可以對應用進行縮容，以避免資源浪費。也可以讓應用自動的進行擴容和縮容，這一功能有用。例如當微博出現了一個話題時，這個時候人們都去訪問，此時他的服務器將無法處理大量的流量訪問，這個時候就需要擴容，而當這個話題不在新鮮時，人們的訪問流量也就是降下來了，那么就需要對服務器進行縮容處理，來自動適應流量需求。
scale命令：擴容或縮容 Deployment、ReplicaSet、Replication Controller或 Job 中Pod數量
# 語法
kubectl scale [--resource-version=version] [--current-replicas=count] --replicas=COUNT (-f FILENAME | TYPE NAME)
# 將名為foo中的pod副本數設置為3。
kubectl scale --replicas=3 rs/foo
kubectl scale deploy/nginx --replicas=30
# 將由“foo.yaml”配置文件中指定的資源對象和名稱標識的Pod資源副本設為3
kubectl scale --replicas=3 -f foo.yaml
# 如果當前副本數為2，則將其擴展至3。
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql
# 設置多個RC中Pod副本數量
kubectl scale --replicas=5 rc/foo rc/bar rc/baz
k8s提供了scale和autoscale來進行擴容和縮容。
現在對go-deployment進行擴容，結果如圖
當訪問量減少了就進行縮容
現在我不想手動的進行擴容和縮容了，我想實現讓它當訪問流量大的時候自動擴容，當訪問流量小的時候自動縮容。這個時候autoscale出現了，利用他我們就可以實現自動擴容和縮容。
# 語法
kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags]
# 使用 Deployment “foo”設定，使用默認的自動伸縮策略，指定目標CPU使用率，使其Pod數量在2到10之間
kubectl autoscale deployment foo --min=2 --max=10
# 使用RC“foo”設定，使其Pod的數量介於1和5之間，CPU使用率維持在80％
kubectl autoscale rc foo --max=5 --cpu-percent=80
到目前為止，k8s一共提供了2個不同維度的AutoScaler。如下圖：
k8s把彈性伸縮分為兩類：
- 資源維度：保障集群資源池大小滿足整體規划，當集群內的資源不足以支撐產出新的pod時，就會觸發邊界進行擴容
- 應用維度：保障應用的負載處在預期的容量規划內
對應兩種伸縮策略：
- 水平伸縮
- 集群維度：自動調整資源池規模（新增/刪除Worker節點）
- Pod維度：自動調整Pod的副本集數量
- 垂直伸縮
- 集群維度：不支持
- Pod維度：自動調整應用的資源分配（增大/減少pod的cpu、內存占用）
其中最為成熟也是最為常用的伸縮策略就是HPA（水平Pod伸縮），所以下面以它為例來重點分析，官方文檔在此：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
縮容擴容的基本流程為三大步驟：
1.采集監控指標
2.聚合監控指標，判斷是否需要執行縮擴容
3.執行縮容擴容操作
HPA水平縮容擴容架構圖
HPA的監控指標
根據官方文檔的描述，HPA是使用巡檢（Control Loop）的機制來采集Pod資源使用情況的，默認采集間隔為15s，可以通過Controller Manager（Master節點上的一個進程）的--horizontal-pod-autoscaler-sync-period參數來手動控制。
目前HPA默認采集指標的實現是Heapster，它主要采集CPU的使用率；beta版本也支持自定義的監控指標采集，但尚不穩定，不推薦使用
因此可以簡單認為，HPA就是通過CPU的使用率作為監控指標的。
聚合算法
采集到CPU指標后，k8s通過下面的公式來判斷需要擴容多少個pod
desiredReplicas = ceil[currentReplicas * ( currentMetricValue / desiredMetricValue )]
ceil表示向上取整，舉個實際例子，假設某個服務運行了4個Pod，當前的CPU使用率為50%，預期的CPU使用率為25%，那么滿足預期的實際Pod數量就是4 * (50% / 25%) = 8個，即需要將Pod容量擴大一倍，增加4個Pod來滿足需求。
當然上述的指標並不是絕對精確的，首先，k8s會盡可能的讓指標往期望值靠近，而不是完全相等，其次HPA設置了一個容忍度（tolerance）的概念，允許指標在一定范圍內偏離期望值，默認是0.1，這就意味着如果你設置調度策略為CPU預期使用率 = 50%，實際的調度策略會是小於45%或者大於55%進行縮擴容，HPA會盡力把指標控制在這個范圍內（容忍度可以通過--horizontal-pod-autoscaler-tolerance來調整）
需要注意的是：
- 一是k8s做出決策的間隔，它不會連續地執行擴縮容動作，而是存在一定的cd，目前擴容動作的cd為3分鍾，縮容則為5分鍾
- 二是k8s針對擴容做了一個最大限制，每次擴容的pod數量不會大於當前副本數量的2倍。