1. 原生vpa简介
VPA 全称 Vertical Pod Autoscaler，即垂直 Pod 自动扩缩容，可以根据容器资源使用情况自动设置 CPU 和 内存 的请求值，从而允许在节点上进行适当的调度，以便为每个 Pod 提供适当的资源。它既可以缩小过度请求资源的容器，也可以根据其使用情况随时提升资源不足的容量。注意：VPA 不会改变 Pod 的资源限制值。
vpa的优点：
使用VPA可以带来以下好处：
- 因为 Pod 完全用其所需，所以集群节点使用效率高
- Pod 会被安排到具有适当可用资源的节点上
- 不必运行耗时的基准测试任务来确定 CPU 和内存请求的合适值。
- VPA 可以随时调整 CPU 和内存请求，而无需执行任何操作，因此可以减少维护时间
vpa的缺点:
- pod资源的调整会导致pod重启，可能还会调度到不同的节点上
- pod默认使用 metricServer，官方并没有说明如何使用custom metric server来提供指标数据
vpa项目来源autoscaler下面的一个子项目，github地址为：https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler
1.1 原生vpa用法
和hpa一样，vpa只需要创建deploy, 和 vpa对象即可。
(1) 创建deploy, 不用额外的指定。
可以通过vpaObservedContainers针对某一个容器的值进行推荐
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）创建vpa对象
apiVersion: "autoscaling.k8s.io/v1beta2"
kind: VerticalPodAutoscaler
metadata:
name: hamster-vpa
spec:
targetRef:
apiVersion: "apps/v1" // 指定需要绑定的对象（上诉的deploy）
kind: Deployment
name: zx-vpa
updatePolicy:
updateMode: "Auto" // 更新模式
VPA 有以下四种更新策略：
- Initial：仅在 Pod 创建时修改资源请求，以后都不再修改。
- Auto：默认策略，在 Pod 创建时修改资源请求，并且在 Pod 更新时也会修改。
- Recreate：类似
Auto，在 Pod 的创建和更新时都会修改资源请求，不同的是，只要Pod 中的请求值与新的推荐值不同，VPA 都会驱逐该 Pod，然后使用新的推荐值重新启一个。因此，一般不使用该策略，而是使用Auto，除非你真的需要保证请求值是最新的推荐值。 - Off：不改变 Pod 的资源请求，不过仍然会在 VPA 中设置资源的推荐值。pod不会有任何变化，vpa对象的推荐值会一直变化
1.2 原生的vpa工作逻辑
原生的vpa架构图如下所示，一个常见的vpa处理逻辑如下：
（1）创建好1.1所示的deploy, vpa对象
（2）Recommender组件发现有vpa存在，就会去metrics server获取所有vpa绑定pod的cpu, mem当前使用值（1分钟平均使用），然后结合历史数据（vpa维护的一个crd对象），给出当前vpa所有容器的推荐值。（会将当前的cpu,mem值当做历史数据保持起来）
（3）updater组件 负责监听vpa资源变化，一旦vpa有推荐值。就会判断当前的推荐值是否需要 更新到 绑定的POD.
判断逻辑比如：资源推荐值 和当前POD正在使用的值是否差距过大，过大则需要更新，不大则忽略。
updater更新的逻辑非常简单，就是直接将该pod驱逐
（4）admissoin controller组件 负责pod的重建，一旦发现有pod重建，并且该pod受到vpa控制，修改pod的资源为vpa推荐值。
所以，依靠 recommender，updater, admissoin controller 这三个组件，就实现了pod资源的更新。
1.3 原生vpa存在的问题
（1）监控数据的获取问题。原生的使用是metrics Sever, 无法自定义metric server
（2）pod资源更新需要重建
（3）vpa目前推荐值没有上限和下限
