istio: Session affinity doesn't seem to apply to weighted subsets - Envoy support required
Describe the bug When attempting to apply session affinity to weighted subsets, the session affinity doesn’t seem to apply and the subsets will randomly get served based on their weights as normal. Session affinity works as expected when not applying custom weighted subsets.
Expected behavior Session affinity to apply on top of weighted subsets. So user will randomly be sent to a version based on the assigned weight, and once they get to that version, they will continue being served that version.
Steps to reproduce the bug
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: hello-world
namespace: hdngo
spec:
host: hello-world.hdngo.svc.cluster.local
trafficPolicy:
loadBalancer:
consistentHash:
httpCookie:
name: user
ttl: 0s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
- name: v3
labels:
version: v3
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: hello-world
namespace: istio-system
spec:
gateways:
- istio-autogenerated-k8s-ingress
hosts:
- "*"
http:
- route:
- destination:
host: hello-world.hdngo.svc.cluster.local
subset: v1
weight: 60
- destination:
host: hello-world.hdngo.svc.cluster.local
subset: v2
weight: 30
- destination:
host: hello-world.hdngo.svc.cluster.local
subset: v3
weight: 10
Version
istioctl version
Version: 1.0.2
GitRevision: d639408fded355fb906ef2a1f9e8ffddc24c3d64
User: root@66ce69d4a51e
Hub: gcr.io/istio-release
GolangVersion: go1.10.1
BuildStatus: Clean
kubectl version
Client Version: version.Info{Major:"1", Minor:"9", GitVersion:"v1.9.1", GitCommit:"3a1c9449a956b6026f075fa3134ff92f7d55f812", GitTreeState:"clean", BuildDate:"2018-01-04T11:52:23Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.8+IKS", GitCommit:"6e1ad1c45c23e44d15090962f3e738735998687a", GitTreeState:"clean", BuildDate:"2018-09-27T13:44:25Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
Installation Using Helm according to the documentation here.
Environment IBM Cloud Public
Cluster state N/A.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 14
- Comments: 39 (11 by maintainers)
In my use case, I solved that issue with the following configuration.
🚧 This issue or pull request has been closed due to not having had activity from an Istio team member since 2019-09-12. If you feel this issue or pull request deserves attention, please reopen the issue. Please see this wiki page for more information. Thank you for your contributions.
Created by the issue and PR lifecycle manager.
Has there been any progress regarding the ability to have weight-based routing + consistentHashLB to prevent traffic from being split up between multiple pods on a single page load?
Is there a workaround for this?
I ask because a real life example shows how important this is: I have two different versions of my web app which “compile” random names for JavaScript files using WebPack to kill caching between versions. If my route changes mid download of a JS file (which it appears it does as this is the behavior I am seeing) the file may or may not exist in the version I have just switched to because it might have a different name so it terminates downloading with only a partial file. The call succeeds with 200 but the contents are incomplete.
Even if it didn’t the contents of the file could change between versions so if it can’t choose a subset at first request and stick to that subset then I could essentially be downloading a file whose contents change mid stream maybe?
Ran into the exact same issue. This is really a deal breaker for us. Is there any alternative?
In this file, the trafficPolicy is specified as a subset config, not as a global DestinationRule config. So I guess the behaviour described on this issue was not supposed to work.
According to this file, the sticky sessions works between pods inside a subset, not between subsets, which makes the sticky session useless for canary deployments.
Was this behaviour intentional, or is this a bug?
is https://github.com/istio/istio/issues/9764#issuecomment-631994703 still the only way to achieve this or is the integration with envoy’s consistent hashing doable across weights/subsets now? (and if not shouldn’t this be open?)
For the time being, are there any suggestions for a workaround? I’m also following Envoy’s issue envoyproxy/envoy#8167
@Gadigg sorry, missed that issue, let me check it.