Stateless is the way to go for services running in pods however i have been trying to move a stateful app which needs to perform session persistence if one pod goes does for resiliency reasons.
In websphere world IHS can be used to keep track of the session and if a node goes down it can be recreated on the live clone.
Is there an industry standard way to handle this issue without having to refactor the applications code by persisting the session using some sidecar pod ?
Yes. Store the session somewhere. Spring boot supports out of the box MongoDB, Redis, Hazelcast or any JDBC database.
Spring Boot provides Spring Session auto-configuration for a wide range of data stores. When building a Servlet web application, the following stores can be auto-configured:
JDBC Redis Hazelcast MongoDB When building a reactive web application, the following stores can be auto-configured:
Redis MongoDB If a single Spring Session module is present on the classpath, Spring Boot uses that store implementation automatically. If you have more than one implementation, you must choose the StoreType that you wish to use to store the sessions. For instance, to use JDBC as the back-end store, you can configure your application as follows:
spring.session.store-type=jdbc
[Tip] You can disable Spring Session by setting the store-type to none. Each store has specific additional settings. For instance, it is possible to customize the name of the table for the JDBC store, as shown in the following example:
spring.session.jdbc.table-name=SESSIONS
For setting the timeout of the session you can use the spring.session.timeout property. If that property is not set, the auto-configuration falls back to the value of server.servlet.session.timeout.
Cookie-based sessions are just that, based on cookies. Which are stored by the user's browser, not your app. If you mean a DB-based session with a cookie session ID or similar, then you would need to store things in some kind of central database. I would recommend using an actual database like postgres, but I suppose there is nothing stopping you from using a shared volume :)