我们正在考虑使用具有以下独特功能的 GKE 网络服务：

> < li>

每次会话都需要客户端上传大量数据，这些数据经过预处理并存储在Pod的内存中-每次会话大约1GB到5GB。出于性能原因，我们认为在Pod中简单地在内存中维护会话是有意义的，而不是像Reddis一样拥有一个共享的DB(即，Pod不是无状态的——因此标题中提到了粘性会话)。这样，当客户端发出下一个请求，试图用它们的数据进行另一个繁重的计算时，它就可以处理这个请求并返回结果，而不需要从Reddis这样的外部源重新生成内存繁重状态。

每个Pod需要整个VM的资源（例如4vCPU 32GB，附加1个GPU），因为它为每个连接的会话提供的服务涉及GPU/CPU使用的短突发（即水平扩容每次都需要新的NODES，而不是单个节点上的额外Pod）。这个想法是Pod可以支持的会话数量仅受节点上内存的限制（因为实际处理将在短突发中发生，如前所述）。

似乎GKE自动扩展开箱即用，目标内存使用量约为50%，对于这些重载会话来说效果很好，但这是我的担忧：

< li>GKE、粘性会话和负载均衡:假设我们对粘性会话使用类似nginx-ingress的东西https://kubernetes . github . io/ingress-nginx/examples/affinity/cookie/例如，假设我有2个节点，每个节点有10个会话，但碰巧第一个节点的会话各使用3GB(90%的节点内存使用率)，第二个节点的会话各使用1GB(30%的节点内存使用率)。理想情况下，任何新的会话都将被路由到30%的内存使用率Pod——GKE会在这个设置中实现这一点吗(假设其目标是平均50%的内存使用率)？或者，这只是一个简单的循环，内存使用率为90%的节点可能会过度扩展，即使另一个节点有足够的内存，可以轻松支持额外的会话？ < li >粘滞会话和缩减:考虑以下假设:假设我们有10个节点，每个节点有10个当前活动的会话，在这些情况下，每个节点的内存使用率为50%(正好达到我们的GKE内存使用率目标)。现在假设稍后，每个节点只剩下1个当前活动的会话和5%的内存使用率。重要的是，这些节点保持“活动”以保持它们各自的粘性会话继续进行。GKE够“聪明”吗(也许有与粘性会话相关的特定配置？)来识别这一点并避免杀死具有活动粘性会话的节点，尽管平均内存使用率如此之低？有什么方法可以让它这样工作吗？

GKE似乎很适合无状态服务，但对于像我们这样的每一个会话都需要大量内存的服务，将状态卸载到外部存储库（如Reddis）并为每个后续请求重新加载将导致显著的性能损失，我不太确定它是否能正常工作。。。但如果我能够解决上述问题，这样我就可以确信GKE将确保新的会话路由到内存使用率较低的节点，并且GKE不会杀死具有活动会话的节点（是的，会话会超时，因此它们不会永远保持节点活动），那么我认为这可能非常合适。

我也很乐意接受其他建议，我是Kubernetes的新手，至少可以说这个黑匣子很吓人！

编辑(关于应用程序的更多细节以了解更多上下文):我们目前的想法是让每个Pod运行一个python web应用程序，该应用程序充当生成子流程的监管程序，这些子流程实际上完成繁重的工作，每个粘性会话一个子流程。然后，似乎只是将请求从客户端路由到它们各自的子流程，以进行繁重的处理，并将结果返回给客户端。只要会话还存在，子流程就会一直存在(当然有超时)。这里的关键问题似乎是，这些子进程/会话中的每一个都需要1-5GB的内存，因此出于性能原因(不仅仅是带宽问题，还包括重新生成状态)，将它传递给外部资源似乎不是一个好主意，因此我们认为最好将状态保存在pod本身的子进程/会话中，然后依靠GKE的水平扩展来按需添加必要的内存资源...假设我们能解决我提到的两个问题。