我们如何在 Kubernetes 上部署一个烧瓶应用程序，它也有一个 probePath 来检查应用程序的活力？
我遇到的大多数教程/示例都没有处理它，只是在 docker 映像中使用 application.run() 启动应用程序。
我觉得这种方法的问题是，如果某个请求在 Pod 上加载的时间过长，并且在这段时间内，Kubernetes 在 Pod 上调用 probePath URL，它会超时。因此，Kubernetes 会在假设它没有响应的情况下杀死 pod。
我错过了什么吗？
【问题讨论】：
标签： python docker flask kubernetes
经过一番研究，我找到了解决方案。
UWSGI 能够在这种情况下以更便宜的模式提供帮助。
要启用更便宜的模式，请在 uWSGI 配置文件中添加更便宜的 = N 选项，其中 N 是 uWSGI 可以运行的最小工作线程数。更便宜的值必须低于配置的工作人员的最大数量（工作人员或进程选项）。
设置要使用的更便宜的算法，如果不设置将使用默认算法
更便宜的算法 = 备用
始终保留的最少工人数
更便宜 = 2
启动时产生的工人数量
更便宜的初始 = 5
可以生成的最大工人数
工人 = 10
一次应该产生多少工人
更便宜的一步 = 1
此配置将告诉 uWSGI 在负载下运行最多 10 个工作程序。如果应用程序处于空闲状态，uWSGI 将停止工作人员，但它始终会让至少 2 个工作人员运行。使用更便宜的初始，您可以控制在启动时应该产生多少工人。如果您的平均负载需要超过最低数量的工人，您可以立即生成它们，然后如果负载足够低，则“廉价”（杀死）。当更便宜的算法决定它需要更多的工人时，它将产生更便宜的一步。如果您的最大工作线程数很高，这将很有用——如果负载突然激增，否则将花费大量时间来逐个生成足够的工作线程。
注意：工人在被降价之前由 uWSGI 通知。 Worker 应该完成直到超时（这由 worker-reload-mercy 配置参数配置）。否则，uWSGI 会杀死工作人员。在服务请求的过程中杀死工作人员可能会导致错误或对客户端的部分响应。
更多信息请参考此链接：https://uwsgi-docs.readthedocs.io/en/latest/Cheaper.html
【讨论】：