在 Kubernetes 集群中处理并发请求的最佳选择是什么？具体来说，我在 azure 上使用 AKS。
我当前的设置有多个使用 FLASK+GUNICORN 实现的 API pod，以及一个 nginx 反向代理（也使用多个 pod 实例化）。 我原以为 nginx 的负载均衡器服务已经负责将请求重定向到流量较低的 pod，但我看到的是，实际上经常发生两个后续请求落在同一个 nginx pod 上的情况，随之而来的是等待时间。
我应该实现一个队列处理程序吗？如果是这样，哪个选项是最好的？是否有可以集成到 AKS 中的天蓝色原生服务？
或者是否足以为我的 pod 实施就绪探测？如果是这样，最好的设置是什么？一个有 2 个线程的 GUNICORN 工作线程，以及一个用于我的 API 的简单检查端点？
【问题讨论】：
标签： nginx flask queue gunicorn azure-aks
除非有特殊要求，否则我会从移除 Nginx 反向代理开始，如果流量仅用于集群内部访问，则依赖普通的 kubernetes 服务，如果用于外部访问，则使用带有 Ingress 的服务。
这样做的原因是，除非您在配置 Nginx 反向代理时非常小心，否则它可能无法以最佳方式工作。例如，当远程访问此服务时，将执行 NAT'ing，其中有一个额外的 Nginx 可能会因为 NAT'ing 将请求固定到单个会话/IP，因此有多个新请求被重复发送到同一个后端. Nginx 入口支持许多注释来帮助配置它，即：
Horizontal Pod Autoscaler 也很适合这种情况；因为这将允许您的应用程序按需扩展（在一组配置的限制内）。如果您希望处理尽可能接近实时，IMO 这将是实现队列的一种更可取的方法。如果您不介意为处理添加更长的延迟，那么工作队列模型可能更合适，因为它可能需要更少的资源。
正如您所提到的，您应该为您的应用设置就绪和活跃度探测器，以便 Kubernetes 能够更好地了解它们的健康状况。就绪探测是 Kubernetes 用来了解是否考虑 Pod 准备好接受流量，从而影响服务是否将流量路由到 Pod。活跃度检查让 kubernetes 了解何时/是否应该重新启动 pod，这对于在不可恢复的条件停止 pod 后重新启动很有用。
这里有一些关于 Kubernetes 探针的进一步阅读参考资料：
希望这会有所帮助。
【讨论】：