-
Notifications
You must be signed in to change notification settings - Fork 1.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
📖 Add control plane machine count 1 warning #7707
Conversation
Signed-off-by: David Tesar <[email protected]>
Welcome @dtzar! |
Hi @dtzar. 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/test-infra repository. |
[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 |
/ok-to-test |
|
||
<h1> Warning! </h1> | ||
|
||
** `--controlplane-machine-count` today allows a value of 1 which is [not recommended for production](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#single-node-etcd-cluster) and in the future [being considered to not be supported with clusterctl code](https://github.com/kubernetes-sigs/cluster-api/issues/3425). Instead it is recommended to [specify a value of 5](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#multi-node-etcd-cluster) or only utilize a control plane from a provider. |
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 for taking an interest in this @dtzar! However, having a controlplane-machine-count
of 1 isn't the same as what's outlined in #3425 - that's about dropping support for standalone control-plane machines i.e. those not managed by a control plane provider.
There's an ongoing conversation about dropping support for this in 1.4 though. @dtzar it would be great help if you could find where in the book we might be pointing toward that use case and remove those instances to help drive that work forward.
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 for the feedback. So you're saying dropping support for deploying any number of control plane machines which are not managed by a provider? Perhaps you could link to one or more places in documentation where this is referenced?
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.
So you're saying dropping support for deploying any number of control plane machines which are not managed by a provider
Exactly - I don't think CAPI should enforce specific deployment scenarios like e.g. number of CP nodes in a cluster, but currently support is built-in for 'standalone' control planes which, in general, pre-existed the Control Plane providers.
I'm not sure how many places in the documentation explicitly supports the use case but there is this in staging-use-cases.md
:
- As an operator, given that I have a management cluster and a pre-existing control plane, I would like to manage the lifecycle of a group of worker nodes without managing the control plane those nodes join.
I think we need the community discussion on deprecating this case to move forward before actually making any changes.
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.
Ok, I provided my feedback on migrating the staging-use-cases document all together on your issue.
Signed-off-by: David Tesar [email protected]
What this PR does / why we need it:
Fixes #3425