3

I have a questions regarding Nodejs in kubernetes. As I want my service to be scalable by the kubernetes, means that I will have multiple pods under 1 service.

lets say I have Pod-1 Pod-2 and Pod-3. Then I will run a puppeteer in the pod based on the request.

For example if a request is like bellow

{
   "id": "A"
}

If id=A is assigned to Pod-2 for the first time, then Pod-2 will start a puppeteer based on the id=A. While my puppeteer is opened forever (to listen event from a website). Thats why I need id=A to be always processed by Pod-2 forever.

If Pod-2 has a failover, then the service will create a new freshly pod (lets say it as a Pod-4), and kill the Pod-2. since Pod-2 is killed, then the puppeteer is also killed. so any new request for id=A can be routed to anywhere of Pod-1,Pod-3 or Pod-4. Once it is routed to the new Pod, then I will start a new puppeteer based on the id in that Pod

Is this achievable?

P.S. I was looking online, and I found out Akka, that seems can solve this issue. But Akka is meant for Java. When I see Akka for nodejs such as akkajs or comedy, i can't picture how it can work in kubernetes.

Edit-1 : Seems like sticky session does not solve this issue. since sticky session cookies has a lifetime. once the time is reached, the cookies will be deleted, and a new pod might be selected and routed to. Since I want the request to be sent to that pod as long as the pod lives

Mark
  • 2,041
  • 2
  • 18
  • 35
  • 1
    You can "route" request using paths via an ingress, eg: `example.com/A/` will go to `svc-A` and `example.com/B` will go to `svc-B`. But yeah you need to create separate services instead of single. Source: [1](https://stackoverflow.com/questions/65141318/kubernetes-route-ingress-traffic-to-specific-pod-for-some-paths), [2](https://stackoverflow.com/a/63487152) – bogdanoff Oct 28 '22 at 14:38
  • 1
    But this will not be scalable anymore. I need to manually adding the services. What I want to achieve is to make it fully automate. It can know where to send without me actually know where it is sent. – Mark Oct 28 '22 at 14:46
  • 2
    Sticky sessions is what you're looking for, but nothing OTB would do this the way you have described AFAIK. The most basic method just uses cookies to ensure the ame client hits the same backend each time. Might need a custom WASM plugin for istio or similar. – jordanm Oct 28 '22 at 14:59
  • Does this answer your question? [Sticky sessions on Kubernetes cluster](https://stackoverflow.com/questions/59272484/sticky-sessions-on-kubernetes-cluster) – Software Engineer Oct 28 '22 at 20:41
  • I've voted to close this as a duplicate. There are loads of questions about sticky sessions in kubernetes on SO. – Software Engineer Oct 28 '22 at 20:42
  • hi @SoftwareEngineer thanks for replying. actually I was looking into something like `Akka Cluster Sharding` for nodejs, Since I've never heard of the sticky season. but its a good start. let me study the sticky session first. thx – Mark Oct 29 '22 at 01:44
  • hi @jordanm after a day of reading, seems like the sticky season can't solve my issue, since the cookies has a lifetime. once the time is reached, the cookies will be deleted, and a new pod might be selected and routed to. Since I want the request to be sent to that pod as long as the pod lives – Mark Oct 29 '22 at 08:59
  • What do you expect to happen if pod-2 (only) fails; but the rest of the pods are functional, the cluster as a whole is still handling requests, and the end user is unaware of this interruption? Can you keep the session state somewhere like a Redis cache that all of the pod replicas can reach? – David Maze Oct 29 '22 at 10:19
  • hi @DavidMaze, because in my case, each pod is having a listener to a website based on an id. thats why there must not be 2 pods that are listening to the same id. if pod-2 fails, I expect for GKE to create a new fresh pod, and kills the pod-2. thus, the listener in the old pod-2 is killed. So if there is any request for this ID, it can be routed to any pod (either the freshly created pod, or the old one) – Mark Oct 29 '22 at 11:42
  • In this case, you should look at an advanced idea called CQRS. Your first request would create an 'actor' (the puppeteer) that would do the required work (e.g. monitoring a website for changes) and would write its accumulated results to a store somewhere. Subsequent requests to 'read' the data would simply read from this store. If the store doesn't exist (i.e. this is the first request for this info), you would redirect to the URL that creates the actor. This would effectively separate the 'read' and 'write' sides of your application, allowing you to bypass the sticky-session idea. – Software Engineer Oct 31 '22 at 08:08
  • @SoftwareEngineer i have no issue with reading the data. as you said, I can store it somewhere and read it from there. but the puppeteer will do a listen event. its inefficient if for id=A, i create 2 puppeteer, 1 for listening event-1, another one for listening event-2. it would be efficient if it only creates 1 puppeteer, then it listen both event-1 and event-2. Yes I agree with you, I was looking for an 'actor' solution. but I cant find/picture any actor solution in nodeJs that works for kubernetes – Mark Oct 31 '22 at 08:35
  • This plan doesn't stop you for multi-tasking the actors/puppeteers. You can hand off work to an existing puppeteer when you need to. Your initial question though is about sticky-sessions, and with this scheme you don't need them. – Software Engineer Oct 31 '22 at 08:43

0 Answers0