服務上線就要頂的住壓力、扛的住考驗，不然挨說的還是我們這幫做事的兄弟，還記得上圖這個場景嗎

老辦法是服務叢集部署，但總歸有個上限，之前跟阿里合作的時候他們有個彈性計算可以通過設定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的高可用，其實已經有很多網友研究過並給出解決辦法，如果有興趣可以先了解一下。