Kubernetes 和 Gunicorn 上的 Flask 应用程序扩展

Cad*_*nge 12 scaling flask eventlet gunicorn kubernetes

我们有一个 Flask 应用程序,它使用 eventlet 工作线程通过 gunicorn 提供服务。我们正在 kubernetes pod 中部署应用程序,其想法是根据工作负载扩展 pod 的数量。

gunicorn 中工人数量的推荐设置是2 - 4 x $NUM_CPUS. 请参阅文档。我以前在专用的物理硬件上部署了服务,这样的计算是有意义的。在 4 核机器上,有 16 名工人听起来不错,我们最终将其增加到 32 名工人。

这个计算是否仍然适用于使用异步工作者的 kubernetes pod,特别是:

  1. 单个节点上可能有多个 Pod。
  2. 相同的服务将在多个 Pod 中运行。

我应该如何设置 gunicorn 工人的数量?

  1. 将其设置为-w 1并让 kubernetes 通过 pod 处理缩放?
  2. 2-4 x $NUM_CPU在 kubernetes 节点上将其设置为。在一个吊舱还是多个吊舱?
  3. 完全是别的什么?

更新

我们决定采用第一个选项,这是我们目前的方法。将 gunicorn 作品的数量设置为 1,并通过增加 Pod 的数量进行水平缩放。否则将会有太多活动部件,而且我们将无法充分利用 Kubernetes 的潜力。

Mar*_*ark -3

我不是开发人员,这似乎不是一个简单的任务,但出于您的考虑,请遵循最佳实践,通过优化 Gunicorn config 来获得更好的性能

此外,在 kubernetes 中,由于CPU 利用率的原因,有不同的机制可以扩展您的部署,例如 HPA (Python 如何使用 Gunicorn 和 Kubernetes 进行扩展?

您还可以使用Pod 和容器的资源请求和限制。

根据Gunicorn 文档

不要根据您期望的客户数量来调整员工数量。Gunicorn 应该只需要 4-12 个工作进程即可每秒处理数百或数千个请求。Gunicorn 依赖操作系统在处理请求时提供所有负载平衡。一般来说,我们建议 (2 x $num_cores) + 1作为开始的工作人员数量。虽然不太科学,但该公式基于这样的假设:对于给定的核心,一个工作线程将从套接字读取或写入,而另一个工作线程正在处理请求。

# 更新

根据您的方法,您可以选择不同的解决方案(部署、守护进程),您可以通过根据将CPU 资源分配给容器和 Pod进行处理来在 kubernetes 中实现上述所有语句

  1. 使用资源(限制、请求)部署使您可以根据硬件限制将应用程序的大小调整为单个节点上的多个 Pod,但根据您的“应用程序负载”,这可能不是足够好的解决方案。

CPU 请求和限制与容器相关,但将 Pod 视为具有 CPU 请求和限制是有用的。Pod 的 CPU 请求是 Pod 中所有 Container 的 CPU 请求之和。同样,Pod 的 CPU 限制是 Pod 中所有容器的 CPU 限制之和。

笔记:

CPU 资源以 CPU 单元来衡量。在 Kubernetes 中,一个 CPU 相当于:fe 1 个 GCP Core。

  1. 正如文章中提到的,第二种方法(将应用程序扩展到多个节点)也是不错的选择。在这种情况下,您可以考虑使用 fe Statefulset 或在 GKE 上使用“ cluster austoscaler ”进行部署,当您尝试创建没有足够容量在集群内运行的新 Pod 时,您可以获得更具可扩展性的解决方案。在这种情况下,集群自动缩放程序会自动添加额外的资源。

另一方面,您可以考虑使用不同的其他解决方案,例如Cerebral,它使您可以创建用户定义的策略,以增加或减少集群内节点池的大小。

GKE 的集群自动扩缩器会根据您要运行的工作负载的需求自动调整集群的大小。启用自动扩展后,如果您创建的新 Pod 没有足够的运行容量,GKE 会自动向集群添加新节点;相反,如果集群中的某个节点未得到充分利用,并且其 Pod 可以在其他节点上运行,GKE 可以删除该节点。

请记住,这个问题非常笼统,对于这个主题没有一个好的答案。您应该根据您的要求、负载、活动、容量、成本考虑所有利弊......

希望这有帮助。