Support port ranges or whole IPs in services

There are several applications like SIP apps or RTP which needs a lot of ports to run multiple calls or media streams. Currently there is no way to allow a range in ports in spec. So essentially I have to do this:

          - name: sip-udp5060
            containerPort: 5060
            protocol: UDP
          - name: sip-udp5061
            containerPort: 5061
            protocol: UDP

Doing above for 500 ports is not pretty. Can we have a way to allow port ranges like 5060-5160?

Fyi you don't actually need to specify a port in the RC unless you're going to target it through a Service, but I guess this is a pain to do if you have even O(10) ports. I wonder if there's an easy client side solution that doesn't involve changing the Service (something like kubectl expose --port 3000-3020).

The problem with port ranges is that the userspace kube-proxy can't handle
them, and that is still the fallback path. Until/unless we can totally EOL
that, we're rather limited.

Aside from that, I don't immediately see a reason against port ranges.

On Tue, Apr 5, 2016 at 5:55 PM, Prashanth B [email protected]
wrote:

Fyi you don't actually need to specify a port in the RC unless you're
going to target it through a Service, but I guess this is a pain to do if
you have even O(10) ports. I wonder if there's an easy client side solution
that doesn't involve changing the Service (kubectl expose --ports
3000-3001).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#23864 (comment)

I do need to target the ports through a Service since that is the only way outside users would be able to place a call via SIP

The short story is it doesn't work right now. Changing it is not
impossible, but we would need to define what happens when the external LB
and/or kube-proxy doesn't support ranges. It's not on the roadmap, though,
so it would either have to be contributed or escalated.

On Tue, Apr 5, 2016 at 9:01 PM, Aditya Patawari [email protected]
wrote:

I do need to target the ports through a Service since that is the only way
outside users would be able to place a call via SIP

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#23864 (comment)

I'm starting to work in this issue. I will try to implement just the logic in kubctl package to map the port ranges to ports which seems a easy and useful workaround. Later I will check the LB and/or kube-proxy option.

golang and kubernetes are new for me so any help, ideas or guidance will be welcomed.

@antonmry

@antonmry What API changes are you looking to do to support this? I glanced at your dev branch and it looks like there's a lot more copy-paste going on than I'd expect. I think I can save you effort if you talk out your desired changes here first.

@antonmry

@antonmry Please see:
https://github.com/kubernetes/kubernetes/tree/master/docs/devel/README.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md
https://github.com/kubernetes/kubernetes/blob/master/docs/api.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api-conventions.md
https://github.com/kubernetes/kubernetes/blob/master/docs/devel/api_changes.md

In general, if you're new to Kubernetes, an API change is not a good place to start. If you're looking for a way to contribute, please checkout issues labeled "help-wanted":
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Ahelp-wanted

It was also stated above that we are not ready to accept this change.

This change, should we decide to do it, doesn't warrant a new API. It's just some field changes to Services and maybe Pods. The right place to start is with a proposal doc that details the change, the API compatibility concerns, the load-balancer implementation concerns, etc.

@bgrant0607

@bgrant0607 @antonmry needs this change to make TeleStax (an RTC framework) work well in Kubernetes, so this isn't a "for fun" request, but rather one that's needed to support their application well.

I agree w/ @lavalamp and @thockin that there are simpler designs, and that a lightweight design proposal is the right way to get to agreement on design quickly.

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

Confirm that this issue is still relevant with /triage accepted (org members only)
Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

I am tempted to close this; it's been open for a decade and there has been no progress. Clearly this issue is not actually helping anyone.

From kubernetes/enhancements#6220:

We need someone to draw up a complete end-to-end picture of what they think "SIP/RTP in Kubernetes" should look like, how the servers are deployed and configured, how packets get routed from client to server and back, etc. And for each part of that that requires some new feature that doesn't exist today, explain why the features that exist today wouldn't work, and why the proposed feature seems like the right fix. And then we need other people to say "yes, I want to deploy clusters like that as well", or else "no, that won't work in my environment, I need this part to work like this..." etc.

/close

@bowei

@bowei: Closing this issue.

Details

In response to this:

/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.

Well that is a shame. I'm rather depended on this feature as the current workaround for scripts creating huge files is a pain. But unfortunately I do not have the experience to help the implementation along...

I also think it would help people with specific needs such as SIP. The issues should be solvable with Multus and KubeVirt. But that kind of misses the point of Kubernetes. I suspect the reason it stayed open for this long is there was always an emergent solution at hand, so I suspect potential contributors never pitched in. Obviously if the problem was of high enough value, we’d have had multiple competing solutions in that period, regardless of messaging. Sent from my iPhoneOn Jul 16, 2026, at 12:57, Jori Huisman ***@***.***> wrote:SixFive7 left a comment (kubernetes/kubernetes#23864) Well that is a shame. I'm rather depended on this feature as the current workaround for scripts creating huge files is a pain. But unfortunately I do not have the experience to help the implementation along... —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

I suspect the reason it stayed open for this long is there was always an emergent solution at hand

And I think that's also why every attempt to do anything with this failed: everyone coming here already had a hacky solution for 80% of the problem, and they imagined that this issue would solve the remaining 20% for them. But everybody had a different hacky 80% solution, and so they were all imagining a slightly different remaining 20%. (That showed up in the earlier KEP attempt, where there were some people who assumed that "port ranges in Services" also implied "port ranges in LoadBalancers", while other people assumed that the feature would only be used with ClusterIPs, and others only cared about hostNetwork pods...)

And SIG Network doesn't want to add a feature that is only useful as the last 20% of a hacky solution anyway. We want to provide the 100% doesn't-need-any-hacks solution (and are still open to doing so, if people want to come up with that solution!)

there was always an emergent solution at hand.

Unfortunately, at least a couple of times in projects I've been involved in, the emergent solution was not the 80% hack, but rather not to do it in k8s (FTP,SIP). Once that decision is made, it becomes harder to contribute back because there is nothing to increment from.

The remaining 20% is very hard to achieve because the requirements to make FTP work are not the same as SIP or other multi-connection protocols, in terms of load balancing, session affinity, etc. The port range is just the common part of issues with all these protocols.

I understand the close probably just means there isn't a consensus on the solution, but I just wanted to add my two cents that there is still interest in the solution by people like me who are/were in silence because they do not have the expertise in all those domains/protocols simultaneously to tackle this.

We closed it because after 10 years it hasn't been important enough to anyone to solve, but we have to re-triage it over and over. If someone wants to work on it, it can be reopened.

@thockin

@thockin that's not quite true. It has been addressed within multiple CNIs. It's just more of a hacky workaround than a true fix...

Navigation Menu

Repository navigation

Support port ranges or whole IPs in services #23864

229 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support port ranges or whole IPs in services #23864

Description

Activity

bprashanth commented on Apr 6, 2016

thockin commented on Apr 6, 2016

adimania commented on Apr 6, 2016

thockin commented on Apr 6, 2016

antonmry commented on May 8, 2016

lavalamp commented on May 16, 2016

bgrant0607 commented on May 16, 2016

thockin commented on May 16, 2016

brendandburns commented on May 16, 2016

229 remaining items

k8s-triage-robot commented on Jul 4, 2026

danwinship commented on Jul 16, 2026

bowei commented on Jul 16, 2026

kubernetes-prow commented on Jul 16, 2026

SixFive7 commented on Jul 16, 2026

briantopping commented on Jul 16, 2026

danwinship commented on Jul 16, 2026

rafasc commented on Jul 16, 2026

thockin commented on Jul 16, 2026

agowa commented on Sep 25, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions