Kubernetes 上的生产就绪 Python 应用程序

Question

在过去的 2 年里，我一直在将应用程序部署到 Kubernetes。在我的组织中，我们所有的应用程序（尤其是无状态的）都在 Kubernetes 中运行。我仍然有一个基本问题，只是因为最近我们发现了一些关于我们的几个 Python 应用程序的问题。

最初，当我们部署 Python 应用程序（用 Flask 和 Django 编写）时，我们使用python app.py. 众所周知，由于GIL的存在，python确实不支持系统线程，一次只能服务一个请求，但是如果一个请求占用了CPU，就无法处理更多的请求。这有时会导致健康 API 无法正常工作。我们观察到，此时如果有单个请求不是 IO 并且在做一些操作，我们将占用 CPU，无法并行处理另一个请求。由于它只执行较少的操作，我们观察到 CPU 利用率也没有增加。这会影响HorizontalPodAutoscaler工作方式，无法扩展 Pod。

因此，我们开始uWSGI在我们的 pod 中使用。所以基本上uWSGI可以在引擎盖下运行多个 pod 并并行处理多个请求，并根据需要自动旋转新进程。但是这里出现了另一个问题，我们已经看到，uwsgi在自动扩展过程以纠正服务请求及其引起的HTTP 503错误方面缺乏速度，因此我们无法以 100% 的可用性为我们的少数 API 提供服务。

同时，我们所有的其他应用程序，写的nodejs，java并且golang，被给予100％的可用性。

我正在研究在 Kubernetes 中以 100%(99.99) 可用性运行 python 应用程序的最佳方式是什么，如下

1. 拥有应用程序提供的健康 API 和活性 API
2. 在 Kubernetes 中运行的应用程序
3. 如果可能没有 uwsgi（每个 pod 单个进程是基本的 docker 概念）
4. 如果使用uwsgi，是否有任何特定的配置我们可以申请k8s env

Answer 1

我们使用带有 30 个线程的 Twisted WSGI 服务器，它对于我们的 Django 应用程序来说非常可靠。正如您提到的，保持每个 Pod 模型一个进程，这更符合 Kubernetes 的期望。是的，GIL 意味着这 30 个线程中只有一个可以同时运行 Python 代码，但与大多数 Web 应用程序一样，这些线程中的大多数在 I/O 上被阻塞（通常等待数据库的响应）。时间。然后在此基础上运行多个副本，既可以实现冗余，也可以在您需要的任何级别上提供真正的并发性（我们通常使用 4-8 个副本，具体取决于站点流量，一些大型副本可达 16 个）。