VPA(Vertical Pod AutoScaler)简介

最近两天简单的研究了下vpa，整理下一些资料

VPA简介
全称Vertical Pod AutoScaler 垂直 Pod 自动扩缩容，它根据容器资源使用率自动设置 CPU 和 内存 的requests，从而允许在节点上进行适当的调度，以便为每个 Pod 提供适当的资源。
并且会保持limit和request的比例。在pod请求过多资源的情况下降低其request，在pod请求过少资源的情况下提高其request
自动伸缩是通过一个叫VerticalPodAutoscaler的CRD（自定义资源对象）进行配置的，允许指定哪些pod可以被水平伸缩

VPA的几种模式
Auto：当创建或者更新存在的pod的时候，VPA会通过推荐的更新机制修改pod的request
Recreate：类似Auto，但是当vpa发现pod定义的request和计算出来的推荐值有明显差距时会驱逐这些pod。这个模式很少使用。只有当你确定只要资源请求数遍历就要重启pod时才使用，否则推荐使用Auto模式
Initial：vpa只会在pod创建时修改资源的request，并且后续不会再修改。
Off：Vpa不会自动修改pod的request。只计算其推荐值，可以通过vpa对象查看推荐值。

VPA的三大组件
Recommander：监控当前和历史资源使用记录，并且基于这些数据提供容器的cpu和内存request推荐值
Updater：检查管理的pod是否有正确的资源设置，如果没有，将pod杀掉，让其使用最新的推荐值重启
Admission Plugin：给新pod设置正确的requests资源。（不管是新建还是重启的）

限制值控制
设置限制时，VPA 将符合资源策略。它将保持为所有容器指定的请求比率限制。
VPA 将尝试将推荐值限制在最小和最大限制范围之间。如果限制上线和vpa的资源策略冲突，vpa会忽略限制上线，使用vpa的资源策略

例子
保证request和limit的比例
假设容器的template定义了request为500milli CPU和1GB的内存，limit为2GB内存。
vpa的推荐值是1000milli CPU和2GB内存，那么vpa会将内存limit设置为4GB
原先的request/limit比例=1GB/2GB=推荐值request/limit比例=2GB/4GB

limit的设置上限
假设容器的template定义了request为500milli CPU和1GB内存，limit为2GB内存。
并且每个容器的limit设置上限为3GB内存。
vpa的推荐值是1000milli CPU和2GB内存，那么vpa会将内存limit设置为3GB，将内存request设置为1.5GB（保证request和limit的比例）

资源策略覆盖limit范围
假设容器的template定义了request为500milli CPU和1GB内存，limit为2GB内存。
并且每个容器的limit设置上限为3GB内存。
vpa的容器资源策略要求vpa将容器的request设置为最小750milli CPU和2GB内存。
vpa的推荐值是1000milli CPU和2GB内存。那么vpa会将内存request设置为2GB，将内存limit设置为4GB（保证request和limit比例）

总的来说 资源策略 > 全局limit上限 > 推荐值

OOMKill后自定义内存增长
如果检查道OOMKill时间，vpa会增加内存使用量推荐值
recommendation = memory-usage-in-oomkill-event + max(oom-min-bump-up-bytes, memory-usage-in-oomkill-event * oom-bump-up-rate)
推荐值 = 发生OOMKill的内存使用值 + oom最小的增长字节、内存使用值与增长率的乘积两者的最大值
通过oom-min-bump-up-byte修改oom最小增长字节，默认是100MiB
通过oom-bump-up-radio修改增长率，默认是1.2，即每次发送OOM，内存增加20%。

已知限制
1、当vpa更新了pod的请求资源，所有运行的相关pod会被重建，可能被调度到其他节点。
2、vpa不保证pod更新推荐值时会重启成功
3、vpa不会更新没有控制器的pod，即不会修改damonset这些类型的pod
4、vpa不应该和hpa一起使用。但是可以使用vpa和一些定制的hpa
5、VPA 准入控制器是一个准入Webhook。如果将其他准入 Webhook 添加到集群，则分析它们如何交互以及它们是否可能相互冲突非常重要。准入控制器的顺序由 API 服务器上的标志定义。
6、vpa会对大部分的内存溢出时间做出反应，但不是全部
7、vpa表现没有经历过大规模的集群测试
8、vpa的推荐值可能超出集群可用资源，导致pod一直处于pending状态
9、同一个pod匹配多个vpa资源可能有未知的行为

vpa的大致流程
当vpa部署到集群后，vpa的recommender会通过prometheus等其他收集数据的组件获取pod的历史以及当前的资源使用情况。然后计算出推荐值。vpa的updater会检查pod设置的request和limit是否符合推荐值。不符合，根据模式，admission controller决定是否修改其request和limit。然后对应的控制器会将其重启。

vpa如何计算cpu和内存的推荐值
总的计算原则，具体计算很复杂，不详细介绍了
对于 CPU，目标是将容器使用率超过请求的高百分比（例如 95%）时的时间部分保持在某个阈值（例如 1% 的时间）以下。
对于内存，目标是将特定时间窗口内容器使用率超过请求的概率保持在某个阈值以下（例如，24 小时内低于 1%）。。

参考资料
https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/README.md
https://zhuanlan.zhihu.com/p/539314274