据我所知，VPA documentation 垂直 Pod 自动缩放器根据预测的请求/限制的下限/上限和目标停止/重新启动 Pod。 在“自动”模式下，它表示 pod 将停止并重新启动，但是，我不明白在它仍在工作时进行预测和重新启动 pod 的意义，因为尽管我们知道它可能会耗尽资源最终它仍然可以工作，一旦它真的耗尽内存/cpu，我们可以等待重新调整它。只是等待 pod 耗尽内存/cpu，然后用新的预测请求重新启动它不是更有效吗？
从死容器中恢复是否比自己停止和重新启动 pod 成本更高？如果是，以什么方式？
答案 0 :(得分：1)
就等pod出来不是更高效吗 memory/cpu 然后用新的预测请求重新启动它？
在我看来，这不是最好的解决方案。如果 pod 尝试使用的 CPU 超过可用限制，而不是容器的 CPU 使用受到限制，如果容器尝试使用超过限制的内存，则由于限制过度使用，OOM 会杀死容器，但对 npod 的限制通常可能高于节点容量总和，因此这可能导致节点内存耗尽，并可能导致其他工作负载/pod 死亡。
回答您的问题 - VPA 旨在简化这些场景：
<块引用>Vertical Pod Autoscaler (VPA) 将用户从 为容器设置最新的资源限制和请求 他们的豆荚。配置后，它将自动设置请求 基于使用情况，从而允许对节点进行适当的调度，以便 每个 Pod 都有适当的资源量。它也会 保持在中指定的限制和请求之间的比率 初始容器配置。
此外，VPA 不仅要负责向上扩展，还要负责向下扩展： 它既可以缩小资源请求过多的 Pod，也可以根据一段时间内的使用情况扩大资源请求不足的 Pod。
<块引用>从死容器中恢复比停止和恢复成本更高 自己重新启动吊舱？如果是，以什么方式？
谈论从死容器中恢复的成本 - 根据官方doc，主要可能的成本可能是最终可能在 OOM 终止过程中丢失的请求。
根据 official documentation VPA 在这些模式下运行：
<块引用>“Auto”：VPA 在创建 pod 时分配资源请求以及 使用首选更新机制在现有 pod 上更新它们 目前这相当于“Recrete”。
“Recreate”：VPA 在创建 pod 时分配资源请求以及 通过在请求时驱逐它们来更新现有 pod 上的它们 资源与新建议有很大不同（尊重 Pod 中断预算（如果已定义））。
“Initial”：VPA 只在创建 Pod 时分配资源请求，并且 以后永远不会改变它们。
“关闭”：VPA 不会自动更改资源需求 豆荚。
注意： VPA 限制
还请查看一些VPA Known limitations：
<块引用>