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.
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: ClusterIP 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”).