### What happened?

I'm looking at various ways to expose a service directly from a set of hosts in a k8s cluster. [Yes, I know about the caveats here, but this is a service that doesn't play like a traditional http/rest endpoint.]

I can do this with a svc that has a `port` setting and a list of `spec.externalIPs` - however, I need to maintain that list of externalIPs manually (or write a small oeprator that does so).

Since these externalIPs tend to turn into individual iptbles rules (or the moral equivalent, depending on your networking stack), it's surprising that I can't give a CIDR here. That would (a) cut down on the number of IPtables rules that need evaluating, (b) require no dynamic updates.


### What did you expect to happen?

I'd like to be able to say

`spec.externalIPs: ["169.254.0.0/16"]`

and not have to maintain the set of IPs on the svc through some external reconciliation.

### How can we reproduce it (as minimally and precisely as possible)?

As above - this is a limitation currently in the validation of externalIPs rules.

### Anything else we need to know?

This is related to a slew of questions people ask about exposing NodePorts on low ports. There are legitimate reasons to want to do this (again, largely around services that don't behave like a cloudy rest service, but those definitely exist), but there's always been a reasonable degree of pushback from supporting this - also for legitimate reasons.

### Kubernetes version

all current


### Cloud provider

n/a


### OS version

n/a

### Install tools

n/a


### Container runtime (CRI) and version (if applicable)

n/a

### Related plugins (CNI, CSI, ...) and versions (if applicable)

n/a
service.spec.externalIPs is unnecessarily limited (enhancement request)
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : service.spec.externalIPs is unnecessarily limited (enhancement request)
Issue date:

--- start body ---
### What happened?

I'm looking at various ways to expose a service directly from a set of hosts in a k8s cluster. [Yes, I know about the caveats here, but this is a service that doesn't play like a traditional http/rest endpoint.]

I can do this with a svc that has a `port` setting and a list of `spec.externalIPs` - however, I need to maintain that list of externalIPs manually (or write a small oeprator that does so).

Since these externalIPs tend to turn into individual iptbles rules (or the moral equivalent, depending on your networking stack), it's surprising that I can't give a CIDR here. That would (a) cut down on the number of IPtables rules that need evaluating, (b) require no dynamic updates.


### What did you expect to happen?

I'd like to be able to say

`spec.externalIPs: ["169.254.0.0/16"]`

and not have to maintain the set of IPs on the svc through some external reconciliation.

### How can we reproduce it (as minimally and precisely as possible)?

As above - this is a limitation currently in the validation of externalIPs rules.

### Anything else we need to know?

This is related to a slew of questions people ask about exposing NodePorts on low ports. There are legitimate reasons to want to do this (again, largely around services that don't behave like a cloudy rest service, but those definitely exist), but there's always been a reasonable degree of pushback from supporting this - also for legitimate reasons.

### Kubernetes version

all current


### Cloud provider

n/a


### OS version

n/a

### Install tools

n/a


### Container runtime (CRI) and version (if applicable)

n/a

### Related plugins (CNI, CSI, ...) and versions (if applicable)

n/a
--- end body ---
