如何停止为云服务多付钱，开始使用 Kubernetes Autoscaler
想象一下：你发起了一场广告活动，流量激增，Kubernetes 中的 Pod 开始在负载下"窒息"。或者反过来：夜幕降临，用户们都在睡觉，但云中仍有数十个昂贵的实例在运转，消耗着公司的预算。听起来很熟悉？
通常在这样的时刻，人们会想起自动扩缩容。在 Kubernetes 生态系统中，这由 kubernetes/autoscaler 仓库处理。它不仅仅是一个单一的实用工具，而是一整套工具，帮助集群随着负载"呼吸"。我决定弄清楚里面有什么，以及为什么它是任何生产环境的必备工具。
里面有什么
该仓库包含三个主要组件。每个组件解决各自特定的任务，但人们经常将它们混淆。
Cluster Autoscaler：当"硬件"不足时
这可能是该套件中最受欢迎的工具。它的任务很简单：如果集群中出现因资源不足而无法启动的 Pod（Pending 状态），Cluster Autoscaler 会联系云服务商，请求添加新节点。
它也可以反向工作。如果某个节点长时间处于半空状态，且其 Pod 可以安全地迁移到其他节点，自动扩缩容器将移除多余的硬件。这是直接的成本节省，尤其是在 AWS、GCP 或 Azure 上。
Vertical Pod Autoscaler (VPA)：资源调优的魔法
如果说 Cluster Autoscaler 改变节点数量，那么 VPA 改变的是 Pod 本身的"大小"。通常开发者是凭感觉设置 requests 和 limits。结果要么是应用程序因 OutOfMemory 崩溃，要么我们预留了 2 GB 内存而实际只需要 200 MB。
VPA 监控实际资源消耗并自动调整限制。该项目目前处于 beta 状态，但它已经做了一件非常酷的事情——推荐模式。你只需观察它建议设置什么资源，而不必信任它自动重启 Pod。
Addon Resizer：系统服务的微观管理
这是垂直自动扩缩容的简化版本。它用于资源消耗随集群规模线性增长的服务。例如，如果你有 100 个节点而不是 10 个，metrics server 需要更多内存。Addon Resizer 监控节点数量并相应地扩缩这类辅助组件。
实际工作原理
假设你正在使用 Go。要在本地开始使用项目代码，你需要遵循 Kubernetes 惯用的路径结构。代码应该放在 k8s.io 中，而不是 github.com 中。
有趣的是：Cluster Autoscaler 支持数十种提供商。不仅有 AWS 这样的巨头，还有针对裸机或本地集群的特定解决方案。如果你正在构建自己的云服务，你需要实现 CloudProvider 接口，你的集群也将学会自动扩缩容。
为什么这对开发者很重要
许多人认为自动扩缩容是 DevOps 工程师的工作。实际上，了解 vertical-pod-autoscaler 的工作原理会让后端开发者的生活轻松很多。
- 你可以告别配置资源时的猜测。
- 应用程序对突发流量高峰的抵抗力变得更强。
- 你可以看到代码的真实内存和 CPU 消耗情况。
顺便说一句，该仓库包含用于快速安装的官方 Helm charts。这比手动部署 manifest 方便得多。
现在应该采用吗？
如果你在云环境中工作，而且基础设施账单在不断增长，那么 Cluster Autoscaler 是基础。它在运行后的第一个月内就能收回设置时间成本。
Vertical Pod Autoscaler 的情况更复杂。由于它会重启 Pod 来更改资源（直到 K8s 获得适当的原地资源更新），需要谨慎使用。我建议从 Recommender 模式开始。你会得到一份资源优化建议列表，但 VPA 不会触碰任何东西。
这个项目充满活力，得到了庞大社区的支持（近 9,000 颗星和数千个分支）。如果你有问题，Kubernetes Slack 频道 #sig-autoscaling 的人们很活跃。
所以如果你的集群仍然是静态的——看看这个仓库。是时候让云为你服务，而不是与你为敌了。
相关项目