Exposing TCP/UDP services: Listening should be decoupled from link to service

[juan-vg]

What do you want to happen?

TLDR: TCP/UDP exposing should be allowed to be configured from multiple, different sources and be independent from the controller's global config.

From my point of view the installation and configuration of the ingress controller should be decoupled from the linking to Services. This means there should be a first configuration step (controller global), and then in next steps each application will define a separated config (Ingress resource) where the link between the controller/listener and the Service is made. This is already how HTTP/S is handled, but for TCP/UDP exposing it must be done through a Configmap —which is set at a controller global scope— where is mandatory to link the TCP/UDP port to the target NameSpace and Service.

On the one hand, this way of exposing TCP/UDP services makes it mandatory to know at a Infra/Ops level the NameSpaces and Services that could exist in the future, where —however— this should be addressed by each application (same as Ingress resources for HTTP/S) when both values are already known.

On the other hand, if many applications want to expose TCP/UDP services, they should not need to be aware of other applications' exposures. This could lead to overwrites or to a logic which definitely should not belong to the application scope.

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[juan-vg]

I was reading the docs again and I understood them in another way that made me think I was wrong, but I believe now what I mention is true and it could be addressed in a better way.

[github-actions[bot]]

This is stale, but we won't close it automatically, just bare in mind the maintainers may be busy with other tasks and will reach your issue ASAP. If you have any question or request to prioritize this, please reach #ingress-nginx-dev on Kubernetes Slack.

[LarsStegman]

This is exactly my thoughts. Applications/deployments should specify what port they need to be open and nginx should take care of it (if the port is not already claimed)

[juan-vg]

@strongjz could you please review the status of the task associated to this PR? I'm afraid I messed something when I closed and reopen the PR

[rikatz]

The maintainers have decided that ingress nginx will become more focused on the l7/http offer (which is the origin of ingress API) and not evolve any tcp/udp feature. In fact, we may decide in short to mid term to deprecate and remove it.

This way, I am closing the issue. Thanks

/close

[k8s-ci-robot]

@rikatz: Closing this issue.

In response to this:

The maintainers have decided that ingress nginx will become more focused on the l7/http offer (which is the origin of ingress API) and not evolve any tcp/udp feature. In fact, we may decide in short to mid term to deprecate and remove it.

This way, I am closing the issue. Thanks

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[LarsStegman]

In fact, we may decide in short to mid term to deprecate and remove it.

oh, that's good to know, then we'll start preparation to move to Traefik. Thanks for letting me know!