K
Q

How to maintain http sessions in an API deployed in Kubernetes?

11/27/2018

I am designing an API which will receive requests from customers and will interact with a cloud backend such as AWS on behalf of the customer. This API has to be scalable so a bit of research led me to believe that I can put the API inside containers and let scale it through Kubernetes. I am planning to use Flask for writing this API. I have three questions in this regard:

  1. Is flask a suitable choice for this? It seems so through my research.
  2. How should the API handle the user authentication to the backend? Should it simply take the username/password from the user, make a connection to the backend based on these credentials, and maintain the resulting connection in memory/database somehow? Is there any other way?
  3. If we take the second approach for user authentication, then the question is: I don't want the API to make a new connection to the backend on every user request. This means I would need to maintain connection state somehow all the while making sure that the API is supposed to work in a decentralized fashion. e.g a user A was served by docker instance 1 of the API previously but now her request gets routed to docker instance 2, in this case I want to use the same connection of the user to the backend, which was established by docker 1 API instance. So how do I maintain this connection? Is it against the principles of a REST API which should be stateless? What is another option to design the system, then? Thanks.
-- ibrar arshad
cloud
flask
kubernetes
rest
scalability

Similar Questions

Should I use configMap for every environment variable?
Schema Registry on Kubernetes, publicly accesible
eks worker node public ip assignment
Why do pods remain in 'pending' status?
K8s deployment error: `selector` does not match template `labels`
Ingress for ECK Kibana

1 Answer

11/27/2018

  1. Flask should be fine, as would be many other approaches, it's up to you how you write your API after all

  2. the best way you could go in my opinion is to have something like bearer token authentication, where you provide some authentication mechanism(s) to token issuing service and when you have a signed token your API (or api gateway / auth proxy) can check if the token is valid (either on it's own or by calling dedicated microservice)

  3. If for any reason you need a session storage, you should implement a separate service that will store that session data. For example you can use Redis as central storage. If you need HA for this service as well, then you'd have to implement your session storage with some clustering support.

-- Radek 'Goblin' Pieczonka
Source: StackOverflow