iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 25
1
DevOps

Kubernetes 30天學習筆記系列 第 25

[Day 25] 實現 Horizontal Pod Autoscaling - HPA

前言

在昨天的學習筆記中介紹到如何監控 Kubernetes 上的資源使用 後,今天筆者想跟大家分享如何在 Kubernetes 上實現 Autosacling。在許多實際場景中,應用服務常常需因應不同流量而配置不同的資源。好比:原本的應用服務可能每天都只有 10 人使用,我們只需要架設一台小 server 即可應付這些流量;當有天應用服務因為某些因素使用人數上升到 10 萬人,可能我們原有的資源不足以回應這些流量,導致使用者無法連上該應用服務。如果這時候,系統能幫我們根據目前的資源使用率,決定是否自動調整資源(像是加開 server)來回應這些流量就太好了。幸好,這樣的功能 Kubernetes 也幫我們想到了。

今天的學習筆記將介紹,

什麼是 Horizontal Pod Autoscaling

前言所提,不論身為運維人員或是開發者,都希望系統能根據目前的資源使用率,決定是否自動調整資源來回應這些流量,避免服務無法運行而失去使用者。在目前許多第三方雲端服務供應商也都提供 Autosacling 的功能,像是 AWS 或是 Google Cloud Platfrom。而 Kubernetes 本身也提供一個 API - Horizontal Pod Autoscaling,讓我們可以針對不同的 Pod 的使用量,來決定是否新增或減少 Pod 的數量。

以下以 helloworld-deployment.yamlhelloworld-hpa.yaml 為例,

# helloworld-deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: helloworld-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: helloworld-pod
  template:
    metadata:
      labels:
        app: helloworld-pod
    spec:
      containers:
      - name: my-pod
        image: zxcvbnius/docker-demo:latest
        ports:
        - containerPort: 3000
        resources:
          requests:
            cpu: 200m

可以發現,在 spec 的地方多了一個 resources 的欄位,

  • spec.resources.requests.cpu
    透過該欄位的設置,代表當 Kubernetes 在運行該 Pod 時,需要配置 200m CPU 給該 Pod。200m 同等於 200milicpu(milicore),代表要求一個 CPU 20% 的資源。然而直得注意的是,若該 Node 是多核(multiple cores),則 200m 代表要求使用每一核(core)百分之二十的資源。更多關於 spec.resources.requests 可以參考該連結

在看完,helloworld-deployment.yaml 後,來看看 helloworld-hpa.yaml

# helloworld-hpa.yaml
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: helloworld-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1beta2
    kind: Deployment
    name: helloworld-deployment
  minReplicas: 2
  maxReplicas: 5
  targetCPUUtilizationPercentage: 50
  • spec.scaleTargetRef
    指定 autoscaling 的對象

  • spec.targetCPUUtilizationPercentage
    helloworld-deployment 為例,我們指定 CPU 200m 的資源,代表當該 helloworld-pod CPU 使用率達到 100 m 時,HorizontalPodAutoscaler 就會幫我們新產生一個 Pod

支持 Colddown / Delay

Horizontal Pod Autoscaling 也支援 Colddown 與 Delay,避免 Horizontal Pod Autoscaling 一次產生太多 Pod 或是關掉太多 Pod。在建立 Kubernetes Cluster 時,可以加入 --horizontal-pod-autoscaler-downscale-delay--horizontal-pod-autoscaler-upscale-delay 去限制 Autoscaling 的回應時間。

  • --horizontal-pod-autoscaler-downscale-delay
    代表 autoscaling 須等多久的時間才能進行 downscale,預設為 5 分鐘

  • --horizontal-pod-autoscaler-upscale-delay
    代表 autoscaling 須等多久的時間才能進行 upscale,預設為 3 分鐘

實作:在 minikube 中實現 Horizontal Pod Autoscaling

需要注意的是,使用 Horizontal Pod Autoscaling 之前,minikube 必須先安裝好 heapster ,讓 Horizontal Pod Autoscaling 可以知道目前 Kubernetes Cluster 中的資源使用狀況(metrics)。若還是不知道怎麼在 Kubernetes 安裝 heapster 的讀者,不妨參考昨日的學習筆記

在了解 helloworld-deployment.yamlhelloworld-hpa.yaml 後,透過 kubectl create 創建 helloworld-deployment,指令如下,

$ kubectl create -f ./helloworld-depolyment.yaml
deployment "hello-deployment" created

接著創建一個 helloworld-service ,讓 Kubernetes Cluster 中的其他物件可以訪問到 helloworld-deployment,指令如下:

$ kubectl expose deploy helloworld-deployment \
> --name helloworld-service \
> --type=ClusterIP
service "helloworld-service" exposed

kubectl get 查看,

接著創建 helloworld-hpa,指令如下

$ kubectl create -f ./helloworld-hpa.yaml
horizontalpodautoscaler "helloworld-hpa" created

kubectl get 檢視目前狀況,

可以看到 TARGETS 的欄位目前是,<unknown> / 50%。稍等久一點,等 helloworld-hpaheapster 抓到目前的資料則可看到數字的變化,

Grafana 也可以觀察到 helloworld-deployment 的狀態,正如我們在 YAML 設定檔要求 200 milicores,目前的使用率為 0%

接著,我們要在 minikube 裡面運行一個 server 不斷去訪問 helloworld-pod 使 CPU 的使用率超過 100 m,再來觀察 helloworld-hpa 是否會偵測到幫我們新增 Pod,指令如下:

$ kubectl run -i --tty alpine --image=alpine --restart=Never -- sh

若是忘了上述指令的讀者,不妨回頭看看 [Day 5] 在 Minikube 上跑起你的 Docker Containers - Pod & kubectl 常用指令 裡面有介紹到該指令的功用唷。

接著安裝 curl 套件,

接著訪問 helloworld-service,會吐回 Hello World! 的字串,

$ curl http://10.108.56.58:3000
Hello World!

接著,我們設置一個無窮迴圈,透過 curl 不斷送請求給 helloworld-deployment,指令如下,

$ while true; do curl http://10.108.56.58:3000; done

接著,再回頭看 helloworld-hpa 的狀態,可以發現目前 CPU 的使用率以超出我們所設定的 50%,

若再觀察一陣子,會看到 helloworld-deployment底下已有 4 個 Pod,代表 helloworld-hpa 幫我們實現了 Autoscaling

我們停止 curl 指令,過了一陣子之後可以發現原本 4 個 Pod 已經退回到原本設定的 2 個了

若從 Grafana 也可以看到剛剛的變化,

總結

Horizontal Pod Autoscaling 可以說是 Kubernetes 中一個不可或缺的 API,透過 Kubernetes 自動化的管理更增加了應用服務的可用性。在到今天為止的學習筆記中,我們介紹了基礎 & 進階 的 Kubernetes API,希望讀者在看完之後都能有所收穫。在學習筆記的最後幾天,我們將從管理層面介紹 Kubernetes,讓讀者更能掌握 Kubernetes 在實際場景中的運用。

Q&A

最後,歡迎大家給予建議與討論,如果能按個讚給些鼓勵也是很開心唷 :)

參考連結


上一篇
[Day 24] 如何在 Kubernetes 上監控服務的資源使用 - Heapster
下一篇
[Day 26] 如何管理 Kubernetes 上的資源分配 - Resource Quotas
系列文
Kubernetes 30天學習筆記29

尚未有邦友留言

立即登入留言