1

I write a virtual service to test header based routing

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: http-app
  namespace: default
spec:
  hosts:
    - http-app.default.svc.cluster.local
  http:
    - match:
        - headers:
            canary-token:
              exact: haha
      route:
        - destination:
            host: http-app.default.svc.cluster.local
            subset: canary
    - route:
        - destination:
            host: http-app.default.svc.cluster.local
            subset: stable

The traffic routing is right when service is

apiVersion: v1
kind: Service
metadata:
  name: http-app
  namespace: default
  labels:
    env: prod
spec:
  type: ClusterIP
  selector:
    app: http-app
  ports:
    - port: 3011
      targetPort: 3011

[2023-08-28T04:00:01.156Z] "GET /mesh HTTP/1.1" 200 - via_upstream - "-" 0 78 645 644 "192.168.65.4, 127.0.0.6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.54" "24cb1d39-33f6-4e07-8ba5-fefc4c656498" "nginx-app.local" "10.1.13.85:3011" outbound|3011|canary|http-app.default.svc.cluster.local 10.1.13.93:44452 10.104.186.154:3011 127.0.0.6:0 - -

But when I explicit set protocol to http like this

  ports:
    - port: 3011
      targetPort: 3011
      appProtocol: http

or this

  ports:
    - name: http-app
      port: 3011
      targetPort: 3011

The traffic routing will be allow_any

[2023-08-28T11:23:10.344Z] "GET /mesh HTTP/1.1" 200 - via_upstream - "-" 0 78 652 652 "192.168.113.118,192.168.65.4, 127.0.0.6" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36 Edg/116.0.1938.54" "f54af48b-6f67-4f64-ba05-2d5d9215fd8c" "nginx-app.local" "10.104.186.154:3011" PassthroughCluster 10.1.13.93:38016 10.104.186.154:3011 127.0.0.6:0 - allow_any

Why after explicit set protocol, the header based routing not work?

blastz
  • 525
  • 5
  • 14
  • Istio supports both automatic and explicit protocol selection. The access log shared, in that the response returned are with http 200 status code in both the cases and there is no error. More details of protocol selection are in https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/#explicit-protocol-selection – Nataraj Medayhal Aug 31 '23 at 04:58
  • As per the official document,ALLOW\_ANY is enabled by default under meshconfig while installing Istio and also Http status code 200 is not an error. [https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/](https://istio.io/latest/docs/tasks/traffic-management/egress/egress-control/) – Kiran Kotturi Aug 31 '23 at 06:48

0 Answers0