istio: Web-sockets upgrade not working in alphav3

Describe the bug Prefix matching rules to upgrade the connection to web sockets are applied(kubctl apply) . When a request is made to WebSocket URL 404 occurs . It was observed that the rules are not seen in the envoy routes(istioctl proxy-config routes).

Expected behavior For URI’s filtered Web sockets must be working.

Steps to reproduce the bug apply the Virtual Service rules and you see envoy routes not being updated.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: fashtagbackend-virtual-service
  namespace: fashtagbackend
spec:
  gateways:
  - fashtagbackend-gateway
  hosts:
  - 'fashtagbackend.fashtag.info'
  - fashtagbackend-service.backend.svc.cluster.local
  http:
  - match:
    - uri:
        prefix: "/replenishment/"
    route:
    - destination:
        host: fashtagbackend-service
      weight: 100
    websocketUpgrade: true
  - match:
    - uri:
        prefix: "/inventoryCount/"
    route:
    - destination:
        host: fashtagbackend-service
      weight: 100
    websocketUpgrade: true
  - match:
    - uri:
        prefix: "/transfer"
    route:
    - destination:
        host: fashtagbackend-service
      weight: 100
    websocketUpgrade: true
  - match:
    - uri:
        prefix: "/api/"
    route:
    - destination:
        host: fashtagbackend-service
      weight: 100

Version kubectl version - Major:“1”, Minor:“13” istioctl version - 1.0.5 Installation Istio is installed using helm Environment AWS

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (11 by maintainers)

Most upvoted comments

Hi, we have similar deployment as yours, and all websocket connections working fine. First thing I noticed, if cluster contains multiple Gateway resources (we have one for each resource domain), then spec.servers.port.name must be unique across cluster. This requirements happened when we upgraded from 0.8 to 1.0.2. Second, istio-proxy (backed by Envoy) is just reverse proxy, and shall add Upgrade http header in each hop with initial connection handshake (by websocket protocol design). If your backend service implement http WS handshake in plain tcp, its ok, but envoy doesn’t know in this case, that underground there is http proto, and doesn’t make connection upgrade in this hop.

I am also seeing issues with websockets when the sidecar is in place (404’s from Envoy). The service I have that listens for websocket connections is using tcp as the port name. Shouldn’t that translate to L4 proxying and not care about what’s on top?