Sticky sessions/Session Affinity based on Nginx Ingress on OVHcloud Managed Kubernetes
Objective
Sticky sessions or session affinity, is a feature that allows you to keep a session alive for a certain period of time. In a Kubernetes cluster, all the traffic from a client to an application, even if you scale from 1 to 3 or more replicas, will be redirected to the same pod.
In this tutorial we are going to:
- deploy an application on your OVHcloud Managed Kubernetes cluster through a
deploymentwith several replicas - setup an Nginx Ingress
- deploy an
Ingressto configure the Nginx Ingress Controller to use sticky sessions/session affinity - test the session affinity
Before you begin
This tutorial presupposes that you already have a working OVHcloud Managed Kubernetes cluster, and some basic knowledge of how to operate it. If you want to know more on those topics, please look at the OVHcloud Managed Kubernetes Service Quickstart.
You also need to have Helm installer on your workstation and your cluster. Please refer to the How to install Helm on OVHcloud Managed Kubernetes Service tutorial.
Instructions
Deploying the application
In this guide you will deploy an application, in Golang, that runs a HTTP server and displays the Pod name.
This kind of application will allow you to validate that Nginx Ingress correctly maintains the session.
First, create a deployment.yml file with the following content:
This YAML deployment manifest file defines that our application, based on ovhplatform/what-is-my-pod:1.0.1 image will be deployed with 3 replicas (3 pods). We pass the pod name on environment variable in order to display it in our what-is-my-pod application.
Then, create a svc.yml file with the following content to define our service (a service exposes a deployment):
Apply the deployment and service manifest files to your cluster with the following commands:
Output should be like this:
You can verify if your application is running and service is created by running the following commands:
Output should be like this:
Installing the Nginx Ingress Controller Helm chart
For this tutorial, we are using the Nginx Ingress Controller Helm chart found on its own Helm repository.
The chart is fully configurable, but here we are using the default configuration.
Add the Ingress Nginx Helm repository:
These commands will add the Ingress Nginx Helm repository to your local Helm chart repository and update the installed chart repositories:
Install the latest version of Ingress Nginx with helm install command:
The install process will begin and a new ingress-nginx namespace will be created.
As the LoadBalancer creation is asynchronous, and the provisioning of the load balancer can take several minutes, you will surely get a <pending> EXTERNAL-IP.
If you try again in a few minutes you should get an EXTERNAL-IP:
You can then access your nginx-ingress at http://[YOUR_LOAD_BALANCER_IP] via HTTP or https://[YOUR_LOAD_BALANCER_IP] via HTTPS.
Configuring the Nginx Ingress Controller to use sticky sessions/session affinity
At this step, you need to deploy an Ingress resource and configure it to use the sticky sessions.
Create an ingress-session-affinity.yml file with the following content:
In this manifest file you can see that we define a Nginx Ingress resource with several annotations. For more information about the annotations, please refer to the Nginx Ingress Controller documentation.
Apply the ingress manifest files to your cluster with the following commands:
Output should be like this:
You have set-up and configured a Kubernetes Ingress resource that will maintain sessions for users, as in the illustration below:

Test the session affinity
The final step of this guide is to access our application and test the session affinity.
Execute the following command to retrieve the Load-Balancer IP created by the Nginx Ingress Controller:
You should have a Load-Balancer IP like this:
Now you can access this IP through your favorite browser and reload the page several times:

Everytime you reload the page, you should get the same cookie value, so the Ingress redirects you to the same Pod.
You can also test the behavior with curl command like this:
You can execute the same command several times in a loop to validate that the session is correctly maintained:
The tips with using curl with cookies is to store the received cookie in a file and read back the cookies from that file later.
Go further
-
If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project.
-
Join our community of users.