Knative v0.3 自动伸缩 - 爱情故事 ¶
发布时间：2021-10-06 , 修订时间：2024-01-17
Knative v0.3 自动伸缩 - 爱情故事¶
作者：Joseph Burnett，Google 软件工程师
Knative v0.3 自动伸缩 - 爱情故事
Knative v0.3 版本中的伸缩包括新的选项，用于自定义自动伸缩子系统。从开箱即用、自动伸缩至零的默认值，到完全替换自动伸缩系统的能力，以及介于两者之间的所有内容。PodAutoscaler 是 Knative 中新的自定义资源，它提供了一个扩展点和控制点，用于配置您的应用程序。
为了说明这些选项，让我们从一个 Web 应用程序的初始阶段到复杂的自动伸缩过程，逐步了解其演变。我们保证，“Knative 自动伸缩将与您共同成长。”
我只想保持简单
有一天早上，你在床上突然坐起来，意识到人们真正想要的是... 爱。你编写了一个简单的 Web 应用程序，可以在任何给定图像的正确位置添加一个心形水印。由于你是精通现代应用程序开发的开发人员，你将其放入一个容器中，并在 GKE 上使用 `gcloud run deploy --image gcr.io/joe-does-knative/love` 在 Knative 服务上运行它。
这是您的 Knative 服务的外观
你向你的 BFF 展示了它，他们把它发布到了 Hacker News 上。瞧，你出现在了黑客互联网的首页！HN 试图给你一个致命的拥抱，但你的应用程序和集群无缝地扩展以处理每秒 1000 个操作的流量。过了一段时间，兴奋感消退了，你的服务每小时收到 1 或 2 个请求。幸运的是，Knative 在不使用时会自动缩减为零个 Pod，因此你不会花在运行空闲进程上。而且你从最初部署后就再也没有更改过任何内容！这很简单。
请不要离开
几周后，闪电再次击中，你意识到... “我可以靠这个赚钱”。显然，人们喜欢心形水印。也许你可以让人们使用你的服务来为他们整个网站上的图像添加水印！在你的 Ruby 脚本（是的，是 Ruby）前面添加一个简单的内存缓存后，你重新部署，然后开始宣传你的产品作为通用的图像处理服务。一切进展顺利，但你很快就意识到你的流量不可预测 - 出现了很多突发。当服务自动缩减为 0 个 Pod，后来流量恢复时，你需要花几分钟时间重新构建缓存，这使得请求延迟有点高。因此你决定在你的 Knative 服务的修订模板中添加一个注释，始终保持至少 2 个 Pod。
现在，您的 Knative 服务的外观如下
没有自动缩减为零。但这没关系，因为你从这项事业中赚了点钱。
事情正在升温
哇！流量开始上升。你平均每秒处理 500 个操作，并且根据一天中的时间运行 10 到 50 个 Pod。你注意到这项工作主要是 CPU 密集型的，你没有像预期那样高效地利用所有资源。因此，你对默认自动伸缩目标进行了一些调整。
但最终你得出结论，你只需要根据 CPU 进行扩展，以保持机器处于热运行状态。因此，你选择了完全不同的 Knative 自动伸缩类别。类别注释将告诉 Knative 使用不同的 PodAutoscaler 控制器实现，有点像 Kubernetes Ingress。
现在，您的 Knative 服务如下所示
你的 CPU 始终保持在 60% 的利用率，你实际上开始赚的钱比你花的多！因此你辞掉了工作，全职从事心形水印业务。
让我们认真对待
事情越来越复杂。你寻求专业帮助，聘请了马克博士来帮助你运营服务。他实施的第一件事是你的服务的发布模式。不再是先走一步再看一步了！
有了马克博士掌舵，一切顺利！随着时间的推移，新年除夕临近，你开始看到指标呈非线性增长。与马克博士的快速咨询证实了你最糟糕的担心。人们在新年除夕互相发送带心形的图片，而且他们 同时 进行操作，就像他们在协调一次爱的 DDoS 攻击一样。你需要一个计划。
幸运的是，马克博士一直在阅读 Knative Serving 发布说明，并开始尝试编辑现有 Knative 修订的 PodAutoscaler。PodAutoscaler 是 Knative 用于保存其自动伸缩状态和配置的地方。与 Knative 修订不同，它是可变的（故意为之）。你制定了一个计划，在全球范围内每个除夕活动（是的，它会发生 24 次！）的流量积累之前，稍微提高容量。
在整个晚上，新年从一个时区到另一个时区。你发现第一个除夕活动出现了几分钟的错误，因为 60% 的 CPU 目标太高。但是在你将下一个活动的 CPU 目标调整到 40% 之后，整个晚上都运行得很顺利。万岁！🎉
你是如此特别
已经过去了一年，而且情况很疯狂！你与几个主要的图像托管网站进行了深度集成，它们现在带来了约 80% 的流量和收入。现在你有了一些空闲时间，你开始分析你的自动伸缩统计数据。你意识到你的上游推荐人观察到的流量几乎 完美地 预测了你的流量模式。并且他们可以通过你的 API 集成提供这些指标！
但你已经实现了你的 CI/CD 管道来与 Knative 配合使用。你所有的操作经验都在运行 Knative 工作负载。只为了实现自己的自动伸缩算法而放弃所有这些将是一件很可惜的事情。但随后你记起了马克博士很久以前开始研究 Knative v0.3 时说过的话。使用 PodAutoscaler 自定义资源，你可以实现 自己的协调器和自动伸缩系统，而无需更改 Knative Serving 系统的任何其他内容。好吧，就是这样！
快速复制一个 Kubernetes 示例控制器，你就实现了协调器，它对自己的 Knative PodAutoscaler 类进行操作。它查询上游指标以进行预测性扩展。
您需要在 Knative 服务中进行以下更改，以将其连接起来
哇，控制器和自动缩放器很难写。但这是您业务的核心问题，而且您已经成功运行了。而且您不必接触与这个特定自动缩放问题无关的所有其他内容。当您思考过去几年 Knative 如何与您的业务一起发展时，您只能说“我有选择，但 Knative…您是最佳选择！”
发生了什么事？
要详细了解 PodAutoscaler 的工作原理以及 Knative 自动缩放的选项，请观看 Kubecon 演讲 Knative：从 0 到无穷大扩展 并查看 Github 上的代码。或者，您可以尝试 Knative Serving 的 自动缩放示例。
这是 PodAutoscaler 相对于其他 Knative 实体的位置
