Limit active application sessions to a pod/container

[deepakkhetwal]

Is your feature request related to a problem? Please describe.
We are deploying an asp.net application that makes heavy use of in-process IIS sessions in on-premise Kubernetes environment. We would like to limit the number of active asp.net application sessions, residing in a container/pod at a given point of time based on some configuration. So let’s say, If I have configured 5 active sessions to be allowed to be in a kubernetes container/pod at a given point of time, then for the 6th session, nginx ingress controller should be able to route the request to new available pod/container(also taking into consideration the new pods limit on active number of sessions). Please advise, how it can be achieved using nginx ingress controller or some other means. Active/established sessions would continue to route to their "assigned" pod (session affinity).

Describe the solution you'd like
may be through ingress annotations

Describe alternatives you've considered
Don't have any alternative at the moment

[pleshakov]

Hi @deepakkhetwal

What is an established session? Is it a connection?

[deepakkhetwal]

It is a asp.net cookie user specific session

…

On Thu, Feb 18, 2021 at 7:45 PM Michael Pleshakov ***@***.***> wrote: Hi @deepakkhetwal <https://github.com/deepakkhetwal> What is an established session? Is it a connection? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1395 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FFBWB5XN2RC3T2VIXLDTS7WYBJANCNFSM4X2W5ISA> .

[pleshakov]

Hi @deepakkhetwal

apologies for the delay

it is not possible to support that use case: NGINX can't determine which pods has fewer sessions and it cannot limit sessions per pod.

however, it is possible to achieve persistence - each session will be tight to one pod. That is possible via nginx.org/lb-method annotation with iphash load balancing method - in this case requests from the same IP will be proxied to the same backend pod. See https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/ Or, using session persistence with NGINX Plus -- https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/session-persistence -- which is based on a session cookie which NGINX Plus can issue.

[deepakkhetwal]

Thank you Michael for your response. is it possible to have a customized nginx version based on our need? or you are saying it's not possible at all even after customization?. If customization is possible, would you be able to point me to the code base, where I should be looking to make desired changes? like which file/folder in github?

…

On Fri, Feb 26, 2021 at 7:47 PM Michael Pleshakov ***@***.***> wrote: Hi @deepakkhetwal <https://github.com/deepakkhetwal> apologies for the delay it is not possible to support that use case: NGINX can't determine which pods has fewer sessions and it cannot limit sessions per pod. however, it is possible to achieve persistence - each session will be tight to one pod. That is possible via nginx.org/lb-method annotation with iphash load balancing method - in this case requests from the same IP will be proxied to the same backend pod. See https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/advanced-configuration-with-annotations/ Or, using session persistence with NGINX Plus -- https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/session-persistence -- which is based on a session cookie which NGINX Plus can issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1395 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB6FFBUYQTYQD5TTPW5242TTBA6KLANCNFSM4X2W5ISA> .

[pleshakov]

Hi @deepakkhetwal

I don't think it would be possible to customize NGINX to support your use case.

[deepakkhetwal]

@pleshakov I was looking at #267 . HA proxy has drain support. do you have something like that?

[pleshakov]

@deepakkhetwal unfortunately, we don't support that

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions]

This issue was closed because it has been stalled for 7 days with no activity.