kubernetes基於Metrics Server的HPA彈性伸縮pod

概念

HPA是kubernetes裏面pod彈性伸縮的實現,它能根據設置的監控閥值進行pod的彈性擴縮容,目前默認HPA只能支持cpu和內存的閥值檢測擴縮容,但也可以通過custom metric api 調用prometheus實現自定義metric 來更加靈活的監控指標實現彈性伸縮。但hpa不能用於伸縮一些無法進行縮放的控制器如DaemonSet。這裏我們用的是resource metric api.

在這裏插入圖片描述

實現hpa的兩大關鍵

1、監控指標的獲取
早期kubernetes版本是使用hepster,在1.10後面版本更推薦使用metric-server

hepster簡單來說是api-server獲取節點信息,然後通過kubelet獲取監控信息,因爲kubelet內置了cadvisor。

metric-server,簡單來說是通過metric-api來獲取節點信息和監控信息。https://github.com/kubernetes-incubator/metrics-server

2、伸縮判定算法
HPA通過定期(定期輪詢的時間通過–horizontal-pod-autoscaler-sync-period選項來設置,默認的時間爲30秒)查詢pod的狀態,獲得pod的監控數據。然後,通過現有pod的使用率的平均值跟目標使用率進行比較。
pod的使用率的平均值:
監控資源1分鐘使用的平均值/設定的每個Pod的request資源值

擴容的pod數計算公式

TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)

celi函數作用:

返回大於或者等於指定表達式的最小整數

在每次擴容和縮容時都有一個窗口時間,在執行伸縮操作後,在這個窗口時間內,不會在進行伸縮操作,可以理解爲類似等一下放技能的冷卻時間。默認擴容爲3分鐘(–horizontal-pod-autoscaler-upscale-delay),縮容爲5分鐘(–horizontal-pod-autoscaler-downscale-delay)。另外還需要以下情況下才會進行任何縮放avg(CurrentPodsConsumption)/ Target下降9%,進行縮容,增加至10%進行擴容。以上兩條件需要都滿足。

這樣做好處是:

  1. 判斷的精度高,不會頻繁的擴縮pod,造成集羣壓力大。
  2. 避免頻繁的擴縮pod,防止應用訪問不穩定。

在這裏插入圖片描述

實現hpa的條件:

  1. hpa不能autoscale daemonset類型control
  2. 要實現autoscale,pod必須設置request

配置HPA

這裏以kubeadm 部署和的kubernetes 1.11和Rancher2.0部署的kubernetes 1.10爲例
環境信息

操作系統:Centos 7.5
kubernetes版本:v1.14.6

kubeadm方式

將metric-server從github拉取下來

git clone [email protected]:kubernetes-incubator/metrics-server.git
或者手動下載到本地再上傳到主機
https://github.com/kubernetes-incubator/metrics-server

早期kubelet的10255端口是開放,但後面由於10255是一個非安全的端口容易被入侵,所以被關閉了。metric-server默認是從kubelet的10255端口去拉取監控信息的,所以這裏需要修改從10250去拉取

edit  metrics-server-master/deploy/1.8+/metrics-server-deployment.yaml

修改source爲以下內容。

–source=kubernetes.summary_api:https://kubernetes.default?kubeletHttps=true&kubeletPort=10250&insecure=true

apply yaml該文件

kubectl apply -f metrics-server-master/deploy/1.8+/

查看pod和node監控信息

kubectl top pods
kubectl top nodes

在這裏插入圖片描述
創建個Deployment測試

apiVersion: v1
kind: Service
metadata:
  name: autuscalertest
  labels:
    app: autuscalertest
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30110
      protocol: TCP
  selector:
    app: autuscalertest
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: autuscalertest
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: autuscalertest
      annotations:
        prometheus.io/scrape: 'true'
    spec:
      containers:
      - name: podinfod
        image: nginx:alpine
        imagePullPolicy: Never
        ports:
        - containerPort: 80
          protocol: TCP
        resources:
          requests:
            memory: "32Mi"
            cpu: "1m"
          limits:
            memory: "256Mi"
            cpu: "100m"

注意:容器端口爲80,映射主機端口爲9899

配置HPA

創建HorizontalPodAutoscaler類型yaml文件,apply -f

apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: autuscalertest
spec:
  scaleTargetRef:
    apiVersion: extensions/v1beta1
    kind: Deployment
    name: autuscalertest
  minReplicas: 2
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 40
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 45

檢查pods和hpa

在這裏插入圖片描述在這裏插入圖片描述

使用webbench進行壓力測試

  1. 編譯安裝

#wget http://www.ha97.com/code/webbench-1.5.tar.gz
#tar zxvf webbench-1.5.tar.gz
#cd webbench-1.5
#make
#make install

  1. 使用
    webbench -c 1000 -t 12360 http://主機ip:9899/
    在這裏插入圖片描述
    可以看見隨着cpu壓力的增加,已經自動scale了,需要注意的是,scale up是一個階段性的過程,並不是一次性就直接scale到max了,而是一個階段性的過程,判定算法就是上文介紹的內容。
    隔斷時間沒操作壓力下來後,自動縮減pod
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章