Support for multiple Istio HTTPRoute

[adrilo]

Hello,

I'm trying to set up Flagger in a service (Istio cluster) but I can't find how to handle multiple http routes in the virtual service (as defined here: https://istio.io/latest/docs/reference/config/networking/virtual-service/#HTTPRoute).
I'm using multiple http routes to set specific timeouts/retries per endpoint. Here is an example:

spec:
  gateways:
    - istio-system/istio-ilbgateway
    - mesh
  hosts:
    - "{{ .Release.Name }}.{{ .Release.Namespace }}.svc.cluster.local"
  http:
    - match:
      - uri:
          exact: "/api/endpoint-grpc"
      route:
        - destination:
            host: "{{ .Release.Name }}.{{ .Release.Namespace }}.svc.cluster.local"
      timeout: 50ms
      retries:
        attempts: 1
        perTryTimeout: 20ms
        retryOn: "connect-failure,gateway-error,refused-stream,cancelled,deadline-exceeded,unavailable,internal,resource-exhausted"
    - match:
      - uri:
          exact: "/api/endpoint-http"
      route:
        - destination:
            host: "{{ .Release.Name }}.{{ .Release.Namespace }}.svc.cluster.local"
      timeout: 100ms
      retries:
        attempts: 1
        perTryTimeout: 45ms
        retryOn: "connect-failure,gateway-error,refused-stream"
      trafficPolicy:
        connectionPool:
          http:
            maxRetries: 30
    - route:
      - destination:
          host:  {{ .Release.Name }}.{{ .Release.Namespace }}.svc.cluster.local

Looking at the CRD, it does not seem possible to do that. Flagger only generates one HTTP route. The match, timeout, retries and trafficPolicy are global to all endpoints.

Did I get that right or did I miss something? If my analysis is correct, is adding this feature something already planned?

Thanks!

[kazukousen]

👍
I thought too i want to manage in flagger's Canary for a virtual service with multiple routes that has only different timeouts and retries and has same destination, but i encountered same your problem.

if we want route to difference destinations, we just can declare multiple VirtualService. (In short, just declare multiple Canary CRD)
but in this case, i think it can be achieved if the flagger's CRD has one route and multiple matches ...

[adrilo]

@kazukousen With your PR #715, is it going to solve this problem by delegating the virtual service conf to a non-Flagger managed VS?

So something like this:

The VS managed by Flagger (matching all routes):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
spec:
  http:
  - delegate:
       name: productpage
       namespace: nsA

The delegate VS (with multiple matches, not managed by Flagger):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: productpage
  namespace: nsA
spec:
  http:
  - match:
     - uri:
        prefix: "/productpage/v1/"
    route:
    - destination:
        host: productpage-v1.nsA.svc.cluster.local
  - match:
     - uri:
        prefix: "/productpage/v2/"
    route:
    - destination:
        host: productpage-v2.nsA.svc.cluster.local
  - route:
    - destination:
        host: productpage.nsA.svc.cluster.local

[kazukousen]

@adrilo
i would guess that the config would be as follows:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookinfo
  namespace: nsA
spec:
  http:
  - match:
      - uri:
          prefix: /productpage/v1
    delegate:
       name: productpage
       namespace: nsA
  - match:
      - uri:
          prefix: /productpage/v2
    delegate:
       name: productpage-v2
       namespace: nsA
  - match:
      - uri:
          prefix: /
    delegate:
       name: productpage
       namespace: nsA

and some Canary resources to be delegated
(in the above example, productpage.nsA and productpage-v2.nsA)

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: productpage
  namespace: nsA
...

so i think that you can solve your issue with one root VS that set specific timeouts/retries per endpoint and one Canary to be delegated.

isn't this what you want?

[adrilo]

Ah yes, that looks promising!

[chlunde]

I think you can close this issue as delegation support has been merged.