BackendConfig — SessionAffinity — GKE Ingress with NEG

Overview

Hi everyone, within this story, I try to explore around session affinity for workload deployment in GKE. The main concept is how to reflect the capability of session affinity of load balancer into the GKE cluster. It is interesting to have an overview of networking and how this will impact our workloads within GKE deployment.

BackendService — SessionAffinity

Now the interesting about session affinity is the capability to keep the traffic into the same backend that is serving our current workload. This may be very useful in some cases where our communication to the backend service require session to be managed. So within this story, I explore how to add session affinity for GKE Ingress through the backendConfig.

Backend services overview | Load Balancing | Google Cloud

Now for the concept, I add the ingress gateway + network endpoint group + BackendConfig with sessionAffinity: ClientIP for the concept.

The three components give me the result of:

[One] Ingress allows me to have the HTTP/S external LoadBalancer type which helps me to map my workloads and at the same time have some features added.

[Two] NEG on top of HTTP/S LoadBalancer will add some benefit which allows me to have less hop to my container, increase visibility, some additional features (eg. CloudArmor, CDN, IAP; for more detail please go to the documentation link)

[Three] BackendConfig: Session Affinity will allow me to put the configuration to the HTTP/S LoadBalancer. (In this case, I am testing the ClientIP type).

Now to do that it is actually quite straight-forward, we only need to add two annotations related to NEG and BackendConfig on the Service. Please see some sample story on NEG and BackendConfig below:

Container-Native LB through Ingress — GKE

TimeOut Setting on GKE Ingress HTTP/S LoadBalancer through BackendConfig

The first annotation: cloud.google.com/neg: ‘{“ingress”: true}’ allow me to enable the NEG which directly set to the container rather than utilize the instanceGroup of the worker node.

https://cloud.google.com/kubernetes-engine/docs/concepts/container-native-load-balancing#benefits

The second annotation: cloud.google.com/backend-config: ‘{“default”: “be”}’ allow me to actually mapped the BackendConfig that defined with the affinityType: “CLIENT_IP”.

Some Test

On this test, I just want to see how session affinity can be brought with the annotation. Thus I tested with a very simple nodejs (express with trust proxy set) workload which returns the hostname, the req.ip, the req.ips, and the header of [‘x-forwarded-for’].

Hostname: will return the hostname of the container that serve my http call

req.ip: will return the most left of header x-forwarded-for (clientIP)

req.ips: will return the value of x-forwarded-for in an array

x-forwarded-for: is the http header with client ip — loadbalancer ip value

For some test these are the test when we are not using the backendConfig:

we can see how the traffic is routed to a multiple pod, thus the balanced way of LB to spread the traffic

The second test is to implement the backendConfig sessionAffinity (ClientIP):

the result is all the traffic is redirected to the same pod

👋 Join FAUN today and receive similar stories each week in your inbox! ️ Get your weekly dose of the must-read tech stories, news, and tutorials.

Follow us on Twitter 🐦 and Facebook 👥 and Instagram 📷 and join our Facebook and Linkedin Groups 💬

If this post was helpful, please click the clap 👏 button below a few times to show your support for the author! ⬇