使用场景
VPA 自动伸缩特性使容器服务具有非常灵活的自适应能力。应对业务负载急剧飙升的情况，VPA 能够在用 户设定范围内快速扩大容器的 Request。在业务负载变小的情况下，VPA 可根据实际情况适当缩小 Request 节省计算资源。整个过程自动化无须人为干预，适用于需要快速扩容、有状态应用扩容等场景。此外，VPA 可用于向用户推荐更合理的 Request，在保证容器有足够使用的资源的情况下，提升容器的资源利用率。
VPA 优势
相较于 自动伸缩功能 HPA，VPA 具有以下优势：
1、VPA 扩容不需要调整 Pod 副本数量，扩容速度更快。
2、VPA 可为有状态应用实现扩容，HPA 则不适合有状态应用的水平扩容。
3、Request 设置过大，使用 HPA 水平缩容至一个 Pod 时集群资源利用率仍然很低，此时可以通过 VPA 进 行垂直缩容提高集群资源利用率。
VPA限制
社区版 VPA 功能处于试验阶段
1、 自动更新正在运行的 Pod 资源是 VPA 的一项实验功能。当 VPA 更新 Pod 资源时，会导致 Pod 的重 建和重启，并且有可能被调度到其他节点上。
VPA 不会驱逐不在控制器下运行的 Pod。对于此类 Pod，Auto 模式等效于 Initial。
2、VPA 与 HPA 不可同时在 CPU 和内存预留上运行。如需同时运行 VPA 与 HPA，则 HPA 需使用除 CPU 和 内存以外的指标。
3、VPA 使用 Admission Webhook 作为其准入控制器。如果集群中存在其他的 Admission Webhook，需要 确保它们不会与 VPA 的 Admission Webhook 发生冲突。准入控制器的执行顺序定义在 API Server 的配 置参数中。
4、VPA 会处理大多数 OOM（Out Of Memory）事件。
5、VPA 性能尚未在大型群集中进行测试。
6、VPA 对 Pod 资源 Request 的建议值可能会超出可用资源（例如节点资源上限、空闲资源或资源配额）， 并导致 Pod 处于 Pending 状态无法被调度。同时使用 VPA 与 Cluster Autoscaler 可以部分解决此问 题。 CA 可结合 VK 一起使用。
7、与同一个 Pod 匹配的多个 VPA 资源具有未定义的行为。
详细见：
VPA组件
VPA Recommender
1、监视资源利用率并计算目标值，计算方法
2、查看指标历史记录、OOM 事件和 VPA 部署规范并建议公平请求。根据定义的限制请求比例提高/降低限 制
3、Recommender 组件发现有 vpa 存在，就会去 metrics server 获取所有 vpa 绑定 pod 的 cpu, mem 当前使 用值（1 分钟平均使用），然后结合历史数据（vpa 维护的一个 crd 对象），给出当前 vpa 所有容器的推荐 值。（会将当前的 cpu,mem 值当做历史数据保持起来）
VPA Updater
1、驱逐那些需要新资源限制的 pod
2、如果定义了“updateMode: Auto ”，则实现 Recommender 推荐的任何内容
3、监听 vpa 资源变化，一旦 vpa 有推荐值。就会判断当前的推荐值是否需要 更新到 绑定的 POD。判断逻 辑比如：资源推荐值 和当前 POD 正在使用的值是否差距过大，过大则需要更新，不大则忽略。updater 更 新的逻辑非常简单，就是直接将该 pod 驱逐
VPA Admission Controller
1、每当 VPA 更新程序驱逐并重新启动 pod 时，在新 pod 启动之前更改 CPU 和内存设置（使用 webhook） 2、当 Vertical Pod Autoscaler 设置为 updateMode 为“Auto ”时，如果需要更改 pod 的资源请求，则 驱逐 pod。由于 Kubernetes 的设计，修改正在运行的 Pod 的资源请求的唯一方法是重新创建 Pod。
VPA 有以下四种更新策略
· Initial：仅在 Pod 创建时修改资源请求，以后都不再修改。
· Auto：默认策略，在 Pod 创建时修改资源请求，并且在 Pod 更新时也会修改。
· Recreate：类似 Auto，在 Pod 的创建和更新时都会修改资源请求，不同的是，只要 Pod 中的请求值 与新的推荐值不同，VPA 都会驱逐该 Pod，然后使用新的推荐值重新启一个。因此，一般不使用该策略， 而是使用 Auto，除非你真的需要保证请求值是最新的推荐值。
· Off：不改变 Pod 的资源请求，不过仍然会在 VPA 中设置资源的推荐值。pod 不会有任何变化，vpa 对象的推荐值会一直变化
资源定义
涉及到的自定义资源主要有两个：VerticalPodAutoscaler 、VerticalPodAutoscalerCheckpoint
VerticalPodAutoscaler
VerticalPodAutoscaler：该资源由用户创建，用于设置纵向扩容的目标对象和存储 recommend 组件计算出 的推荐指标。
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscalermetadata:
name: nginx-vpa
namespace: vpaspec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: nginx
updatePolicy:
updateMode: "Auto"
resourcePolicy:
containerPolicies:
- containerName: "nginx"
minAllowed:
cpu: "100m"
memory: "100Mi"
maxAllowed:
cpu: "2000m"
memory: "2600Mi"
VerticalPodAutoscalerCheckpoint
该资源由 recommend 组件创建和维护，用于存储指标相关信息。一个 vpa 对应的多个容器，每个容器创建一个该资源。
VPA 工作流程
1.用户配置 VPA 资源 （VerticalPodAutoScaler )。
- VPA Recommender 从 API Service 读取 VPA 配置。
- VPA Recommender 实时更新资源利用率指标(来自 MetriceServer)，对目标 POD 进行计算，提供 pod 资源推荐。
4.VPA Updater 监听读取 pod 资源建议。
5.VPA Updater 得到新的建议后终止 pod （ Kubernetes 不支持动态更改正在运行的 pod 的资源限制，因此 VPA 无法使用更新现有 pod。 - POD 部署控制器意识到 pod 已终止，并将重新创建 pod 以匹配其副本配置。
- 当 Pod 处于重新创建过程中时，VPA Admission controller 获取 Pod 资源推荐。
- VPA Admission controoler 将建议覆盖到 pod。 （如上示例，VPA 准入控制器向 pod 设置“250m”的 CPU 的资源限制，替换 POD 定义中的设置。
VPA 实践
部署 VPA 组件
测试
场景一：使用 VPA 获取 Request 推荐值
1、不建议在生产环境中使用 VPA 自动更新 Request。
2、可以利用 VPA 查看 Request 推荐值，在合适条件下手动触发更新或者作为创建同类任务得推荐值。
updateMode: “OFF”
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: nginx
name: nginx
namespace: vpa
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- image: nginx
name: nginx
resources:
requests:
cpu: 100m
memory: 250Mi
---
apiVersion: v1
kind: Service
metadata:
name: nginx
namespace: vpa
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
selector:
app: nginx
---
apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
name: nginx-vpa
namespace: vpa
spec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: nginx
updatePolicy:
updateMode: "Off"
resourcePolicy:
containerPolicies:
- containerName: "nginx"
minAllowed:
cpu: "250m"
memory: "100Mi"
maxAllowed:
cpu: "2000m"
memory: "2048Mi"
| 字段 | 说明 |
|---|---|
| lowerBound | 推荐的最小值。使用小于该值的 Request 可能会对性能或可用性产生重大影响。 |
| target | 推荐值。由 VPA 计算出最合适的 Request。 |
| uncappedTarget | 最新建议值。仅基于实际资源使用情况，不考虑 .spec.resourcePolicy.containerPolicies 中设置的容器可以被推荐的数值范围。uncappedTarget 可能与推荐上下界限不同。该字段仅用作状态指示，不会影响实际的资源分配。 |
| upperBound | 推荐的最大值。使用高于该值的 Request 可能造成浪费。 |
压测：
~ ab -c 100 -n 10000000 192.168.206.128:31407/
~ kubectl describe vpa nginx-vpa -n vpa
VPA 对 Pod 给出了推荐值：Cpu: 476m，因为我们这里设置了 updateMode: “Off”，所以不会更新 Pod
场景二：停用特定容器 VPA
Pod 中有多个容器，例如一个是真正的业务容器，另一个是辅助容器。为了节省集群资源，可以选择停止为辅助容器推荐 Request.
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscalermetadata:
name: tke-opt-vpaspec:
targetRef:
apiVersion: "apps/v1"
kind: Deployment
name: tke-opt-deployment
updatePolicy:
updateMode: "Off"
resourcePolicy:
containerPolicies:
- containerName: tke-opt-sidecar
mode: "Off"
该 VPA 的 .spec.resourcePolicy.containerPolicies 中，指定了 tke-opt-sidecar 的 mode 为“Off”，VPA 将不会为 tke-opt-sidecar 计算和推荐新的 Request。
场景三：自动更新 Request
updateMode: “Auto”
自动更新正在运行的 Pod 资源是 VPA 的一项实验功能，建议不要在生产环境中使用该功能。VPA 的 updateMode 字段的值为 Auto，表示 VPA 可以在 Pod 的生命周期内更新 CPU 和内存请求。VPA 可以删除 Pod，调整 CPU 和内存请求，然后启动一个新 Pod。
创建 Deployment 时设置了资源的 Request 和 Limits，VPA 此时不仅会推荐 Request 值，还会按照Request 和 Limits 的初始比例自动推荐 Limits 值。例如，YAML 中 CPU 的 Request 和 Limits 的初始比例为 100m:200m = 1:2，那么 VPA 推荐的 Limits 数值则是 VPA 对象中推荐的 Request 数值的两倍。
故障处理
- 执行 vpa-up.sh 脚本时报错
ERROR: Failed to create CA certificate for self-signing. If the error is
"unknown option -addext", update your openssl version or deploy VPA from
the vpa-release-0.8 branch.
检查集群 CVM 的 openssl 版本是否大于 1.1.1
使用考虑
影响：
1、无法与 HPA 共同使用
2、针对云平台，影响计费逻辑，pod 销毁在重启，无法保证 pod 重启在原有节点上，对于依赖宿主机某些资源得场景有局限性。在最新的 v1.27 版本新增 alpha 特性，提供 in place update ，避免了重启 POD
可行性：
可结合 OFF 模式为用户提供预计算资源功能，但仅限于内存、CPU 得资源限制且任务需要先创建运行，可演变成同类型任务得资源推荐功能或者预测资源，缺点是支持的资源类型受限。
