Document how to attach worker nodes to any control planes

[rhockenbury]

User Story

I wanted to see if this use case has any merit.

A user could potentially choose to deploy the control plane for a cluster with non-cluster-api tools (kubespray, kops, and others), and then manage only the worker nodes with the cluster-api.

Here's why a user might find this desirable:

1. If a user is migrating from a tool like kubespray or kops to the cluster-api, they may want to adopt the cluster-api in smaller increments and manage only a subset of workers nodes through the cluster-api, rather than going "all in"
2. It removes the need for a KIND cluster, and pivoting to a management cluster, which can often be pain points in adopting the cluster-api, and given that the user may already have a well-established process for provisioning the control plane, this would allow them to continue to use that process.

Detailed Description

The cluster bootstrap would proceed like this:

1. The user would provision the control plane
2. The user would deploy the cluster-api controllers by adding a node-selector or toleration to allow scheduling the controllers on the master nodes
3. The user would apply the manifests without the machineDeployment and kubeadmConfigTemplate for the control plane
4. The worker nodes would be provisioned by the cluster-api

This is already possible with a few manual steps:

• Steps 1 + 2 from above
• Create a secret for the -ca (only the ca secret is required for bootstrapping worker nodes)
• Set Cluster.metadata.annotations[cluster.x-k8s.io/control-plane-ready] to true
• Set Cluster.Status.controlPlaneInitialized to true
• Set Cluster.Status.apiEndpoints[0].host = api_server and Cluster.Status.apiEndpoints[0].port = port

This will allow the boostrapper to jump this logic (https://github.com/kubernetes-sigs/cluster-api-bootstrap-provider-kubeadm/blob/master/controllers/kubeadmconfig_controller.go#L186) and proceed with setting up worker nodes.

Anything else you would like to add:

Because the cluster-api CRDs are created with the status subresource enabled, the status field cannot be directly modified by kubectl commands.

Annotations could potentially be set for controlPlaneInitialized and apiEndpoints to allow manual overrides of the fields on the Cluster.Status.

/kind feature

[ncdc]

@michaelgugino to add in details on how OpenShift does this with Cluster API

[rhockenbury]

@michaelgugino - I would be interested to hear how you approach this.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rhockenbury]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[detiber]

/lifecycle frozen

[vincepri]

/kind documentation
/retitle Document how to attach worker nodes to any control planes
/help

[k8s-ci-robot]

@vincepri:
This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

In response to this:

/kind documentation
/retitle Document how to attach worker nodes to any control planes
/help

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.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fabriziopandini]

/remove-lifecycle stale

[fabriziopandini]

@vincepri @enxebre what about closing this in favor of #4095, the two-issue seems related to me

[vincepri]

/close

[k8s-ci-robot]

@vincepri: Closing this issue.

In response to this:

/close

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.