-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit active application sessions to a pod/container #1395
Comments
What is an established session? Is it a connection? |
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>
.
|
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 |
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>
.
|
I don't think it would be possible to customize NGINX to support your use case. |
@pleshakov I was looking at #267 . HA proxy has drain support. do you have something like that? |
@deepakkhetwal unfortunately, we don't support that |
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. |
This issue was closed because it has been stalled for 7 days with no activity. |
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
The text was updated successfully, but these errors were encountered: