我正在研究系统的设计，希望该系统的许多部分将通过成为单一目的的无状态服务而很好地映射到基于Kubernetes的部署。
但是，某些零件不太可能很好地适合该模型，我正在寻求帮助，以了解针对这些零件可能最适合探索的选择。
具体来说，我希望有一些应用程序构成高度交互的UI的后端。后端将基于连续或频繁的用户交互来呈现从大型数据集派生的视图。想一想单人游戏或CAD程序。
因此，这些应用程序需要对从远程存储加载的大数据进行频繁的本地访问，并且还需要访问不断更新的用户状态，该状态可能太大而无法在用户交互之间进行序列化和反序列化。这种状态当前仅作为易失性应用程序状态存储在进程存储器中。 在确保用户会话中的详细信息不会暴露给其他用户方面也存在安全方面的担忧。
我认为可以反复快速访问遥远的数据，例如可以使用共享内存和一些无状态服务支持的卷将其本地缓存到Pod。然后，该缓存由粘性会话重用。
但是，反复快速访问快速变化的挥发性状态似乎是一个更难解决的问题。 我能想到的一种方法是，在用户会话期间，客户端应始终连接到同一应用程序实例，而其他用户则永远不应连接到该实例。
到目前为止，我已经通过nginx入口控制器研究了Kubernetes作业以及带有粘性会话的状态集。我认为这些都不满足所有这些要求。我也听说过有关自定义负载平衡器和运算符的信息，但我还没有详细了解它们。
尽管与核心Kubernetes用例不匹配，但我想考虑可以利用它的解决方案（可能带有扩展），并避免为易失的流程/容器实现整个单独的自定义生命周期管理层的需要与Kubernetes完全分开。
有人可以建议考虑的最佳方法吗？