Azure、容器和水平扩展答案

【问题标题】：Azure, Containers and horizontal scalingAzure、容器和水平扩展
【发布时间】：2024-04-27 03:35:01
【问题描述】：

我是容器和 Kubernetes 的新手。我在 Azure 中进行大部分测试。

我创建了一个容器并根据负载水平缩放容器。托管在我构建的容器中的端点将不得不处理突发的请求。我希望容器大部分时间都处于空闲状态，但在我的测试中，它有时必须扩展到多个实例以处理请求的突发。

为了降低运行服务的成本，我想知道是否可以将容器的实例数量缩减为 0，同时保持在请求即将到来时“唤醒”容器的能力进来？我怎么能做到这一点？

【问题讨论】：

您已经为运行的节点付费了，为什么要缩减到 0 个 pod？您是否考虑过突发到 Azure 容器实例？我不确定这是否会帮助您缩减到 0 个实例。 docs.microsoft.com/en-us/azure/aks/concepts-scale
我同意 CSharpRocks。由于您为节点付费，因此运行 1 个副本应该没有任何区别。当您需要更多 POD（副本）或利用 AKS 的 ACI（虚拟节点）功能时，您可以启用 Cluster AutoScaler 来突增您的节点数

标签： azure containers azure-aks azure-container-service

【解决方案1】：

已经有许多与此功能相关的提案，但没有一个被整合到 kubernetes 中。

空闲/非空闲提案：

这是一个难题，因为在服务启动时，传入的请求需要排队。

如果您有兴趣实现此功能，看起来已经为您完成了一些工作，但它不一定是您用例的端到端解决方案：https://github.com/openshift/service-idler

这是另一个解决类似功能的项目：https://github.com/deislabs/osiris

【讨论】：

【解决方案2】：

AKS 在内部使用水平 pod 自动扩缩器 (HPA) 来监控资源需求并自动扩展副本数量。另外，根据 Pod 的不同需求，kubernetes 的集群 autoscaler 会根据计算资源需求调整节点的数量。

将 ACI 与 AKS 结合起来形成了一个强大的微服务部署模型，其中 AKS 可用于微服务的典型部署，而 ACI 可用于处理突发工作负载，从而减少扩展管理方面的挑战并确保每秒使用成本模型的有效利用.

此外，如果要求是对现有 azure 应用程序的一些扩展以及基于事件触发器的用例，那么 azure 函数可能是更好的选择。此处，特定代码（函数）仅应根据要求为特定事件或触发器调用，并且函数实例按需创建、销毁（按需计算 - 函数即服务（FaaS））。 Azure 函数避免了额外资源 (VM) 的分配，并且仅在函数处理工作时才考虑成本。解决方案可以结合这两种功能，以便触发 Azure 功能以进行最少的处理/决策，进而可以调用 Azure 容器实例进行特定的突发处理/完整处理，这可能会降低成本。

【讨论】：