-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Note regarding mega nodes #3823
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: master
Are you sure you want to change the base?
Changes from 8 commits
f674d89
3c78d32
b2695da
d1c364b
a0a20a2
def366e
e190af3
f78fcf2
8a99c3d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
|
|
@@ -297,7 +297,17 @@ Regarding CPU and memory, it is recommended that the different planes of Kuberne | |||||
|
|
||||||
| ### Large Kubernetes Clusters | ||||||
|
|
||||||
| For hardware recommendations for large Kubernetes clusters, refer to the official Kubernetes documentation on [building large clusters](https://kubernetes.io/docs/setup/best-practices/cluster-large/). | ||||||
| Kubernetes is engineered around the concept of horizontal scaling for redundancy, so scaling vertically with large servers can be problematic if the proper minimum/maximum requirements aren’t followed. The following are tips and recommendations for large Kubernetes clusters: | ||||||
|
|
||||||
| - If you must use servers larger than 24 CPU, use virtualization tooling, such as what [Harvester](https://docs.harvesterhci.io/v1.0/rancher/virtualization-management/) provides, to subdivide the servers. | ||||||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Where did that 24 CPU number come from ? |
||||||
|
|
||||||
| - Kubernetes, kernel, and network limitations prevent having too many pods per server. You should maintain a minimum of roughly 24 cores per server and a maximum of the recommended 110 pods per server. | ||||||
|
||||||
| - Kubernetes, kernel, and network limitations prevent having too many pods per server. You should maintain a minimum of roughly 24 cores per server and a maximum of the recommended 110 pods per server. | |
| - Kubernetes, kernel, and network limitations prevent having too many pods per server. You should maintain a maximum of roughly 24 cores per server and a maximum of the recommended 110 pods per server. |
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.
@Tejeev, checking that minimum should be maximum here?
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.
yes, though these are somewhat softer than I think I make it sound. Folks that know what they are doing may up the pod count to the real limit of 251 (IIRC. we should double check that) and there are use cases that might use more cores, per pod, though at the moment they are rare. Not sure how to convey this a bit better or if we leave it as is to prevent over committing by folks that do not have real need of increased limits
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.
Perhaps:
"It is recommended to maintain a maximum of roughly 24 cores and 110 pods per server"
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 goes against upstream docs best practice: "No more than 110 pods per node": https://kubernetes.io/docs/setup/best-practices/cluster-large/
Also saying "you may increase the pod limi" implies that this is supported, and we have not tested this in our scaling tests, we do not want to give this impression.
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.
Is there a reason we put this in the rke docs ? Wouldn't this apply to any large cluster, including rke2.
We need to make a scaling section, but for now most of that data lives over here: https://rancher.com/docs/rancher/v2.5/en/installation/requirements/