Support an arbitrary number of Listeners per Gateway

[Rycieos]

This is an enhancement request, but it could also be considered a bug, as the Kubernetes Gateway API requires this support.

Description

A single Gateway object needs to be able to support an arbitrary number of Listeners, including multiple Listeners of the same type.

User story

I have an application that speaks both HTTP as well as a nonstandard protocol over TCP to the backend servers. I also want all traffic wrapped in TLS. To greatly simplify environment creation, I want all HTTPS and TCP traffic to be handled on the same FQDN, meaning the same IP address, meaning the same Gateway object. Since the HTTPS and TLS wrapped TCP traffic do not differ in FQDN, it is not possible to have them on the same port.

This can be specified with this example Gateway Spec:

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
spec:
  listeners:
  - allowedRoutes:
      kinds:
      - group: gateway.networking.k8s.io
        kind: HTTPRoute
    name: https
    port: 443
    protocol: HTTPS
  - allowedRoutes:
      kinds:
      - group: gateway.networking.k8s.io
        kind: TLSRoute
    name: tls
    port: 5000
    protocol: TLS

While currently I do not need multiple listeners of the same type on different ports, it should also be possible to do that as well.

Issue

Currently, if this Gateway is created, Contour returns an error with the message:

contour/internal/gatewayapi/listeners.go

Line 128 in d7d4012

Message: "Only one HTTPS/TLS port is supported",

[github-actions]

Hey @Rycieos! Thanks for opening your first issue. We appreciate your contribution and welcome you to our community! We are glad to have you here and to have your input on Contour. You can also join us on our mailing list and in our channel in the Kubernetes Slack Workspace

[skriss]

xref #3616
xref kubernetes-sigs/gateway-api#1607

[skriss]

@Rycieos FYI I am going to start looking into this to see how we'd implement it. We agree that ultimately, not supporting this use case means we are not Gateway API conformant so we'd like to address it.

[skriss]

A few things that need to be sorted out here:

• how to map arbitrary Gateway Listener port numbers to port numbers that Envoy listens on inside the container (external Listener port numbers could be e.g. 81, 5081, 32081)
• how does this interact with Ingress/HTTPProxy resources, which currently assume just 2 ports, HTTP and HTTPS? The easiest option is to say they are incompatible, at least for now (could set a condition on HTTPProxies if Contour is configured for an incompatible Gateway)

[Sajiyah-Salat]

Hello @skriss can I work on this issue?

[skriss]

Hello @skriss can I work on this issue?

@Sajiyah-Salat I'm already working on a design for this issue, plus it's probably not a great first issue anyway since it's fairly intricate. I'd suggest looking at the good first issue or help wanted labels to find a good issue to start with. You could also look at the Gateway API label if you're specifically interested in that area. Thanks for your interest in the project!

[skriss]

@Rycieos if you're interested in trying out an early dev build, I have a branch that seems to be basically working:

• branch: https://github.com/skriss/contour/tree/pr-multiple-gateway-listeners
• image: docker.io/steveheptio/contour:many-listeners@sha256:d8b4a18df2b2c27b9c8252f29aa2e701b00f2028fc2fbfb89da52cec94b08bc7

Assuming you are using the gateway provisioner, you'd need to change the image used in the provisioner deployment itself, plus add the --contour-image=docker.io/steveheptio/contour:many-listeners flag to its args.

If you're not using the gateway provisioner, let me know, as some other changes will need to be made to the envoy service ports.

Please note that this is just a dev build and may have bugs or limitations, but the basic functionality worked properly in my testing.