[kubernetes gateway-api] Resolve gateway api listener ports to real ports instead of internal ones

[cwrau]

Welcome!

• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What did you expect to see?

Currently, when one wants to create a gateway with the default config from the helm chart (websecure internally 8443 but in reality 443), one needs to configure the listener port to be 8443, which is semi-incorrect but at least unintuitive, as in every way that matters to the user it's really 443.

It would be great if one could configure some kind of realPort: 443, or some kind of alias, ... to make this more user friendly.

[nmengin]

Hey @cwrau,

Thank you for reaching out.
From what I understand, you would like an option in the Helm chart to open port 443?

[cwrau]

Hey @cwrau,

Thank you for reaching out. From what I understand, you would like an option in the Helm chart to open port 443?

Not directly, it's perfect that traefik doesn't use ports <1000 by default and I wouldn't want that anyways.

I'd like to have some sort of mapping between the "physical" port traefik opens (8443) and the "real" port in the LoadBalancer (443).

Essentially currently one needs to write a gateway this way;

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  listeners:
  - name: https
    protocol: HTTPS
    port: 8443 <-

while the user actually would like to, and intuitively would, write the following;

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  listeners:
  - name: https
    protocol: HTTPS
    port: 443 <-

Also, because 8443 is kind of an implementation detail, I'd like to hide this from the users

[nmengin]

Hello @cwrau,

Thank you for the additional information.

Discussing it with other maintainers, we do not think that such an internal mapping is a best practice.
On top of that, we have seen nothing in the GatewayAPI specification arguing that a Gateway Controller should provide such behavior.

For these reasons, we prefer to close the issue.

[cwrau]

• Discussing it with other maintainers, we do not think that such an internal mapping is a best practice.

• On top of that, we have seen nothing in the GatewayAPI specification arguing that a Gateway Controller should provide such behavior.

I understand both arguments, but just because there is no best practice and the spec doesn't force you to do this well, doesn't mean you can't do it.

Also, what does "best practice" mean? I've installed other Gateway API implementations, and they all do it this way;

• Contour uses port 80 on the gateway while having port 8080 on the pod.
• Easegress also does some mapping, while their example shows 8080 on the gateway+service and 30080 on the pod, this is easily changed to just have port 80 on the gateway+service and still have 30080 on the pod.
• Envoy gateway has port 80 on the gateway, but uses port 10080 on the pod.
• Gloo also does 80 -> 8080
• haproxy also does 80 -> 8080

That's just going down the list of GA implementations from https://gateway-api.sigs.k8s.io/implementations/#gateway-controller-implementation-status, so it does seem to be best practice to map the port for the user.

[nmengin]

Hey @cwrau,

Thank you for your feedback and for pointing the additional information.

I re-open the issue to let us (maintainers) to dig deeper.