Proposal: Port mapping

[stefanprodan]

App Mesh users should be able to define port mappings. Right now the VirtualNode, VirtualRouter and container port must be the same. This makes it impossible to expose an app on port 80 without running the container as root or with CAP_NET_ADMIN and that's not desirable.

Assuming a container exposes port 8080, a user can map it to port 80 with a Kubernetes service like this:

apiVersion: v1
kind: Service
spec:
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 8080

Adding targetPort to the VirtualRouter would allow users map ports defined in the VirtualNode:

kind: VirtualRouter
spec:
  listeners:
  - portMapping:
      port: 80
      protocol: http
      targetPort: 8080
---
kind: VirtualNode
spec:
  listeners:
  - portMapping:
      port: 8080
      protocol: http

My proposal is to add the targetPort field to the VirtualRouter listener in v1beta2 API.

[dastbe]

Hey Stefan,

First, it should not be the case that you need to align Virtual Router and Virtual Node listeners. At a high-level, the configuration at the client Envoy performs the following routing

1. Match the outbound traffic on the Virtual Router Listener
2. Select a route based on the virtualhost, path, and other matchers
3. Select a Virtual Node destination
4. Route to the Virtual Node on its listener port

So I'd be very interesting if you're having issues with this behavior.

Second, I am interested in the notion of a portmapping at the Virtual Node. It seems like this would be useful in the Virtual Service -> Virtual Node scenario, as well as give customers a method of indirection at the node. While I think your initial issue should not be a problem, would this be of interest to you?

[stefanprodan]

Assuming I have a deployment exposing two HTTP ports: 8080, 9090 and a VN with the same listeners. Then I want to map 8080 to 80 and 9090 to 90, so I add 80 and 90 to the VR listeners, how would Envoy know what VN listener port to chose?

[benpettman]

@dastbe I am having an issue with your suggestion in that I have a deployment that is exposed on port 7000 and when every port is set to 7000 everything works fine, but if I alter the VirtualRouter to listen on port 80, it does not route to the VirtualNode correctly, I am simply routing / so matching all traffic.

I get a Connection reset by peer error.

I do think there is value in being able to tell the VR to listen on a port and map to the correct port as @stefanprodan suggests.

[woodsmur]

I am having the same issue with this scenario. Any update for this?