Bug description

Due to a restriction in Envoy’s http 1.1 parser, I’m forced to SNI route to one of my backend services using TCP. Unfortunately, this service is stateful: I need to ensure multiple flows from the same source arrive at the same pod. I decided to use consistent hashing based on the source IP to achieve this

It does not work. Successive requests from the same source IP are sent to different pods. Looking through the proxy-config, I didn't see the relevant configuration in the tcpProxy, so it looks like istio just didn't generate the corresponding config. I also couldn't find anything in the istio source aside from http-related configuration.

I posted about this on the istio discussion board, but didn't hear anything back: https://discuss.istio.io/t/consistent-hashing-not-supported-for-tls-tcp-proxies/10629

[ ] Docs
[ ] Installation
[ X ] Networking
[ X ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade

Expected behavior

Requests from the same IP will go to the same pod, barring any changes in cluster state.

Note: Envoy definitely supports this (I was able to work around by using an EnvoyFilter to patch the tcp proxy).

Steps to reproduce the bug

Configure a TCP gateway and virtual service. Configure source IP based consistent hashing to a tcp service with multiple instances. Send traffic hitting that route from the same IP. See that the connections are sent to different pods.

E.g. destination rule:

  trafficPolicy:
    connectionPool:
      tcp:
        connectTimeout: 1500ms
    loadBalancer:
      consistentHash:
        useSourceIp: true
    outlierDetection:
      baseEjectionTime: 2s
      consecutiveGatewayErrors: 3
      interval: 5s

Version (include the output of istioctl version --remote and kubectl version --short and helm version --short if you used Helm)

client version: 1.9.5
control plane version: 1.9.5
data plane version: 1.9.5

How was Istio installed?

istioctl install

Environment where the bug was observed (cloud vendor, OS, etc)

GKE

Workaround

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: source-ip-hash
  namespace: istio-system
spec:
  configPatches:
  - applyTo: NETWORK_FILTER
    match:
      context: GATEWAY
      listener:
        portNumber: 8443
        filterChain:
          filter:
            name: "envoy.filters.network.tcp_proxy"
            sni: my-tcp-service.example.com
    patch:
      operation: MERGE
      value:
        typed_config:
          "@type": "type.googleapis.com/envoy.extensions.filters.network.tcp_proxy.v3.TcpProxy"
          hashPolicy:
            - sourceIp: {}