Kubernetes+Docker微服務實踐之路--彈性擴容

服務上線就要頂的住壓力、扛的住考驗，否則挨說的仍是咱們這幫作事的兄弟，還記得上圖這個場景嗎

老辦法是服務集羣部署，但總歸有個上限，以前跟阿里合做的時候他們有個彈性計算能夠經過設置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的高可用，其實已經有不少網友研究過並給出解決辦法，若是有興趣能夠先了解一下。