K8s VPA (Vertical Pod Autoscaler) 资源自动调整实践

好嘞！各位看官，今天咱就来聊聊 Kubernetes 里那个既能帮你省钱，又能让你的应用跑得更欢实的家伙——Vertical Pod Autoscaler，简称 VPA。这玩意儿，说白了，就是个智能的资源调整小助手，专门帮你打理 Pod 的 CPU 和内存，让它们不多占，也不少用，恰到好处，就像量身定制的西装一样。🎩

别怕，今天咱们不搞那些枯燥的理论，就用大白话，加上一点幽默，把这 VPA 掰开了、揉碎了，让你彻底明白它是个啥，怎么用，以及那些坑坑洼洼的地方。准备好了吗？咱们这就开车！🚀

第一章：VPA 是个啥？为啥需要它？

想象一下，你开了一家小餐馆，生意忽冷忽热。有时候座无虚席，恨不得多几个服务员；有时候门可罗雀，空闲的服务员都在打盹儿。如果服务员的数量是固定的，那高峰期肯定忙不过来，顾客体验差；低谷期又浪费人力成本。

Kubernetes 里的 Pod 也一样。你给它分配的 CPU 和内存，就好比是餐馆里的服务员。如果分配少了，Pod 就得“饿肚子”，运行缓慢，甚至崩溃；如果分配多了，资源就被白白浪费，等于给闲着的服务员发工资。💸

这时候，VPA 就闪亮登场了！它就像一个聪明的经理，能根据 Pod 的实际负载情况，动态地调整 CPU 和内存的分配，让它们始终保持最佳状态。

为啥我们需要 VPA 呢？

省钱！省钱！还是省钱！ 💰 你不再需要为了应对偶尔的峰值，而长期分配过多的资源。VPA 能让你更有效地利用集群资源，降低云平台的账单。
性能优化！ 🚀 VPA 能确保 Pod 拥有足够的资源来应对负载，避免因资源不足而导致的性能下降。
自动化运维！ 🤖 VPA 能自动监控和调整 Pod 的资源需求，减轻运维人员的工作负担，让他们有更多时间去喝咖啡，写代码，或者…摸鱼？🐟

VPA 的工作原理：

VPA 主要由三个组件组成：

Recommender: 它就像一个数据分析师，持续监控 Pod 的资源使用情况，然后根据历史数据和算法，给出 CPU 和内存的建议值。
Updater: 它就像一个执行者，根据 Recommender 的建议值，更新 Pod 的资源配置。
Admission Controller: 它就像一个门卫，拦截新的 Pod 创建请求，并根据 Recommender 的建议值，调整 Pod 的初始资源配置。

简单来说，VPA 的工作流程就是：监控 -> 分析 -> 建议 -> 执行。

第二章：VPA 的三种模式：各有千秋

VPA 有三种模式，分别是：

Off 模式： 顾名思义，就是关闭 VPA 的功能。VPA 只会收集数据，但不会进行任何资源调整。这种模式通常用于观察和分析 Pod 的资源使用情况，为后续的配置提供依据。
Initial 模式： VPA 只会在 Pod 创建时，根据 Recommender 的建议值，设置 Pod 的初始资源配置。之后，VPA 就不会再进行任何调整。
Auto 模式： 这才是 VPA 的完全体！VPA 会持续监控 Pod 的资源使用情况，并根据 Recommender 的建议值，自动调整 Pod 的资源配置。

三种模式的对比：

模式	功能	适用场景	优点	缺点
Off	收集数据，不进行资源调整	观察和分析 Pod 的资源使用情况，为后续的配置提供依据。	不会影响现有 Pod 的运行，可以安全地收集数据。	不会自动调整资源，无法实现自动化运维。
Initial	只在 Pod 创建时设置初始资源配置	适用于对资源需求相对稳定的 Pod，例如，一些后台任务或者不经常变化的微服务。	可以避免 Pod 一开始就分配过多的资源，节省资源。	无法应对 Pod 负载的变化，如果负载发生变化，可能需要手动调整资源。
Auto	持续监控并自动调整资源配置	适用于对资源需求变化较大的 Pod，例如，一些处理大量请求的 Web 应用或者需要进行复杂计算的任务。	可以自动应对 Pod 负载的变化，始终保持最佳性能，并最大限度地利用资源。	会导致 Pod 重启，可能会对应用造成短暂的影响。需要谨慎配置，避免频繁重启。

选择哪种模式，取决于你的应用场景。 如果你的应用资源需求稳定，可以选择 Initial 模式；如果你的应用资源需求变化较大，可以选择 Auto 模式；如果你只是想观察一下，那就选择 Off 模式。

第三章：手把手教你配置 VPA

说了这么多，咱们来点实际的。下面，我就手把手教你配置 VPA。

前提条件：

你已经安装了 Kubernetes 集群。
你已经安装了 VPA。（安装方法可以参考 VPA 的官方文档，这里就不赘述了。）

步骤：

创建 VPA 对象。

创建一个 YAML 文件，例如 vpa.yaml，内容如下：
```
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: my-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  updatePolicy:
    updateMode: "Auto" # 或者 "Initial" 或 "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: '*'
      controlledValues: RequestsAndLimits # 可以是 RequestsAndLimits, RequestsOnly, LimitsOnly
      minAllowed:
        cpu: 100m
        memory: 100Mi
      maxAllowed:
        cpu: 1
        memory: 1Gi
```
解释一下：
- apiVersion 和 kind 定义了 VPA 对象的 API 版本和类型。
- metadata.name 定义了 VPA 对象的名称。
- spec.targetRef 定义了 VPA 对象所管理的 Deployment。你需要将 my-deployment 替换为你实际的 Deployment 名称。
- spec.updatePolicy.updateMode 定义了 VPA 的模式。这里设置为 Auto，表示 VPA 会自动调整 Pod 的资源配置。
- spec.resourcePolicy.containerPolicies 定义了 VPA 对容器的资源限制。
  - containerName: '*' 表示对所有容器生效。
  - controlledValues: RequestsAndLimits 表示 VPA 可以同时调整 Requests 和 Limits。
  - minAllowed 定义了允许的最小 CPU 和内存值。
  - maxAllowed 定义了允许的最大 CPU 和内存值。
应用 VPA 对象。

使用 kubectl apply 命令应用 VPA 对象：
```
kubectl apply -f vpa.yaml
```

查看 VPA 对象的状态。

使用 kubectl get vpa my-vpa -o yaml 命令查看 VPA 对象的状态。你可以看到 Recommender 给出的 CPU 和内存建议值。

status:
  conditions:
  - lastTransitionTime: "2023-10-27T10:00:00Z"
    message: VPA is not recommending a change of resources.
    reason: NoRecommendation
    status: "True"
    type: RecommendationProvided
  recommendation:
    containerRecommendations:
    - containerName: my-container
      lowerBound:
        cpu: 100m
        memory: 100Mi
      target:
        cpu: 200m
        memory: 200Mi
      uncappedTarget:
        cpu: 200m
        memory: 200Mi
      upperBound:
        cpu: 500m
        memory: 500Mi

解释一下：

status.conditions 显示了 VPA 的状态。
status.recommendation.containerRecommendations 显示了 Recommender 给出的 CPU 和内存建议值。
- lowerBound 表示建议的最小 CPU 和内存值。
- target 表示建议的目标 CPU 和内存值。
- upperBound 表示建议的最大 CPU 和内存值。

验证 VPA 的效果。

你可以通过观察 Pod 的资源使用情况，来验证 VPA 的效果。如果 VPA 工作正常，你会发现 Pod 的 CPU 和内存使用量会逐渐接近 Recommender 给出的建议值。

第四章：VPA 的坑与注意事项

VPA 虽然好用，但也有一些坑需要注意。

Pod 重启！ 💥 这是 VPA 最让人头疼的问题。在 Auto 模式下，当 VPA 需要调整 Pod 的资源配置时，会导致 Pod 重启。这可能会对应用造成短暂的影响。

解决方法：
- 尽量缩短 Pod 的启动时间。
- 使用滚动更新策略，减少 Pod 重启对应用的影响。
- 谨慎配置 spec.resourcePolicy.containerPolicies 中的 minAllowed 和 maxAllowed，避免 VPA 频繁调整资源。
- 考虑使用 PodDisruptionBudget (PDB)，限制同时可以被中断的 Pod 数量。
资源抖动！ 📉 VPA 可能会因为负载的波动，而频繁地调整 Pod 的资源配置，导致资源抖动。

解决方法：
- 调整 Recommender 的算法，使其更加平滑。
- 增加 spec.resourcePolicy.containerPolicies 中的 minAllowed 和 maxAllowed 的范围，减少 VPA 的调整频率。
与 Horizontal Pod Autoscaler (HPA) 的冲突！ ⚔️ VPA 和 HPA 都是用于自动调整 Pod 资源的，但它们的工作方式不同。VPA 调整的是 Pod 的 CPU 和内存，HPA 调整的是 Pod 的数量。如果同时使用 VPA 和 HPA，可能会导致冲突。

解决方法：
- 尽量避免同时使用 VPA 和 HPA。
- 如果必须同时使用，需要仔细配置 VPA 和 HPA 的参数，避免它们相互干扰。
- 可以使用 ControlledValues: RequestsOnly，让 VPA 只调整 Requests，让 HPA 基于 Requests 进行扩缩容。
初始资源配置不合理！ 🤦‍♂️ 如果 Pod 的初始资源配置不合理，VPA 可能需要进行多次调整才能达到最佳状态。

解决方法：
- 在创建 Pod 之前，先使用 Off 模式的 VPA 收集数据，了解 Pod 的资源使用情况，然后根据数据设置合理的初始资源配置。
监控不足！ 🙈 VPA 需要依赖监控数据才能做出正确的决策。如果监控数据不准确或者不完整，VPA 可能会做出错误的判断。

解决方法：
- 确保你的监控系统能够准确地收集 Pod 的资源使用情况。
- 定期检查 VPA 的状态，确保它工作正常。

第五章：VPA 的最佳实践

最后，我再分享一些 VPA 的最佳实践。

从小范围开始。 不要一开始就将 VPA 应用于所有 Pod。先选择一些不重要的 Pod 进行测试，观察 VPA 的效果，然后再逐步推广到其他 Pod。
仔细配置 spec.resourcePolicy。 spec.resourcePolicy 是 VPA 的核心配置。你需要根据你的应用场景，仔细配置 minAllowed、maxAllowed 和 controlledValues，以达到最佳效果。
定期监控 VPA 的状态。 定期检查 VPA 的状态，确保它工作正常。如果发现异常，及时进行处理。
结合其他工具。 VPA 可以与其他工具结合使用，例如，Prometheus 和 Grafana，可以更好地监控和分析 Pod 的资源使用情况。
不断学习和实践。 VPA 是一个复杂的工具，需要不断学习和实践才能掌握它的精髓。

总结

好了，今天的 VPA 讲座就到这里了。希望通过今天的讲解，你已经对 VPA 有了更深入的了解。VPA 是一个强大的工具，可以帮助你更好地管理 Kubernetes 集群的资源，提高资源利用率，降低成本。但是，VPA 也有一些坑需要注意。在使用 VPA 时，需要谨慎配置，并定期监控其状态。

记住，没有银弹！VPA 并不是万能的，你需要根据你的实际情况，选择合适的工具和策略，才能达到最佳效果。

最后，祝你在 Kubernetes 的世界里玩得开心！🎉

第一章：VPA 是个啥？为啥需要它？

第二章：VPA 的三种模式：各有千秋

第三章：手把手教你配置 VPA

第四章：VPA 的坑与注意事项

第五章：VPA 的最佳实践

总结

发表回复 取消回复

发表回复取消回复