• 1. 原生vpa簡(jiǎn)介
  • 1.1 原生vpa用法
  • 1.2 原生的vpa工作邏輯
  • 1.3 原生vpa存在的問題

1. 原生vpa簡(jiǎn)介

VPA 全稱 Vertical Pod Autoscaler，即垂直 Pod 自動(dòng)擴(kuò)縮容，可以根據(jù)容器資源使用情況自動(dòng)設(shè)置 CPU 和 內(nèi)存 的請(qǐng)求值，從而允許在節(jié)點(diǎn)上進(jìn)行適當(dāng)?shù)恼{(diào)度，以便為每個(gè) Pod 提供適當(dāng)?shù)馁Y源。它既可以縮小過度請(qǐng)求資源的容器，也可以根據(jù)其使用情況隨時(shí)提升資源不足的容量。注意：VPA 不會(huì)改變 Pod 的資源限制值。

vpa的優(yōu)點(diǎn)：

使用VPA可以帶來以下好處：

• 因?yàn)?Pod 完全用其所需，所以集群節(jié)點(diǎn)使用效率高
• Pod 會(huì)被安排到具有適當(dāng)可用資源的節(jié)點(diǎn)上
• 不必運(yùn)行耗時(shí)的基準(zhǔn)測(cè)試任務(wù)來確定 CPU 和內(nèi)存請(qǐng)求的合適值。
• VPA 可以隨時(shí)調(diào)整 CPU 和內(nèi)存請(qǐng)求，而無需執(zhí)行任何操作，因此可以減少維護(hù)時(shí)間

vpa的缺點(diǎn):

• pod資源的調(diào)整會(huì)導(dǎo)致pod重啟，可能還會(huì)調(diào)度到不同的節(jié)點(diǎn)上
• pod默認(rèn)使用 metricServer，官方并沒有說明如何使用custom metric server來提供指標(biāo)數(shù)據(jù)

vpa項(xiàng)目來源autoscaler下面的一個(gè)子項(xiàng)目，github地址為：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler

1.1 原生vpa用法

和hpa一樣，vpa只需要?jiǎng)?chuàng)建deploy, 和 vpa對(duì)象即可。

(1) 創(chuàng)建deploy, 不用額外的指定。

可以通過vpaObservedContainers針對(duì)某一個(gè)容器的值進(jìn)行推薦

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: zx-vpa-test
    project: test
    sym-apiversion: v3
    sym-app: zx-vpa
    sym-manager-injected: "true"
  name: zx-vpa
  namespace: test-test
spec:
  progressDeadlineSeconds: 600
  replicas: 2
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: zx-vpa-test
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:         
      creationTimestamp: null
      labels:
        app: zx-vpa-test
        project: test
        sym-apiversion: v3
        sym-app: zx-vpa
        sym-manager-injected: "true"
        uuid: 96402213-d9fa-4c97-8723-51ca0249d55b
      name: zx-vpa-test
    spec:
      containers:
      - command:
        - sleep
        - "36000"
        image: dockerhub.nie.netease.com/fanqihong/ubuntu:stress
        imagePullPolicy: IfNotPresent
        name: zx-vpa
        resources:
          limits:
            cpu: "1"
            memory: 131072k
          requests:
            cpu: "1"
            memory: 131072k
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      - command:
        - sleep
        - "36000"
        image: ncr.nie.netease.com/zouxiang/testcpu:v1
        imagePullPolicy: IfNotPresent
        name: zx-vpa2
        resources:
          limits:
            cpu: "2"
            memory: 200Mi
          requests:
            cpu: "2"
            memory: 200Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File

（2）創(chuàng)建vpa對(duì)象

apiVersion: "autoscaling.k8s.io/v1beta2"
kind: VerticalPodAutoscaler
metadata:
  name: hamster-vpa  
spec:
  targetRef:
    apiVersion: "apps/v1"       // 指定需要綁定的對(duì)象（上訴的deploy）
    kind: Deployment
    name: zx-vpa
  updatePolicy:
    updateMode: "Auto"          // 更新模式

VPA 有以下四種更新策略：

• Initial：僅在 Pod 創(chuàng)建時(shí)修改資源請(qǐng)求，以后都不再修改。
• Auto：默認(rèn)策略，在 Pod 創(chuàng)建時(shí)修改資源請(qǐng)求，并且在 Pod 更新時(shí)也會(huì)修改。
• Recreate：類似 Auto，在 Pod 的創(chuàng)建和更新時(shí)都會(huì)修改資源請(qǐng)求，不同的是，只要Pod 中的請(qǐng)求值與新的推薦值不同，VPA 都會(huì)驅(qū)逐該 Pod，然后使用新的推薦值重新啟一個(gè)。因此，一般不使用該策略，而是使用 Auto，除非你真的需要保證請(qǐng)求值是最新的推薦值。
• Off：不改變 Pod 的資源請(qǐng)求，不過仍然會(huì)在 VPA 中設(shè)置資源的推薦值。pod不會(huì)有任何變化，vpa對(duì)象的推薦值會(huì)一直變化

1.2 原生的vpa工作邏輯

原生的vpa架構(gòu)圖如下所示，一個(gè)常見的vpa處理邏輯如下：

（1）創(chuàng)建好1.1所示的deploy, vpa對(duì)象

（2）Recommender組件發(fā)現(xiàn)有vpa存在，就會(huì)去metrics server獲取所有vpa綁定pod的cpu, mem當(dāng)前使用值（1分鐘平均使用），然后結(jié)合歷史數(shù)據(jù)（vpa維護(hù)的一個(gè)crd對(duì)象），給出當(dāng)前vpa所有容器的推薦值。（會(huì)將當(dāng)前的cpu,mem值當(dāng)做歷史數(shù)據(jù)保持起來）

（3）updater組件 負(fù)責(zé)監(jiān)聽vpa資源變化，一旦vpa有推薦值。就會(huì)判斷當(dāng)前的推薦值是否需要 更新到 綁定的POD.

判斷邏輯比如：資源推薦值 和當(dāng)前POD正在使用的值是否差距過大，過大則需要更新，不大則忽略。

updater更新的邏輯非常簡(jiǎn)單，就是直接將該pod驅(qū)逐

（4）admissoin controller組件 負(fù)責(zé)pod的重建，一旦發(fā)現(xiàn)有pod重建，并且該pod受到vpa控制，修改pod的資源為vpa推薦值。

所以，依靠 recommender，updater, admissoin controller 這三個(gè)組件，就實(shí)現(xiàn)了pod資源的更新。

image-20220708171459455.png

1.3 原生vpa存在的問題

（1）監(jiān)控?cái)?shù)據(jù)的獲取問題。原生的使用是metrics Sever, 無法自定義metric server

（2）pod資源更新需要重建

（3）vpa目前推薦值沒有上限和下限