-
Notifications
You must be signed in to change notification settings - Fork 14.3k
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
Clarify cluster diagram as one possible reference architecture #47164
Clarify cluster diagram as one possible reference architecture #47164
Conversation
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
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 think this is a great addition. thanks
/lgtm
but not sure if the formatting / indentation is correct.
/assign @tengqm
as per your comment on
#47111 (comment)
/sig architecture
LGTM label has been added. Git tree hash: 15436ba45b96f9a92facd68bf7d93143c71de60b
|
Thank you for the swift review, @neolit123! I appreciate your feedback on the formatting and indentation. If you're aware of any similar pages with correct formatting, or if you have any specific suggestions for improvement, I'd be grateful for your guidance. |
would leave the formatting correctness to the docs team. |
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.
Thanks
I think if we merged this we'd immediately want to file an issue calling for more changes. You can revise this PR so that it can merge without needing that issue.
Here's some specific feedback.
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
Co-authored-by: Tim Bannister <tim@scalefactory.com>
The latest commit includes the following changes:
I'd love any feedback on the overall organization of the content or suggestions on how I can improve the content I added |
5deae5d
to
a8edb2d
Compare
Latest commit adds some small points of optimization to make the pages mesh more coherently and make the overview more of an overview. |
/lgtm |
@network-charles: changing LGTM is restricted to collaborators In response to this:
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. |
The proposed change mentions following under |
Always. The control plane does not include the kubelet and kube-proxy; see https://kubernetes.io/docs/concepts/overview/components/ You might run the control plane on a computer (or several) computers that are running kubelet, and possibly also running kube-proxy; however, the control plane is still:
|
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.
/lgtm
Here's some feedback to make this even better.
LGTM label has been added. Git tree hash: 60b2326103ed6daed7b3bf5b978c2346b78f68d2
|
Improves clarity and consistency with existing documentation Co-authored-by: Tim Bannister <tim@scalefactory.com>
@sftim I've added a follow up commit to fix some remaining issues and improve consistency. I am a little confused what the third-party notice is targeting so perhaps my placement is worth double checking. Thanks for the feedback! |
@sftim : That's much clearer. Thanks. However, if that's the case then shouldn't the revised doc mention: |
“never“ feels correct to me @GarbageYard You could think of an electrical generating station. Maybe there is a generator set specifically for the control room (a good idea for resilience), and that generator may be able to supply the plant or even the power network. In that analogy, you could be more specific about why there is a generator in a strange place on the plant diagram. In a Kubernetes cluster, if you run the control plane on nodes, you can explain why some servers are nodes and have both a kubelet and control plane components on them. |
Co-authored-by: Tim Bannister <tim@scalefactory.com>
/lgtm |
LGTM label has been added. Git tree hash: d2242616513ea8c876c871323493fa1268bd86aa
|
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.
This is a really good addition @robert-cronin, thanks so much for writing it up!
(and thanks to all the reviewers too)
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: nate-double-u 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 |
Thank you so much, @nate-double-u, and thanks to all the commenters and reviewers! 😊 |
This PR addresses the concerns raised in issue #47111 regarding the potential misunderstanding of component distribution in Kubernetes clusters, particularly the presence of kubelet and kube-proxy on control plane nodes.
Before
After
I'm not entirely sure how much additional detail is appropriate for this introductory page on cluster architecture. I'm open to removing certain details for brevity if needed. Feedback on the level of detail and which points are most crucial to keep would be greatly appreciated. Also if there is anything I have gotten wrong about cluster architecture, please feel free to correct me.