我们有一个我们正在考虑使用 GKE 的 Web 服务，它具有以下独特功能：
每个会话都涉及客户端上传大量数据，这些数据经过预处理并存储在 Pod 的内存中 - 每个会话介于 1GB 到 5GB 之间。出于性能原因，我们认为在 Pod 的内存中简单地维护会话而不是像 Reddis 那样拥有共享数据库是有意义的（即 Pod 不是无状态的 - 因此标题中提到了粘性会话）。这样，当来自客户端的下一个请求来自客户端尝试对其数据进行另一次繁重的计算时，它已准备好处理它并返回结果，而无需从 Reddis 等外部源重新生成大量内存状态。
每个 Pod 需要整个 VM 的资源（例如 4vCPU 32GB 和 1 个 GPU 连接），因为它为每个连接的会话提供的服务涉及 GPU/CPU 使用的短暂爆发。（即水平扩展每次都需要新的节点，而不是单个节点上的额外 pod）。这个想法是 Pod 可以支持的会话数量仅受节点上的内存限制（因为实际处理将在前面提到的短脉冲中发生）。
似乎 GKE 开箱即用的自动扩展（目标内存使用率约为 50%）对于这些重负荷会话来说效果很好，但这是我的担忧：
- GKE、粘性会话和负载平衡：假设我们使用 nginx-ingress 之类的东西使用 cookie https://kubernetes.github.io/ingress-nginx/examples/affinity/cookie/对于粘性会话 - 考虑到 GKE 和 nginx 负载均衡器的参与，如何将新会话分配给“正确”节点？例如，假设我有 2 个节点，每个节点有 10 个会话，但碰巧第一个节点的会话每个使用 3GB（90% 的节点内存使用），而第二个节点的会话每个使用 1GB（30% 的节点内存使用）。理想情况下，任何新会话都将路由到 30% 内存使用 Pod - GKE 会在此设置中实现这一点（鉴于其平均内存使用率为 50% 的目标）？或者它只是一个简单的循环，即使另一个节点有足够的内存并且可以轻松支持额外的会话，具有 90% 内存使用率的节点可能会过度扩展？
- 粘性会话和缩减：考虑以下假设：假设我们有 10 个节点，每个节点有 10 个当前活动的会话，在这种情况下，每个节点的内存使用率为 50%（正好在我们的 GKE 内存使用目标）。现在假设稍后，每个节点下降到只有 1 个当前活动会话和 5% 的内存使用。重要的是这些节点保持“活跃”以保持它们各自的粘性会话继续进行。GKE 是否足够“智能”（可能具有与粘性会话相关的特定配置？）以识别这一点并避免杀死具有活动粘性会话的节点，尽管平均内存使用量如此之低？有什么方法可以配置它以这种方式运行吗？
GKE 似乎非常适合无状态服务，但对于像我们这样的服务而言，每个会话涉及大量内存，其中将状态卸载到外部存储库（如 Reddis）并为每个后续请求重新加载它会导致显着的性能下降，我不太确定它可以很好地工作......但如果我能解决上述问题，我可以确信 GKE 将确保新会话被路由到内存使用率较低的节点，并且 GKE 不会杀死具有活动会话的节点（是的，会话会超时，因此它们不会使节点永远保持活动状态），那么我认为这可能非常合适。
我也绝对愿意接受其他建议，我是 Kubernetes 新手，至少可以说黑匣子令人生畏！
编辑（有关应用程序的其他详细信息以获取更多上下文）：我们当前的想法是让每个 Pod 运行一个 python Web 应用程序，该应用程序充当生成子进程的监督者，这些子进程实际上完成繁重的工作，每个粘性会话一个子进程。然后似乎只需将来自客户端的请求路由到它们各自的子进程以进行繁重的处理并将结果返回给客户端。只要会话处于活动状态（当然有超时），子进程就会保持活动状态。这里的关键似乎是每个子进程/会话都需要 1-5GB 的内存，因此出于性能原因（不仅是带宽问题，而且还要重新生成州），所以我们'