-
Notifications
You must be signed in to change notification settings - Fork 1.4k
📖 docs: Consolidate MachinePool documentation #12810
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
[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 |
Hi @bnallapeta. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
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 looks great! Just a few small comments.
|
||
### Use MachinePool when: | ||
|
||
- **Cloud provider supports scaling group primitives**: AWS Auto Scaling Groups, Azure Virtual Machine Scale Sets, GCP Managed Instance Groups. These resources natively handle scaling, rolling upgrades, and health checks. |
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.
Should we perhaps mention OCI and Scaleway, the other two providers who support MachinePools? Also GCP isn't yet implemented so perhaps we shouldn't be listing it.
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.
GCP does have MachinePool references. And docs refer GCPManagedMachinePool. Can you help clarify?
Added the other two here and in the "What is a MachinePool" section too.
/ok-to-test |
Signed-off-by: Bharath Nallapeta <[email protected]>
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
LGTM label has been added. Git tree hash: 04b34f16639523228b8b1b97160d41f7e1127d10
|
Let me know once this ready for a final pass from my side (not sure who else might want to review this before merge) |
It is ready. PTAL. |
|
||
- **Cloud provider supports scaling group primitives**: AWS Auto Scaling Groups, Azure Virtual Machine Scale Sets, GCP Managed Instance Groups, OCI Compute Instances, Scaleway Kapsule. These resources natively handle scaling, rolling upgrades, and health checks. | ||
- **You want to leverage cloud provider-level features**: MachinePool enables direct use of cloud-native upgrade strategies (e.g., surge, maxUnavailable) and autoscaling behaviors. | ||
- **You are operating medium-to-large node groups**: Managing 50+ nodes through individual Machine objects can add significant reconciliation overhead. MachinePool reduces this by consolidating the group into a single object. |
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.
Q: Is this still correct?
With Machine Pool Machines, the load for core CAPI controller seems the same
Also there are features in CAPI designed to work at node level like MHC and reconciliation of providerID (so reconciliation overhead is the same also 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.
Also, there Cluster API users managing huge clusters (a few thousand of workers) with machine deployments, so I don't think that the size of node groups should be a differentiator
(same for "use MachineDeployment when")
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 would suggest to merge this page in https://cluster-api.sigs.k8s.io/tasks/experimental-features/machine-pools instead of spreading knowledge relevant for the users in multiple places.
If this page becomes too complex/hard to read, let's create sub pages like we did for cluster class and runtime SDK
What this PR does / why we need it:
This PR consolidates and improves the MachinePool documentation structure to eliminate redundancy and create a better user experience.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #12794
concepts/machinepool.md
to the book navigation/area documentation