Change:
![Services overview diagram](services_overview.png) <ins> By default, the choice of backend is random.  Client-IP-based session affinity can be selected by setting `service.spec.sessionAffinity` to  `"ClientIP"`. </ins> ### Why not use round-robin DNS? A question that pops up every now and then is why we do all this stuff with

Discussion:
Within a Kubernetes cluster each node runs a service proxy that will round robin load balance requests to the various pods within the cluster. Currently there is no mechanism to maintain session affinity for applications that require sticky sessions. To enable session affinity we need to modify the load balancer resides within each node's service proxy to direct requests to specific endpoints based on a client IP address (future enhancement would be to support cookie based session ID). From a high level, I propose the following changes to enable support for session affinity. SessionAffinity to ServiceSpec in (I welcome better object names): a map, serviceDtlMap to the LoadBalanacerRR strcut in The serviceDtlMap will be a map whose key is the service name and value will be a new type called serviceDetail. The serviceDetail struct will hold information about the session affinity settings (is it enabled and the type of session affinity - cookie or client IP) along with a map of ssessionAffinityMap. The sessionAffinityMap will have a key that is either the clientIP or the cookie and the value will a new type called sessionAffinityDetail. The sessionAffinityDetail struct will hold the client IP address, the session cookie, the endpoint url and the last used date and time (last used DTTM will be used for cleaning up old records). the OnUpdate method in to also update the LoadBalancerRR.sessionAffinityMap when new services or endpoints are or removed. LoadBalancerRR NextEndpoint method () to first check the session affinity map for an endpoint based on either the cookie or the client ip address (based on preference in step 1 above). If an endpoint exists for this request, then return that endpoint - otherwise continue with the existing flow of selecting next endpoint and then add this endpoint to the sessionAffnityMap. a background task to clean up stale session affinity records based on some life time setting (say 30 or 60 minutes of inactivity). Note that the external load balancer will also require some form of session affinity, otherwise it could send a client request to node who's service proxy does not have a record for the client in it's session affinity map.
Is this implemented now?
It is implemented, sorry for leaving it open. I had planned to add some documentation (was thinking of adding to guestbook example) while on vacation, but that didn't happen.

I'll close this one and create a separate ticket.
Does this have a doc?
Set to "ClientIP" , Harry Zhang wrote:
We try to use ClientIP session affinity with NodePort type (as opposed to LoadBalancer type) on AWS (for cookie-based HTTP traffic). We have manually created an Amazon load-balancer. ( The AWS load-balancer may use cookie-based session affinity or any other session affinity ). Is ClientIP session affinity (using NodePort) supported also on AWS? Was this implemented & tested on AWS? It seems that AWS load-balancer is exposing its own IP address to Kubernetes - so ClientIP affinity is using only a single pod on each node (the pod that is related to the AWS load-balancer IP address)? Is that so? If so, how can we configure Amazon load-balancer to expose the source client IP? Is that possible? Otherwise, it seems that ClientIP session affinity (using NodePort) is not applicable on AWS....
ELB terminates the client TCP connection and opens a new one. Therefore, the clientIP affinity mode does not work properly with ELB. I don't have a better answer, unfortunately. are there any clever workarounds?
one way to achieve this is enabling proxy protocol on ELB and using an intermediary nginx container to pass the real IP to your service (maybe this is now supported directly in kube-proxy or ingress. Is it ?) I had written a blog post on this topic -
PROXY protocol is not directly supported - we'd have to peek at the TCP stream to do that.
Turns out some of the info I had given was incorrect. Sorry about that. You can check the full discussion here -
Can you take your post down if it's not correct? People (such as myself) are finding your post and thinking it's the proper solution, only to have problems and dig down to find these issues. By the way, really appreciate you being the trailblazer and investigating this matter- we have this need as well.
For future reference: kube-proxy is L4. If your source IP is the same, you can't distinguish clients. You need a L7 proxy to read those details. Check Ingress: This uses cookies to identify your user and skips the L4 kube-proxy invoking the pod directly.