Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
NodePort allocation conflates TCP and UDP #20092
Consider a service like
apiVersion: v1 kind: Service metadata: name: dns spec: selector: … clusterIP: … type: NodePort ports: - name: dns port: 53 nodePort: 30053 protocol: UDP - name: dns-tcp port: 53 nodePort: 30053 protocol: TCP
The API refuses to accept this service, stating
It works fine without
I'm not sure if this is deliberate but not well documented, or a bug? I don't see a reason not to allow a UDP and TCP node port to have the same number.
This was intentionally omitted due to laziness and complexity. We hoped
On Mon, Jan 25, 2016 at 9:00 AM, Matthias Rampke email@example.com
I've also hit this issue (see: https://stackoverflow.com/questions/37449121/how-to-expose-kube-dns-service-for-queries-outside-cluster) when trying to expose DNS to queries from outside the cluster.
Note that in my setup, the "NodePort" is different for UDP and TCP but only UDP appears to work (it's the first to be defined?).
"bug", but yes. We'd need to store parallel bitmaps per protocol. Even
a) fail and reject the REST operation
NodePort was really made for load-balancers, where the port number doesn't
On Thu, Jul 28, 2016 at 9:37 PM, TonyAdo firstname.lastname@example.org wrote:
referenced this issue
Jul 29, 2016
this is what I'd expect. Port exhaustion is not really a temporary
condition (won't resolve unless some other service is deleted).
SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany | +49 173
Managing Director: Alexander Ljung | Incorporated in England & Wales with
This alone is insufficient, but we might get away without storing two maps by simply saying
This will prevent the case of ports being used in one protocol but not the other and failing to allocate.
I haven;t tried too hard to break it, but something like that MIGHT work.