Virtual service destination port selector required

[DonRenando]

Hello,

Describe the bug

We have canary on a grpc application with portDiscovery enabled. The container of this application has 2 containerPorts.

Flagger will generate the virtual service. In the destionation part of the virtual service, there will be no port field. Even if it works fine like that, we have Istio validation warning, because in the spec of virtual serivce, if we expose more that 1 port, we need to explicitly expose it in destination virtual service

To Reproduce

apiVersion: apps/v1
kind: Deployment
metadata:
  name: add-service
  labels:
    app: add-service
spec:
  selector:
    matchLabels:
      app: add-service
  template:
    metadata:
      labels:
        app: add-service
    spec:
      containers:
      - name: add-service
        image: ibmcom/grpc-ping
        ports:
          - name: grpc
            containerPort: 5555
          - name: http-metrics
            containerPort: 5556

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: add-service
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: add-service
  progressDeadlineSeconds: 60
  # HPA reference (optional)
  autoscalerRef:
    apiVersion: autoscaling/v2beta2
    kind: HorizontalPodAutoscaler
    name: hpa-add-service
  service:
    # ClusterIP port number
    port: 5555
    # container port number or name (optional)
    targetPort: 5555
    # port name can be http or grpc (default http)
    portName: grpc
    # add all the other container ports
    # to the ClusterIP services (default false)
    portDiscovery: true
  # promote the canary without analysing it (default false)
  skipAnalysis: false
  # define the canary analysis timing and KPIs
  analysis:
    # schedule interval (default 60s)
    interval: 0s
    # max number of failed checks before rollback
    threshold: 1
    # number of checks to run before rollback
    iterations: 1

Virtual services will be generated without destination ports.

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  annotations:
    kustomize.toolkit.fluxcd.io/reconcile: disabled
  creationTimestamp: "2023-03-15T09:41:51Z"
  generation: 1
  name: add-service
  namespace: tinyeh
  ownerReferences:
  - apiVersion: flagger.app/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: Canary
    name: add-service
    uid: 53d9f3b6-ac31-407c-ad77-2b56b205183f
  resourceVersion: "1650072349"
  uid: 4fd541e7-9ac7-4946-b436-f9806e7b3023
spec:
  gateways:
  - mesh
  hosts:
  - add-service
  http:
  - route:
    - destination:
        host: add-service-primary
      weight: 100
    - destination:
        host: add-service-canary
      weight: 0

We have the Istio error: Istio Error [IST0112] Specify a port›Specifying a port in the destination is required to disambiguate

Expected behavior

For each port exposed in the containers, generate a virtual service with this ports specified with portDiscovery enabled in the canary item.

Additional context

• Flagger version: 1.21.0
• Kubernetes version: 1.22.0
• Service Mesh provider: Istio (1.12.9)
• Ingress provider: Istio (Envoy)

[nitishkrishna]

I have a similar situation where it breaks when you have 1 http port and 1 gRPC port:

• It cannot discover correct svc port to use in the svc it creates
• It assumes the containerPort == svc port (from deployment spec)
• If I discover http port, then it assumes svc port == 8080 and http traffic breaks (the correct svc port is 80 in our case)
• If I discover gRPC port then the delegation is broken because port 80 is used in the delegated-generated VS, which is not the gRPC port (only the port configured in canary resource is used - so this will be the http port 80)
• So the only situation that works with multiple ports is if you discover the gRPC port BUT do delegation on the http port
• This forces you to use http metrics for analysis metricsTemplate and thus you cannot use gRPC metrics (which is what we want to do)