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源牺氨。它既可以縮小過(guò)度請(qǐng)求資源的容器设捐，也可以根據(jù)其使用情況隨時(shí)提升資源不足的容量酪呻。注意：VPA 不會(huì)改變 Pod 的資源限制值。
vpa的優(yōu)點(diǎn)：
使用VPA可以帶來(lái)以下好處：
- 因?yàn)?Pod 完全用其所需界轩，所以集群節(jié)點(diǎn)使用效率高
- Pod 會(huì)被安排到具有適當(dāng)可用資源的節(jié)點(diǎn)上
- 不必運(yùn)行耗時(shí)的基準(zhǔn)測(cè)試任務(wù)來(lái)確定 CPU 和內(nèi)存請(qǐng)求的合適值画饥。
- VPA 可以隨時(shí)調(diào)整 CPU 和內(nèi)存請(qǐng)求，而無(wú)需執(zhí)行任何操作浊猾，因此可以減少維護(hù)時(shí)間
vpa的缺點(diǎn):
- pod資源的調(diào)整會(huì)導(dǎo)致pod重啟抖甘，可能還會(huì)調(diào)度到不同的節(jié)點(diǎn)上
- pod默認(rèn)使用 metricServer，官方并沒(méi)有說(shuō)明如何使用custom metric server來(lái)提供指標(biāo)數(shù)據(jù)
vpa項(xiàng)目來(lái)源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, 不用額外的指定幅疼。
可以通過(guò)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)求滑肉，不過(guò)仍然會(huì)在 VPA 中設(shè)置資源的推薦值。pod不會(huì)有任何變化摘仅，vpa對(duì)象的推薦值會(huì)一直變化
1.2 原生的vpa工作邏輯
原生的vpa架構(gòu)圖如下所示靶庙，一個(gè)常見(jiàn)的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ù)保持起來(lái)）
（3）updater組件 負(fù)責(zé)監(jiān)聽(tīng)vpa資源變化矾端，一旦vpa有推薦值掏击。就會(huì)判斷當(dāng)前的推薦值是否需要 更新到 綁定的POD.
判斷邏輯比如：資源推薦值 和當(dāng)前POD正在使用的值是否差距過(guò)大，過(guò)大則需要更新须床，不大則忽略铐料。
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資源的更新愧沟。
1.3 原生vpa存在的問(wèn)題
（1）監(jiān)控?cái)?shù)據(jù)的獲取問(wèn)題。原生的使用是metrics Sever, 無(wú)法自定義metric server
（2）pod資源更新需要重建
（3）vpa目前推薦值沒(méi)有上限和下限
