ControlPlaneInitialized condition is set before a control-plane Node is ready

[dkoshkin]

What steps did you take and what happened:

1. Follow https://cluster-api.sigs.k8s.io/user/quick-start.html for Docker with:

clusterctl generate cluster capi-quickstart --flavor development \
  --kubernetes-version v1.19.11 \
  --control-plane-machine-count=1 \
  --worker-machine-count=1 \
  > capi-quickstart.yaml

2. Modify the KubeadmControlPlane to force a failure, something like:

apiVersion: controlplane.cluster.x-k8s.io/v1alpha4
kind: KubeadmControlPlane
metadata:
  name: capi-quickstart-control-plane
  namespace: default
spec:
  kubeadmConfigSpec:
    initConfiguration:
      nodeRegistration:
        kubeletExtraArgs:
          node-labels: "{{INVALID_LABELS}}"

---

The worker machine is in Provisioning, before a control-plane is up:

kubectl get machines
NAME                                    PROVIDERID   PHASE          VERSION
capi-quickstart-control-plane-gbcvx                  Provisioning   v1.19.11
capi-quickstart-md-0-644755b685-spjwc                Provisioning   v1.19.11

Its because the cluster has ControlPlaneInitialized status.

  status:
    conditions:
    - lastTransitionTime: "2021-07-13T17:59:21Z"
      message: Scaling up control plane to 1 replicas (actual 0)
      reason: ScalingUp
      severity: Warning
      status: "False"
      type: Ready
    - lastTransitionTime: "2021-07-13T18:00:03Z"
      status: "True"
      type: ControlPlaneInitialized

Even though there is no nodeRef

kubectl get machines capi-quickstart-control-plane-gbcvx -o yaml | grep nodeRef | wc -l
       0

What did you expect to happen:

According to the API comment ControlPlaneInitializedCondition should be marked True when:

cluster's apiserver is reachable and at least one control-plane Machine has a node reference

There is 1 controller that checks for the NodeRef

cluster-api/controllers/cluster_controller.go

Lines 477 to 482 in 7f879be

	for _, m := range machines {
	if util.IsControlPlaneMachine(m) && m.Status.NodeRef != nil {
	conditions.MarkTrue(cluster, clusterv1.ControlPlaneInitializedCondition)
	return ctrl.Result{}, nil
	}
	}

But another one will set to True with only KubeadmControlPlane.initialized = true:

cluster-api/controllers/cluster_controller_phases.go

Lines 238 to 247 in bfc6f80

	// Update cluster.Status.ControlPlaneInitialized if it hasn't already been set
	// Determine if the control plane provider is initialized.
	if !conditions.IsTrue(cluster, clusterv1.ControlPlaneInitializedCondition) {
	initialized, err := external.IsInitialized(controlPlaneConfig)
	if err != nil {
	return ctrl.Result{}, err
	}
	if initialized {
	conditions.MarkTrue(cluster, clusterv1.ControlPlaneInitializedCondition)
	} else {

I think both should check for a control-plane Machine to have a NodeRef.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

It most cases it may be undesirable to start bootstrapping worker machines before a control-plane (and API server) is up since it may cause a lot of churn as the workers will fail to start.

Environment:

• Cluster-api version: v0.4.0
• Minikube/KIND version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

/kind bug
[One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels]

[vincepri]

/assign @fabriziopandini
/milestone v0.4

Just a note that the two codepaths linked above are mutually exclusive, although I do agree that they have different definitions and this should be fixed.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/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.

[vincepri]

/reopen
/lifecycle frozen

[k8s-ci-robot]

@vincepri: Reopened this issue.

In response to this:

/reopen
/lifecycle frozen

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.

[fabriziopandini]

/unassign

[13164815445]

I am very interested in this project, can I try to solve this problem?

[killianmuldoon]

@13164815445 Welcome and thanks for your interest! It might be a good idea to tackle on of our good first issues initially to get used to the workflow in contributing to Cluster API.

[13164815445]

thanks! can i assign this issue to me? @killianmuldoon

[13164815445]

/assign @13164815445

[fabriziopandini]

/triage accepted

[killianmuldoon]

/unassign @13164815445

/assign @killianmuldoon