Menu
I could not find a documentation that specifies how Kubernetes service behaves when the affiliated deployment is scaled with multiple replicas.
I'm assuming there's some sort of load balancing. Is it related to the service type?
Also, I would want to have some affinity in the request forwarded by the service (i.e all requests with a certain suffix should always be mapped to the same pod if possible, etc). Is that achievable? Closes I've seen is Ambassador, but that is affinity in the service level, and not pod level.
577
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.
Services in Kubernetes use the virtual IPs which the kube-proxy feature manages. The former default kube-proxy mode was userspace, which allocates the next available Kubernetes pod using round-robin load distribution on an IP list, and then rotates or otherwise permutes the list.
This means that all traffic from a client to a pod will be directed to the same pod. If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based on the client's IP addresses by setting service.spec.sessionAffinity to "ClientIP"
With this configuration you can't have multiple services listening on port 80. Kubernetes 0.5. x introduced a new networking model, which map an separate IP for each services. So once GKE upgrade you will be able to have multiple services exposed on different IP/ports.
I could not find a documentation that specifies how Kubernetes service behaves when the affiliated deployment is scaled with multi replicas.
Pods deployed with Deployment is supposed to be stateless.
When using Ingress, L7-proxy, the routing can be based on http request content, but this depends on what implementation of an IngressController you are using. E.g. Ingress-nginx has some support for sticky sessions and other implementations may have what you are looking for. E.g. Istio has support similar settings.
Ambassador
Ambassador that you write about does also have some support for session affinity / sticky sessions.
Configuring sticky sessions makes Ambassador route requests to the same backend service in a given session. In other words, requests in a session are served by the same Kubernetes pod
When a pod in your cluster does an http request to a Service within the cluster, the kube-proxy does routing in a round robin way by default.
By default, kube-proxy in userspace mode chooses a backend via a round-robin algorithm.
If you want session affinity on pod-to-service routing, you can set the SessionAffinity: ClientIP field on a Service object.
If you want to make sure that connections from a particular client are passed to the same Pod each time, you can select the session affinity based on client’s IP addresses by setting service.spec.sessionAffinity to “ClientIP” (the default is “None”).
104
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
