-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
Migrate reference details out Service concept #36675
Migrate reference details out Service concept #36675
Conversation
Helps with #14770 |
/label refactor |
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site settings. |
[supported protocol](#protocol-support). | ||
The default protocol for Services is | ||
[TCP](/docs/reference/networking/service-protocols/#protocol-tcp); you can also | ||
use any other [supported protocol](/docs/reference/networking/service-protocols/). |
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.
nit: protocols?
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.
For this PR, I was aiming to retain the original text. Subsequent PRs could tidy that up.
If some of my other PRs merge, I can shrink #30817 until it reaches a reviewable size. That PR includes more fixes than just the reorganisation that this PR covers.
NAT for multihomed SCTP associations requires special logic in the corresponding kernel modules. | ||
|
||
{{< note >}} | ||
The kube-proxy does not support the management of SCTP associations when it is in userspace mode. |
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.
You may want to make 'kube-proxy' a link or a glossary.
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.
For this PR, I was aiming to retain the original text. Subsequent PRs could tidy that up.
If some of my other PRs merge, I can shrink #30817 until it reaches a reviewable size. That PR includes more fixes than just the reorganisation that this PR covers.
|
||
### `TCP` {#protocol-tcp} | ||
|
||
You can use TCP for any kind of Service, and it's the default network protocol. |
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.
You can use TCP for any kind of Service, and it's the default network protocol. | |
You can use TCP for any kind of Service, and it's the default service protocol. |
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.
For this PR, I was aiming to retain the original text. Subsequent PRs could tidy that up.
If some of my other PRs merge, I can shrink #30817 until it reaches a reviewable size. That PR includes more fixes than just the reorganisation that this PR covers.
IP address, for example 10.0.0.1. Assuming the Service port is 1234, the | ||
Service is observed by all of the kube-proxy instances in the cluster. | ||
When a proxy sees a new Service, it opens a new random port, establishes an | ||
iptables redirect from the virtual IP address to this new port, and starts accepting |
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.
iptables redirect from the virtual IP address to this new port, and starts accepting | |
iptables rule that redirects from the virtual IP address to this new port, and starts accepting |
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.
For this PR, I was aiming to retain the original text. Subsequent PRs could tidy that up.
If some of my other PRs merge, I can shrink #30817 until it reaches a reviewable size. That PR includes more fixes than just the reorganisation that this PR covers.
e10f4b5
to
3f4822e
Compare
6f19b1a
to
f202b42
Compare
f202b42
to
f0ce483
Compare
f0ce483
to
07a52d0
Compare
07a52d0
to
1bc7b2b
Compare
f7a2c34
to
28f170b
Compare
cf98610
to
b581bd4
Compare
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.
Just a single non-blocking nit from my side. Since this is a refactor PR, I'd like another pair of eyes to review it too! But thanks for the effort, Tim :)
@@ -666,6 +490,12 @@ Kubernetes `ServiceTypes` allow you to specify what kind of Service you want. | |||
to use the `ExternalName` type. | |||
{{< /note >}} | |||
|
|||
The `type` field was designed as nested functionality - each level adds to the |
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.
non-blocking nit
The `type` field was designed as nested functionality - each level adds to the | |
The `type` field was designed as a nested functionality - each level adds to the |
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've kept that wording from the original AFAIK. We could do a tiny later PR to add that word if we want to.
As long as we intend to fix the nits over a separate PR, I'm LGTMing this change from my side. |
LGTM label has been added. Git tree hash: 9b01179d2d260c80de39dd0df40e689b10fedfb9
|
It's not easy to find where the text has moved to. Locally, you can use a tool like You'll get better results if you set |
@sftim Is there an issue already for the revisions as suggested by Qiming? I ask so as not to lose the spirit of wanting to keep current text as is for this refactor, while still committing to improving it after release deadlines are met. |
We changed our review guidelines since I started on this and we now suggest that errors that the PR didn't introduce are OK to leave. I am willing to file issues, although if I do that now and we merge, those will be issues against the wrong page. |
Thanks, Tim 🤝 |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: natalisucks The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
THIS IS REALLY A BAD EXAMPLE TO THE WHOLE COMMUNITY. IT IS A MIXTURE OF REFACTOR AND REWRITING. IT IS TOO HUGE TO REVIEW. IT CONTAINS MANY DEFECTS THAT WERE IDENTIFIED BUT NOT FIXED. THE AUTHOR PROMISED TO FIX THEM IN FOLLOW-UP PRS BUT NO ISSUES ARE FILED, IN OTHER WORDS, THE BALLS NOW FELL TO THE GROUND. A GOOD PRACTICE SHOULD BE KEPT COMMUNITY WIDE, ABIDE BY ALL MEMBERS. THIS ONE IS AN EXCEPTION. IT INTRODUCED A NEW PROTOCOL: IF ONE'S PR IS NOT THOROUGHLY REVIEWED AND THE AUTHOR WANTS IT TO BE MERGED, WITH SUFFICIENT PRIVILEGE, THE AUTHOR CAN CHANGE THE REVIEW GUIDELINES. I AM FEELING VERY UPSET BY THIS. |
@tengqm Hi Qiming, I see that you've raised this concern in the #sig-docs-maintainers channel, so I'd like us to continue having the discussion there – I have linked the thread for visibility so that other folks involved in this PR, and the wider community, can follow along. I agree overall with your point about setting good examples for the community, which is why I'd love us to continue discussions in a respectful way – pushing your point in all caps seems counterintuitive to this. I would also like to unpack your feeling of the author having privilege, and try and get us to a point where you, as a fellow tech lead, would feel equally empowered amongst your co-chair and tech lead peers. In following my own advice, I'll post comments in the above-linked thread so that we can discuss this more and get us to a point where every contributor and lead feels empowered to contribute changes, but more importantly, to bring up dissent and healthy disagreements for the betterment of pushing good practice. |
@natalisucks This PR is huge and very difficult to review. There were quite some issues raised during the past reviews and the author refused to fix. One of the arguments is that this is a refactor PR. No. If you have reviewed the change, it is NOT a refactor, it is introducing a lot of new texts that are misleading or inaccurate. Another argument is that while introducing new text, this PR is not fixing any existing text. Why is that? We don't have such a criteria for approving PRs. The solution, well, was to change the rule. Is that an acceptable practice that shows respects to reviewers? Even when we merged the PR, it still had 6 commits, more than 800 lines of text changed. Every single change to the Service topic needs some discussions. For example, is application protocol tied to load-balancer type of Services? Is the removal of some texts well justified? Are we introducing many dangling dead links to the Service concept? Since this change involves many new texts, don't we need some tech reviews from the relevant SIGs, especially sig-network? I'd not be so dismayed if the PR is a simple refactoring. A huge change to one of the core concept needs more eyes. To make sure we are really improving the docs, we could have split this PR into 10+ smaller ones. We are not supposed to merge this prematurely. |
Split out from #30817
Previews:
Migrate away:
Edit: this PR helps us to document the removal of userspace kube-proxy, by giving a new better home for the kube-proxy docs.
/sig network