@pavolloffay There are no sig labels on this issue. Please add a sig label by:
(1) mentioning a sig: @kubernetes/sig-<team-name>-misc
(2) specifying the label manually: /sig <label>

Note: method (1) will trigger a notification to the team. You can find the team list here and label list here

@kubernetes/sig-network @kubernetes/sig-node

/sig network

/assign

@pavolloffay UDP is supported in services. Are you looking for a kubectl port-forward command?

@cmluciano yes kubectl port-forward pod-name udp-port

@cmluciano do you have any news on this? Is it in the roadmap or I was doing something wrong?

@kubernetes/sig-apps-feature-requests

/remove-sig network

/area kubectl

@cmluciano why is this labeled for sig-apps? I thought port-forwarding is under the purview of network and node sigs, and the fact that there are kubectl changes that need to be made may include cli?

/remove-sig apps
/sig cli

That is true @Kargakis . I keep forgetting that sig/cli is a thing.

cc @kubernetes/sig-cli-feature-requests

/assign
I will take a look.

Is there any progress on this? cc @shiywang

@pavolloffay working on it right now

cc @freehan you may be interested.

Any updates @pavolloffay ? I just needed this as well.

/triage accepted
/priority important-longterm

Hi all! I have created a kubectl plugin krelay to support forwarding UDP port, you could install it by krew: kubectl krew install relay. In addition krelay could forward data to a IP or hostname as well.

Please feel free to give it a try. I am looking forward to your feedback!

Also can't wait for this to be implemented. Any updates on the progress being made?

Do we have any update on this?

+1

Hi everyone,
Is there any plan to add UDP support to port forwarding ?

Thanks.

+1

Hi,

I hope we found a workaround for fix that.

Best Regards

/assign

hi all,

although kubernetes does not currently have native support for this feature, I have created this project to connect to services using UDP and manage multiple services through a Tray application. The project is open source : kftray

i hope that in the future, Kubernetes API will address this issue, eliminating the need for a relay server to handle UDP traffic redirection.

Hey @seans3 I know this has been in the backlog for quite some time, but is there any plan to implement this in the coming few months?

It would be a really valuable feature to have natively

Note that Http3 is based on Quic which is (on top of) UDP. Testing quic services requires port-forwarding UDP.

Hey @seans3! I see that this was assigned to you; would you be able to provide any meaningful updates on an expected timeline? For a seven-year issue on something so fundamental to OSI layer 3, I feel that the community deserves a bit more communication on this - if the number of +1 comments attempting to revive the issue are any indication. Additionally, @jvilhuber's comment necessitates additional reconsiderations towards urgency, especially given this long-lived context.

To the point I raised nearly four years ago: some protocols leverage UDP by default, and others leverage UDP exclusively. The spread of k8s usage in these use-cases is hindered, if not completely absent, and out-of-band solutions have since been developed as a result. It's "okay" that there are alternative solutions, but something so crucial to such a pervasive networking orchestration solution as kubernetes would be expected by many to exist by default.

I hope I'm not talking to thin air, but we could really use an internal champion for this effort.

I agree with the above. This has been a long-standing fundamental issue with Kubernetes. It's something like having an automobile that simply will not drive on asphalt paved roads, only concrete.
I understand that UDP is pretty annoying to deal with on a low level, but I feel the use cases for UDP in k8s are so wide-ranging that it warrants some attention to say the least.

Please do this!

I need this feature

Like so many other issues - help is welcome. We have orders of magnitude more things that people "need" than we have capacity to deliver them. If you are too busy to help, then please consider that other people, such as the wonderful @seans3, might also be busy with urgent things.

GitHub added emojis so that you can express your "me too" without sending a notification out to hundreds of people's mailboxes. Please use those.

I've cleared all the assignee(s) for now until we have some volunteers who can help.