如何爲Kubernetes配置Pod水平自動擴展

介   紹


Kubernetes有一個強大的功能,它能在運行的服務上進行編碼並配置彈性伸縮。如果沒有彈性伸縮功能,就很難適應部署的擴展和滿足SLAs。這一功能稱爲Horizontal Pod Autoscaler (HPA)。


爲什麼使用HPA


使用HPA,您可以根據資源的使用情況或者自定義的指標,實現部署的自動擴展和縮減,讓部署的規模接近於實際服務的負載。


HPA可以爲您的服務帶來兩個直接的幫助:

  1. 在需要計算和內存資源時提供資源,在不需要時釋放它們

  2. 按需增加/降低性能以實現SLA


HPA工作原理


HPA會根據監測到的CPU/內存利用率(資源指標),或基於第三方指標應用程序(如Prometheus、Datadog等)提供的自定義指標,自動調整副本控制器、部署或者副本集合的pods數量(定義最小和最大pods數)。HPA是一種控制迴路,它的週期由Kubernetes的controller manager –horizontal-pod-autoscaler-sync-period標誌控制(默認值是30s)。


1.png

HPA工作圖解


HPA定義


HPA是Kubernetes中彈性伸縮API組下的一個API資源。當前穩定的版本是autoscaling/v1,它只提供了對CPU自動縮放的支持。如果您想額外獲得對內存和自定義指標的支持,可以使用Beta版本autoscaling/v2beta1

 

您可以在HPA API對象中看到更多信息:https://git.k8s.io/community/contributors/design-proposals/autoscaling/horizontal-pod-autoscaler.md#horizontalpodautoscaler-object

 

在一般情況下HPA是由kubectl來提供支持的。可以使用kubectl進行創建、管理和刪除:


創建HPA:

  • 帶有manifest: kubectl create -f <HPA_MANIFEST>

  • 沒有manifest(只支持CPU):kubectl autoscale deployment hello-world –min=2 --man=5 –-cpu-percent=50

獲取hpa信息:

  • 基本信息: kubectl get hpa hello-world

  • 細節描述: kubectl describe hpa hello-world

刪除hpa:

  • kubectl delete hpa hello-world


下面是一個HPA manifest定義的例子:


2.png


  • 這裏使用了autoscaling/v2beta1版本,用到了cpu和內存指標

  • 控制hello-world項目部署的自動縮放

  • 定義了副本的最小值1

  • 定義了副本的最大值10

  • 當滿足時調整大小:

      CPU使用率超過50%

      內存使用超過100Mi


安  裝


在HPA可以在Kubernetes集羣上使用之前,有一些元素需要在系統中安裝和配置。


需  求


檢查確定Kubernetes集羣服務正在運行並且至少包含了這些標誌:

  • kube-api: requestheader-client-ca-file

  • kubelet: read-only-port 在端口10255

  • kube-controller: 可選,只在需要和默認值不同時使用

  • horizontal-pod-autoscaler-downscale-delay:”5m0s”

  • horizontal-pod-autoscaler-upscale-delay:”3m0s”

  • horizontal-pod-autoscaler-sync-period: “30s”

對於RKE,Kubernetes集羣定義,請確定您已經在服務部分添加了這些行。如果要在Rancher v2.0.X UI中執行此操作,請打開”Cluster options”- “Edit as YAML”並添加下面的定義:


3.png


要部署指標服務,您的Kubernetes集羣必須要正確配置和部署。


注意:在部署和測試示例時,本文使用的是Rancher v2.0.6以及k8s v1.10.1集羣


資源指標


如果HPA想要使用資源指標,那麼就需要用到metrics-server包了,它在Kubernetes集羣中的kube-system命名空間裏。


按照下面的步驟實現:

  1. 配置kubectl連接到正確的Kubernetes集羣

  2. 克隆metrics-server的Github倉庫:git clone https://github.com/kubernetes-incubator/metrics-server

  3. 安裝metrics-server包(假設Kubernetes升級到了1.8):kubectl create -f metrics-server/deply/1.8+/

  4. 檢查metrics-server是否運行正常。在命名空間kube-system可以檢查服務pod以及日誌


4.png


5. 檢查是否可以從kubectl訪問指標API:如果您要直接訪問Kubernetes集羣,請使用kubectl config的服務器URL,比如‘https://:6443’


5.png


如果您想通過Rancher訪問Kubernetes集羣,那麼kubectl config的服務器URL就要像:https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>,即你還要在原本的

API路徑後面加上/k8s/clusters/<CLUSTER_ID>


6.png


自定義指標(Prometheus)


自定義指標作爲一種資源,可以由許多第三方應用程序提供。我們準備在演示中使用Prometheus。假設Prometheus已經部署在您的Kubernetes集羣中了,它可以從pods、節點、命名空間等等地方獲得正確的指標,我們將使用Prometheus url,http://prometheus.mycompany.io,它公開於端口80。


Prometheus可以在Rancher v2.0目錄中部署。如果在Kubernetes集羣上沒有運行,那麼就在Rancher目錄中部署它。


如果HPA想要使用Prometheus中的自定義指標,那麼Kubernetes集羣上的kube-system命名空間則需要用到k8s-prometheus-adapter。爲了方便k8s-prometheus-adapter的安裝,我們將使用banzai-charts提供的Helm chart。


通過下面的步驟可以使用這一chart:

1.   在k8s集羣上初始化helm


7.png


2.   從Github倉庫克隆banzai-charts


8.png


3.   安裝prometheus-adapter,指定具體的Prometheus URL和端口


9.png


4.   檢查prometheus-adapter是否運行正常。檢查服務pod和日誌是在kube-system命名空間下


10.png


5.   檢查指標API是否可以從kubectl進行訪問:直接訪問Kubernetes集羣,那麼kubectl config的服務器URL就比如https://<K8s_URL>:6443


12.png


如果是從Rancher進行訪問,那麼kubectl config的服務器URL就是https://<RANCHER_URL>/k8s/clusters/<CLUSTER_ID>,需要加上後綴/k8s/clusters/<CLUSTER_ID> 


12.png


ClusterRole和ClusterRoleBinding


默認情況下,HPA將嘗試通過用戶的system:anonymous讀取(系統的和自定義的)指標。用戶需要定義view-resource-metrics以及view-custom-metrics,而ClusterRole和ClusterRoleBinding將它們分配給system:anonymous來打開對指標的讀取訪問。


要實現這一點,需要下面的步驟:

1.    配置kubectl正確連接到k8s集羣

2.   複製ClusterRole和ClusterRoleBinding文件:

13.png
14.png


在Kubernetes集羣上創建它們(如果你想使用自定義指標的話):


15.png


 服務部署


爲了讓HPA正常工作,服務部署應該要有容器的資源請求定義。


我們用一個hello-world的例子來測試一下HPA是否正常工作。


我們根據下面步驟進行,第一步,正確配置kubectl連接到k8s集羣,第二步,複製hello-world的部署文件。


16.png


1.   在k8s集羣上部署它


17.png


2.   爲資源或者自定義指標複製HPA

3.   資源指標:

``` apiVersion: autoscaling/v2beta1 kind: HorizontalPodAutoscaler metadata: name: hello-world namespace: default spec: scaleTargetRef: apiVersion: extensions/v1beta1 kind: Deployment name: hello-world minReplicas: 1 maxReplicas: 10 metrics:

  • type: Resource resource:name: cpu targetAverageUtilization: 50

  • type: Resource resource: name: memory targetAverageValue: 1000Mi

  • 自定義指標(和資源指標一樣,不過需要添加自定義的cpu_system指標)


18.png


4.   獲得HPA信息和描述,並且檢查資源指標是否已經顯示出來:

資源指標:


19.png


自定義指標:


20.png


5.   給我們的服務產生負載,進行彈性伸縮的測試。這裏可以使用各種各樣的工具(產生負載),不過這裏我們使用https://github.com/rakyll/hey 向hello-world服務發出http請求,並觀察彈性伸縮是否正常工作


6.   觀察自動的擴縮容

  • 資源指標:

  • 當cpu利用率達到目標比例時,自動擴展到2個pods


21.png
22.png


當cpu使用率達到目標值horizontal-pod-autoscaler-upscale-delay默認超過3分鐘時,擴展到3個pods:


23.png
24.png


當cpu使用率降到目標值horizontal-pod-autoscaler-downscale-delay默認超過5分鐘時,縮小到1個pods:


25.png
26.png


自定義指標:

  • 當cpu利用率達到目標時擴展到2個pods:


27.png
28.png


當cpu_system利用率限制達到目標值,擴展到3個pods:


29.png
30.png


當cpu利用率限制達到目標值horizontal-pod-autoscaler-upscale-delay超過3分鐘(默認),擴展到4個pods:


31.png
32.png


當所有的指標都低於目標值horizontal-pod-autoscaler-downscale-delay 超過5分鐘,自動縮小到1個pods:


33.png
34.png


總  結


我們看到了如何在Rancher上使用Kubernetes HPA來進行部署的彈性擴縮容。這是一個非常出色好用的功能,可以讓部署的規模適應於實際的服務負載並且實現服務SLA。


我們還看到,如何在kube-controller上對horizontal-pod-autoscaler-downscale-delay (默認5分鐘)和 horizontal-pod-autoscaler-upscale-delay (默認3分鐘) 進行參數化,調整擴縮容的反應。


對於我們的自定義指標,我們在例子cpu_system中進行了展示,不過我們還可以使用所有導出給Prometheus的指標,並瞭解當前服務的性能,比如http_request_numberhttp_response_time等等。

 

爲了讓之後HPA更容易使用,我們現在正努力將metric-server作爲插件集成到RKE集羣部署中。它現在已經包含在RKE v0.1.9-rc2中進行測試,目前還尚未得到官方的支持。它會在RKE v0.1.9版本中得到支持。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章