Feature Request: Add support for multiple listeners on Virtual Node and Virtual Router

[kiranmeduri]

Tell us about your request
What do you want us to build?
Today, virtual-node and virtual-router only allow single listener. Some applications have use-cases where they need to expose multiple ports and they cannot use App Mesh to support communication between these applications. Below are some sample applications

1. Service supports multiple protocols e.g. HTTP and gRPC
2. Service supports multiple access domains e.g. Admin port, Traffic port
3. ... Please add more

Which integration(s) is this request for?
None

Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?

Are you currently working around this issue?
How are you currently solving this problem?
Today I have to run multiple versions of service per port exposed. This increases cost and management.

Additional context
Anything else we should know?

Attachments
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

[piontas]

Another use case is when you have applications metrics, health checks running on different port.

There is no option to allow, whitelist or ignore TCP ingress port in App Mesh settings / ENV variables.

Example deployment configuration

containers:
        - name: dummy-name
          image: "dummy-repo/dummy-image
          ports:
            - name: service
              containerPort: 8080
              protocol: TCP
            - name: health
              containerPort: 8081
              protocol: TCP
          livenessProbe:
            httpGet:
              path: /liveness
              port: 8081
            timeoutSeconds: 5
          readinessProbe:
            httpGet:
              path: /readiness
              port: 8081
            timeoutSeconds: 30

Is there any other way to solve it?

[KushalP]

Any further news on this? When using AppMesh we're having to comment out our Deployment configuration to be:

containers:
  - name: dummy-name
    image: "dummy-repo/dummy-image"
    ports:
      - name: service
        containerPort: 8080
        protocol: TCP
      - name: health
        containerPort: 8081
        protocol: TCP
    # App Mesh doesn't support more than one listener as of today.
    # Whenever it's supported we will use liveness and readiness
    # probes.
    # See: https://github.com/aws/aws-app-mesh-roadmap/issues/120
    # livenessProbe:
    #   httpGet:
    #     path: /liveness
    #     port: 8081
    #   timeoutSeconds: 5
    # readinessProbe:
    #   httpGet:
    #     path: /readiness
    #     port: 8081
    #   timeoutSeconds: 30

As a result, we're forced to blind deploy pods that expect to have these checks occur on a separate port.

[KushalP]

Is it possible to have APPMESH_IGNORED_INGRESS_PORTS similar to the egress env var to get around this in the short-term?

[malphi]

This request make sense. Our case is that: a service provide http and grpc call for clients, when different clients use both protocol to access, it doesn't work. Such as ELB use http for health check, another client use grpc for business logic.
In istio, VirtualService can handle this request with multiple routes, but VirtualNode of AppMesh cannot support that.

[treynash]

Is there any more specific update on this issue other than Accepted? Unfortunately, this issue is preventing us from using appmesh in some of our scenarios because we must expose multiple ports with multiple protocols.

[awsiv]

Affects us as well:

For spring apps, its normal to have service port eg. 8080 and management port eg. 9180/health. The healthcheck port should be allowed to be different from listener port. Currently both must be the same

[asakchris]

Virtual Node listeners should support health check on different port like Target Group. Getting below error now:

HealthCheck port must be the same port configured on the listener. (Service: AWSAppMesh; Status Code: 400; Error Code: BadRequestException; Request ID: XXXXXXXXXXX; Proxy: null)

[Knappek]

I am also facing this issue where I am trying to add Cortex to App Mesh. The cortex distributor has to have an http listener that is used by prometheus to send metrics via remoteWrite and another listener on port 7946 for gossip ring discovery with all cortex components. Hence right now it is not possible to instrument Cortex on App Mesh.

[twanc]

it looks as quite important feature, why its even not prioritized? :)

[matthewcummings]

@twanc might just be that the team is overwhelmed. I'm considering a migration to EKS and Istio because of this, it's almost a showstopper for me.

[herrhound]

@twanc – we've accepted the multi-listener support to our roadmap and prioritized it. I moved it to the "Researching" lane to better reflect the actual status of this project.

[begemotik]

any ETA on resolving the issue?

[alexbrjo]

We are working on multiple listeners for Virtual Gateways, Virtual Nodes and Virtual Routers. Usage will be pretty simple, users will be able to list more than one listener like so:

Listeners:
- PortMapping:
    Port: 80
    Protocol: http
- PortMapping:
    Port: 8080
    Protocol: grpc

If a user added a second listener to a Virtual Node that routes point to, it would be ambiguous which listener should receive the traffic. There are several cases like this so we are adding the port field to all API objects where multiple listeners introduce ambiguity.

# spec for a Route
HttpRoute:
  Match: 
    Prefix: "/home"
    Port: 80  # new port field to disambiguate which Virtual Router listener this route is receiving traffic from
  Action:
    WeightedTargets:
    - VirtualNode: myVirtualNode
      Weight: 1
      Port: 80 # new port field to disambiguate which listener the route is pointing to

# spec for a GatewayRoute
HttpRoute:
  Match: 
    Prefix: "/home"
    Port: 80  # new port field to disambiguate which Virtual Router listener this route is receiving traffic from
  Action:
    Target:
      VirtualService: 
        VirtualServiceName: "example.com"
        Port: 80 # new port field to disambiguate which listener the route is pointing to

[herrhound]

Multiple listeners are available in the preview channel: https://docs.aws.amazon.com/app-mesh/latest/userguide/multiple-listeners.html

[Breefield]

Hello, it's very cool to see this is in the preview channel!
I'm wondering when it's anticipated that this feature will come out of preview and be generally available?

[rakeb]

We are happy to announce that, today we released Multiple Listeners feature support. The feature is now generally available. Now, App Mesh users can create more than one listeners in Virtual Gateways, Virtual Nodes and Virtual Routes. Please take a look in AWS App Mesh adds support for multiple listeners.