Flask是一个Web框架，使用它编写的任何应用程序都需要WSGI服务器来托管。尽管你可以使用Flask内置的开发人员服务器，但你不应该这样做，因为它不适用于生产系统。因此，你需要使用WSGI服务器，例如uWSGI，gunicorn或mod_wsgi（mod_wsgi-express）。由于Web应用程序由WSGI服务器托管，因此它只能位于同一容器中，但是Flask没有单独的进程，因此它在Web服务器进程中运行。

然后，是否需要单独的Web服务器（例如nginx）取决于。在使用mod_wsgi的情况下，你不使用Apache Web服务器，因此可以从中直接受益。使用mod_wsgi-express时，它也已经设置为以最佳基本配置运行，并且这样做避免了像使用uWSGI或gunicorn时人们经常使用nginx那样需要单独的前端Web服务器。

对于平台化已经提供了用于负载平衡的路由层的容器化系统（例如Kubernetes中的入口），在混合中使用nginx可能会增加你不需要的额外复杂性并降低性能。这是因为你要么必须在同一容器中运行nginx，要么必须在同一容器中创建一个单独的容器并使用共享emptyDir卷类型，以允许它们仍然通过UNIX套接字进行通信。如果你不使用UNIX套接字，使用INET套接字或在完全不同的Pod中运行nginx，那么这是毫无意义的，因为你将为流量引入额外的跃点，这将比紧密地花费更昂贵。使用UNIX套接字绑定。当与nginx耦合并通过INET接受请求时，uWSGI服务器的性能不佳，并且将nginx放置在单独的pod中（可能位于不同的主机上）会使情况变得更糟。

在前面使用nginx的部分原因是，它可以保护你免受由于请求缓冲以及其他潜在问题而导致的缓慢客户端的攻击。不过，在使用Ingress时，你已经拥有了haproxy或nginx前端负载均衡器，可以在某种程度上保护你免受此侵害。因此，实际上是否要在混合中引入其他nginx代理取决于你在做什么。将gunicorn或uWSGI直接放在负载均衡器后面可能会更简单。

建议如下。

• 另请参阅mod_wsgi-express。它是专门为容器化系统而开发的，旨在使其变得更容易，并且比uWSGI和gunicorn更好。

• 使用实际的流量配置文件，而不是仅仅使它过载的基准测试，在你的实际应用程序中测试不同的WSGI服务器和配置。这一点很重要，因为基于Kubernetes的系统的动态特性以及其路由的实现方式意味着所有这些行为都可能与你惯用的传统系统大不相同。