-
Notifications
You must be signed in to change notification settings - Fork 14.8k
docs: improve NodePort collision section with example and reference #51228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
To complement the existing explanation of static and dynamic NodePort bands, add the default range breakdown and a link to a related blog post. This provides users with a clearer understanding and the key information they'd otherwise need to search for separately.
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
We should be wary to link to https://kubernetes.io/blog/2023/05/11/nodeport-dynamic-and-static-allocation/ unless we're going to mark that page evergreen. Otherwise, people will follow the link and see:
|
I see your point, thanks for bringing it up. If you feel it's better to leave the link out, I'm happy to drop it. I just thought it might help reduce the need for readers to search elsewhere. That said, the original documentation does feel a bit abstract, so I think the concrete example could be still helpful for readers. Of course, including specific details always carries the risk of reducing the long-term accuracy if those details change over time (though that seems unlikely in this case). Do you think it would still be reasonable to include the default range example, and perhaps the port range calculation formula, given that trade-off? |
By the way, the code for port range calculation can be found here: https://github.com/kubernetes/kubernetes/blob/089849ac22f4d67ac0a8651d1a8e5fda9d7752e4/pkg/registry/core/service/portallocator/allocator.go#L259-L285 |
When using the default NodePort range 30000-32767, the bands are partitioned as follows: | ||
|
||
- Static band: 30000-30085 | ||
- Dynamic band: 30086-32767 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might actually put this in https://kubernetes.io/docs/reference/networking/virtual-ips/ anbd link there. Maybe also the information about bands.
Not sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume you're referring to placing it near the IP address ranges for Service virtual IP addresses section. That sounds reasonable to me; happy to give it a try and see how it looks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm... it turns out it's a bit tricky to find a good place for this change in Virtual IPs and Service Proxies. As the title suggests, that page appears to focus more on how kube-proxy
handles internal packet distribution using the virtual IP mechanism through iptables, IPVS, or similar components. Personally, I feel this change is slightly off-topic for that page, since it's specific to the NodePort Service type. That said, I don't have a strong opinion.
It might be helpful to get input from other reviewers. Could you take a look, @nate-double-u @shannonxtreme? (Cc @lmktfy)
Description
Changes:
To complement the existing explanation of static and dynamic NodePort bands, add the default range breakdown and a link to the related blog post. This provides users with a clearer understanding and the key information they'd otherwise need to search for separately.
Verified with
make container-serve
.