I'm looking into the design of a system where hopefully many parts will map well to a Kubernetes based deployment by becoming single purpose, stateless services.

However some parts are unlikely to fit that model well and I am looking for help with understanding what options might be best to explore for those parts..

Specifically I expect to have some applications which form the backend of a highly interactive UI. The backend will present views derived from large data sets based on continual or frequent user interaction. Think of something like a single player game or a CAD program.

As such these applications require frequent local access to large data loaded from distant storage and also access to continually updated user state that is probably too large to be serialized and deserialized between user interactions. Such state is currently just stored in process memory as volatile application state. There are also security concerns about ensuring that details from a user session are not exposed to other users.

I think repeated fast access to the distant data is solvable e.g. it could be cached locally to a pod using a volume backed with shared memory and some stateless service to populate it. Then that cache reused by a sticky session.

However repeated fast access to the quick changing volatile state seems to be a harder problem to solve. One approach I can imagine is that the client should always connect to the same application instance for the length of a user session and that other users should never connect to that instance.

So far I have looked into Kubernetes jobs and also statefulsets with sticky sessions through an nginx ingress controller. I don't think either of these meet all of these requirements. I've also heard mention of custom load balancers and operators but I haven't yet learnt about these in detail.

Despite the mismatch with core Kubernetes use cases I'd like to consider solutions that can make use of it (maybe with extensions) and avoid the need to implement a whole separate custom lifetime management layer for a volatile process/container that is completely separate from Kubernetes.

Can anyone suggest the best approach to consider?