應用現狀
企業應用的流量大小不是每時每刻都一樣，有高峰和低谷，如果每時每刻都要保持可承載高峰流量的機器數目，那么成本會很高。通常解決這個問題的辦法就是根據流量大小或資源占用率自動調節CCE集群中工作負載及節點的數量，也就是彈性伸縮。
在CCE中，由于使用Pod/容器部署應用，容器可使用的資源是在部署時即配置好，不會無限制使用CCE節點中的資源，所以在CCE中彈性伸縮需要先對Pod數量進行伸縮，Pod數量增加后節點資源使用率才會增加，進而根據節點資源使用率再去伸縮集群中節點的數量。
解決方案
CCE中的彈性伸縮主要使用HPA（Horizontal Pod Autoscaling）和CA（Cluster AutoScaling）兩種彈性伸縮策略，HPA負責工作負載彈性伸縮，也就是應用層面的彈性伸縮；CA負責節點彈性伸縮，也就是資源層面的彈性伸縮。
通常情況下，兩者需要配合使用，因為HPA需要集群有足夠的vCPU和內存等資源才能擴容成功，當集群資源不夠時需要CA擴容節點，使得集群有足夠資源；而當HPA縮容后集群會有大量空余資源，這時就需要CA對集群節點進行縮容以釋放資源，才不至于造成浪費。
如下圖所示，HPA根據監控指標進行擴容，當集群資源不夠時，新創建的Pod會處于Pending狀態，CA會檢查所有Pending狀態的Pod，根據用戶配置的擴縮容策略，選擇出一個最合適的節點池，在這個節點池擴容。
CCE同時支持創建CA策略，根據CPU/內存分配率擴容、還可以按照時間定期擴容節點，CA策略可以與autoscaler默認的根據Pod的Pending狀態進行擴容配合使用。
使用HPA+CA可以很容易做到彈性伸縮，且節點和Pod的伸縮過程可以非常方便的觀察到，使用HPA+CA做彈性伸縮能夠滿足大部分業務場景需求。
本實踐將通過一個示例介紹HPA+CA兩種策略配合使用下彈性伸縮的過程，從而幫助您更好的理解和使用CCE中的彈性伸縮。
準備工作
準備一個算力密集型的應用，當用戶請求時，需要先計算出結果后才返回給用戶結果，如下示例，這是一個PHP頁面，代碼將保存在index.php文件中，用戶請求時先循環開方1000000次，然后再返回“OK!”。
編寫Dockerfile制作容器鏡像。
FROM php:5-apache
COPY index.php /var/www/html/index.php
RUN chmod a+rx index.php
執行如下命令構建鏡像，鏡像名稱為busy-php。
docker build -t busy-php:latest .
構建完成后上傳到目標資源池的SWR鏡像倉庫，上傳容器鏡像的步驟請參見“容器鏡像服務 > 客戶端上傳鏡像”。
創建有1個工作節點的CCE集群，工作節點規格2U4G，節點需要帶彈性公網IP，以便訪問公網。
在CCE控制臺“插件管理”中，如未安裝請首先給集群安裝好以下插件：
?autoscaler：CA插件。
?metrics-server：是Kubernetes集群范圍資源使用數據的聚合器，能夠收集包括了Pod、Node、容器、Service等主要Kubernetes核心資源的度量數據。
創建節點池和CA策略
在CCE控制臺中，創建一個節點池，添加一個2U4G的節點，并打開節點池的彈性擴縮容開關，如下圖所示。
修改autoscaler插件配置，將自動縮容開關打開，并配置縮容相關參數，例如節點資源使用率小于50%時進行縮容掃描，啟動縮容。插件規格建議至少選擇“高可用50”，即保證運行不少于2個autoscaler實例。
上面配置的節點池彈性伸縮，會根據Pod的Pending狀態進行擴容，根據節點的資源使用率進行縮容。
CCE同時支持創建CA策略，這里的CA策略可以根據CPU/內存分配率擴容、還可以按照時間定期擴容。CA策略可以與autoscaler默認的根據Pod的Pending狀態進行擴容共同作用。
如下圖所示，在CCE控制臺
彈性伸縮 >
節點伸縮中創建一個“節點伸縮策略”，配置當集群CPU分配率大于70%時，增加一個節點。CA策略需要關聯節點池，可以關聯多個節點池，當需要對節點擴縮容時，在節點池中根據最小浪費規則挑選合適規格的節點擴縮容。
創建工作負載
使用剛構建的busy-php容器鏡像創建無狀態工作負載，副本數為1。vCPU設置為0.5 core、內存設置為200MiB，limits與requests建議取值保持一致，避免擴縮容過程中出現震蕩。
然后再為這個負載創建一個Nodeport類型的Service，以便能從外部訪問。
創建HAP策略
創建HPA策略，如下圖所示，該策略關聯了名為busy-php的工作負載，期望CPU使用率為50%。
另外有兩個配置參數，一個是CPU的閾值范圍，最低30，最高70，表示CPU使用率在30%到70%之間時，不會擴縮容，防止小幅度波動造成影響。另一個是擴縮容冷卻時間窗，表示策略成功觸發后，在縮容/擴容冷卻時間內，不會再次觸發縮容/擴容，以防止短期波動造成影響。
準備壓測環境
在本例中使用linux開源壓測工具wrk模擬外部壓力負載，您也可以使用其它壓測工具進行模擬，確保對集群中的工作負載可形成持續的壓力即可。
為確保壓測效果，建議在節點池外的同一集群工作節點上安裝并運行壓測工具，本例以在linux工作節點上安裝wrk為例：
如未安裝git、gcc，首先安裝：
yum install git -y
yum install gcc -y
下載wrk工具：
git clone //github.com/wg/wrk.git
進入wrk目錄，編譯：
cd wrk && make
完成編譯后，可將wrk可執行文件軟連接至/usr/local/bin等目錄下，方便后續使用。
首先通過如下命令測試工作負載是否正常，正常結果應為返回“OK！”。
curl //192.168.0.149:31504
其中的{ip:port}為busy-php工作負載的訪問地址和端口，可在負載詳情頁中獲取：
驗證wrk工具并查看結果是否正常：
wrk -t2 -c10 -d3s //192.168.0.149:31504/
wrk的詳細使用方法和參數說明，請參考官方介紹：//github.com/wg/wrk。
觀察彈性伸縮過程
首先查看CCE集群中剛才新建的節點池情況，初始狀態節點池中有1個節點。
說明
本實踐中的壓測、工作負載和節點等相關指標值僅為參考示例。
查看HPA策略，因為之前已進行過連通性測試，可以看到目標負載busy-php的指標（CPU使用率）為16%
通過如下命令開始打壓，其中{ip:port}為負載的訪問地址，可以在busy-php負載的詳情頁中查詢。
wrk -t10 -c1000 -d1200s //192.168.0.149:31504/
說明
上述壓測命令中的并發數、連接數、持續時間僅為示例，請根據節點規格等參數進行合理的設置。
觀察工作負載的伸縮過程。
可以看到第二行開始負載的CPU使用率達到99%，超過了目標值，此時觸發了工作負載的彈性伸縮，將負載擴容為2個副本/Pod，隨后的幾分鐘內，CPU使用并未下降，這是因為雖然工作負載進行了擴容，但新創建的Pod并不一定創建成功，一般是因為資源不足Pod處于Pending狀態，此時需同步進行節點擴容。
如下圖所示，工作負載的副本數已通過動態擴容達到8，但因為沒有充足的vCPU和內存資源，會被k8s集群標記為“實例調度失敗”。
之后工作負載CPU使用率一直保持在99%以上，工作負載持續進行擴容，副本數從2個擴容到4個，再擴容到8個最后擴容至12個。觀察負載和HPA策略的詳情，從事件中可以看到負載的擴容的過程和策略生效的時間線，如下所示。
與此同時，查看節點池中的節點數量，發現在剛才工作負載擴容的同時，節點數量也擴容了。在CCE控制臺中可以看到伸縮歷史，節點數量會根據CA及autoscaler策略，通過判斷Pod的Pending狀態進行擴容。
另外還可以看到CA策略也執行了一次，當集群中CPU分配率大于70%，將節點池中節點數量從2擴容到了3。
本例中節點擴容機制具體是這樣：
?Pod數量變為4后，由于沒有資源，Pod處于Pending狀態，觸發了autoscaler默認的擴容策略，將節點數量進行增加。
?同時因為集群中CPU分配率大于70%，觸發了CA策略，從而將節點數增加一個，從控制臺上伸縮歷史可以看出來。根據分配率擴容，可以保證集群一直處于資源充足的狀態。
本例中啟動壓測時設置了壓力持續時間，因此當壓測工具停止打壓后，觀察負載Pod數量。CPU負載快速下降，工作負載開始縮容，工作負載副本數也快速由12縮容至2個，最后恢復到1個副本。
觀察負載和HPA策略的詳情，從事件中可以看到負載的縮容過程和策略生效的時間線，在控制臺中同樣可以看到HPA策略生效歷史。
再繼續觀察，會看到節點池中的節點數量會被不斷縮容。
最終，節點池節點數量將穩定在2。
這里節點沒有繼續被縮容，是因為節點池中這兩個節點都存在namespace為kube-system的Pod（且不是DaemonSets創建的Pod）。關于節點在什么情況下不會被縮容請參考CCE幫助中心
彈性伸縮 > 集群/節點彈性伸縮 > 節點伸縮原理。
如需繼續縮容，可編輯節點池，手動減少其節點數量。
總結
通過上述的實踐可以看到，使用CCE的HPA+CA機制，可以很容易做到工作負載及節點的彈性伸縮，且節點和Pod的伸縮過程可以非常方便的觀察到，使用HPA+CA做彈性伸縮能夠滿足大部分業務場景需求。
