1. 程式人生 > >Openstack+Kubernetes+Docker微服務實踐之路--彈性擴容

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

57355-20161124160443534-1985216280.jpg

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

老辦法是服務叢集部署,但總歸有個上限,之前跟阿里合作的時候他們有個彈性計算可以通過設定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中檢視,是不是生效了,

57355-20161124160502034-1148528239.png

壓力測試

我們的配置確定生效之後就要看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增加了自動擴容的能力,檢視一下

57355-20161124160518675-254229269.jpg

可以看到target和current以及數量等資訊,目前我們沒有訪問量

第二步,加壓,增加訪問量和併發,給你一條簡單的命令

while true; do wget -q -O- http://test.k8s.io/hi?name=3213; done

我分別在三臺機器上執行了這條命令,壓力直線上升,

57355-20161124160537737-1202948857.jpg

當CPU超過10%的時候我們看下Pods的數量

57355-20161124160549346-732181430.png

Pods從一個迅速給擴容到4個,如果服務能力沒到達到要求還會增加Pods數量,當我把壓力測試命令終止後CPU降下來時Kubernetes大概過了幾分鐘把Pods減少到最初的一個,我反覆測試了多次,這個功能非常好用也很穩定,它能夠及時的根據服務的壓力做出響應,在收縮的時候有延遲可能是防止短時間內再次發生,CPU穩定一段時間後Pods被減少到我們配置的--min個。

有了這個功能我們再也不怕突發其來的壓力和伺服器宕機,瓶頸就丟給網路和磁碟IO以及資料庫了,伺服器方面如果有宕機Kubernetes會把它上面的Pods全部移到其它結點上啟動起來,保證你的Pods始終是執行的,但有一點Kubernetes的Master是單點執行的,在後面如果有空研究一下Master的高可用,其實已經有很多網友研究過並給出解決辦法,如果有興趣可以先了解一下。