Sticky sessions
This example demonstrates how to achieve session affinity using cookies.
Deployment
Session affinity can be configured using the following annotations:
Name | Description | Value |
nginx.ingress.kubernetes.io/affinity | Type of the affinity, set this to | string (nginx only supports |
nginx.ingress.kubernetes.io/affinity-mode | The affinity mode defines how sticky a session is. Use |
|
nginx.ingress.kubernetes.io/session-cookie-name | Name of the cookie that will be created | string (defaults to |
nginx.ingress.kubernetes.io/session-cookie-path | Path that will be set on the cookie (required if your Ingress paths use regular expressions) | string (defaults to the currently matched path) |
nginx.ingress.kubernetes.io/session-cookie-max-age | Time until the cookie expires, corresponds to the | number of seconds |
nginx.ingress.kubernetes.io/session-cookie-expires | Legacy version of the previous annotation for compatibility with older browsers, generates an | number of seconds |
nginx.ingress.kubernetes.io/session-cookie-change-on-failure | When set to |
|
You can create the example Ingress to test this:
Validation
You can confirm that the Ingress works:
In the example above, you can see that the response contains a Set-Cookie
header with the settings we have defined. This cookie is created by NGINX, it contains a randomly generated key corresponding to the upstream used for that request (selected using consistent hashing) and has an Expires
directive. If the user changes this cookie, nginx creates a new one and redirects the user to another upstream.
If the backend pool grows nginx will keep sending the requests through the same server of the first request, even if it's overloaded.
When the backend server is removed, the requests are re-routed to another upstream server. This does not require the cookie to be updated because the key's consistent hash will change.
When you have a Service pointing to more than one Ingress, with only one containing affinity configuration, the first created Ingress will be used. This means that you can face the situation that you've configured session affinity on one Ingress and it doesn't work because the Service is pointing to another Ingress that doesn't configure this.
Last updated