Sneh's Blog

Redirect Issue in the Bank App Deployed on EKS on custom domain

sneh srivastava's photo
sneh srivastava
·

3 min read

How Session Affinity Solved the Redirect Issue in the Bank App Deployed on EKS

When deploying applications on Kubernetes with an ingress controller (e.g., NGINX ingress), maintaining consistent user sessions becomes crucial for web applications, especially for login-based workflows. In this case, adding the following annotations to the ingress configuration resolved the issue of being redirected repeatedly to the login page:

nginx.ingress.kubernetes.io/affinity: cookie
nginx.ingress.kubernetes.io/session-cookie-name: bankapp_session
nginx.ingress.kubernetes.io/session-cookie-hash: sha1

Root Cause of the Issue

  1. Session Stickiness:

    • Without session affinity, requests from a client may be routed to different pods in the backend.

    • When a user logs in, their session is typically stored in-memory on the pod that processed the request. If a subsequent request (e.g., navigating to the dashboard) is routed to a different pod that does not recognize the session, the application considers the user as logged out and redirects them to the login page.

  2. Stateless vs. Stateful Applications:

    • Kubernetes’ default behavior is stateless. In the absence of mechanisms like session affinity or an external session store (e.g., Redis), session continuity across pods is lost, leading to the observed issue.

How the Added Annotations Resolved It

The added annotations configure the ingress to maintain session affinity using cookies. Here’s how each annotation contributes:

  1. nginx.ingress.kubernetes.io/affinity: cookie:

    • Enables session stickiness at the ingress level by using cookies.

    • Ensures that all requests from a specific client are routed to the same backend pod.

  2. nginx.ingress.kubernetes.io/session-cookie-name: bankapp_session:

    • Sets the name of the session cookie to bankapp_session.

    • This cookie is sent by the client with each subsequent request, allowing the ingress controller to identify the correct pod to route the request to.

  3. nginx.ingress.kubernetes.io/session-cookie-hash: sha1:

    • Specifies the hashing algorithm (SHA1 in this case) used to generate the session cookie.

    • The hash ensures the cookie’s integrity and prevents tampering, adding a layer of security.

Why This Fix Worked

  • With these annotations, the ingress controller ensures that after a client logs in, all subsequent requests (e.g., accessing the dashboard) are directed to the same pod where the session data resides.

  • This avoids session inconsistencies caused by requests being routed to different pods.

Benefits of Using Ingress-Based Session Affinity

  1. Simplifies Backend Configuration:

    • No need to implement external session storage (e.g., database, Redis) for session persistence.

  2. Transparent to Clients:

    • Clients do not need to be aware of the backend’s distributed nature.

  3. Easy to Configure:

    • Ingress annotations provide a simple and declarative way to enable session affinity.

Limitations

  • Pod-Specific Sessions:

    • If the pod crashes or is rescheduled, the session data is lost unless external session storage is used.

  • Load Balancing Imbalance:

    • Session stickiness can lead to uneven distribution of requests among pods.

Conclusion

By enabling session affinity using cookie-based stickiness, the ingress ensured consistent routing of requests for logged-in users to the same pod. This resolved the issue of repeated redirection to the login page, providing a seamless user experience. For production-grade deployments, consider combining session affinity with robust session storage mechanisms to ensure high availability and fault tolerance.

Happy Learning!! 😄

EKSAWSKubernetes