服務上線就要頂的住壓力、扛的住考驗，不然挨說的還是我們這幫做事的兄弟，還記得上圖這個場景嗎
老辦法是服務集群部署，但總歸有個上限，之前跟阿里合作的時候他們有個彈性計算可以通過設置CPU的閥值來動態擴展和收縮計算能力，那時感覺很有逼格，至少在當時我們常規的做法很難做到，沒想到時至今日有了Kubernetes我們能也揚眉吐氣了，看我來給大家實實在在的秀一把。
Kubernetes的自動擴容針對的是ReplicationController的，它會監控所有Pods的CPU使用情況，如果超過比例就啟動更多的Pods來提供服務，反之減少Pods，在一般的情況下我們不會設置Pods的CPU的上限，但要使用自動擴容就要設置它的閥值因此也要設置Pods的CPU使用上限，不然Kubernetes沒辦法計算它的占用比例，所以我們在創建RC的時候就要指定每個Pod CPU資源占用的上限
配置
apiVersion: v1
kind: ReplicationController
metadata:
name: thrift-c
namespace: thrift-demo
spec:
replicas:1
selector:
app: thrift-c
template:
metadata:
name: thrift-c
labels:
app: thrift-c
spec:
containers:
- name: thrift-c
resources:
requests:
cpu: 200m
image: registry2.io/thrift/thrift-c:0.0.2
imagePullPolicy: Always
ports:
- containerPort: 9091
imagePullSecrets:
- name: registry2key
注意resources的配置，指定CPU最高占用為200m，如果是修改的話必須要刪除RC，重新創建，apply不行，另外注意我們這里的replicas是1。
在Dashboard中查看，是不是生效了，
壓力測試
我們的配置確定生效之后就要看Kubernetes彈性擴容的效果了，第一步要先給我們的服務增加自動擴容的能力，有兩種方法，一種是配置文件，另一種是通過Kubectl命令完成，看命令
kubectl autoscale rc thrift-c -nthrift-demo --max=10 --cpu-percent=10 --min=1
參數--max是彈性擴容最大Pods數量，--min自然是最小數量，--cpu-percent是閥值，是一個百分比這里配置的是相當於10%，這條命令運行之后就給我們指定的RC thrift-c增加了自動擴容的能力，查看一下
可以看到target和current以及數量等信息，目前我們沒有訪問量
第二步，加壓，增加訪問量和並發，給你一條簡單的命令
while true; do wget -q -O- http://test.k8s.io/hi?name=3213; done
我分別在三台機器上執行了這條命令，壓力直線上升，
當CPU超過10%的時候我們看下Pods的數量
Pods從一個迅速給擴容到4個，如果服務能力沒到達到要求還會增加Pods數量，當我把壓力測試命令終止后CPU降下來時Kubernetes大概過了幾分鍾把Pods減少到最初的一個，我反復測試了多次，這個功能非常好用也很穩定，它能夠及時的根據服務的壓力做出響應，在收縮的時候有延遲可能是防止短時間內再次發生，CPU穩定一段時間后Pods被減少到我們配置的--min個。
有了這個功能我們再也不怕突發其來的壓力和服務器宕機，瓶頸就丟給網絡和磁盤IO以及數據庫了，服務器方面如果有宕機Kubernetes會把它上面的Pods全部移到其它結點上啟動起來，保證你的Pods始終是運行的，但有一點Kubernetes的Master是單點運行的，在后面如果有空研究一下Master的高可用，其實已經有很多網友研究過並給出解決辦法，如果有興趣可以先了解一下。