Code change:
kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding, kubeadmconstants.SuperAdminKubeConfigFileName) <del> if _, err := superAdminClient.RbacV1().ClusterRoleBindings().Create( </del> <ins> err = wait.PollUntilContextTimeout( </ins> ctx, <del> clusterRoleBinding, metav1.CreateOptions{}, ); err != nil { return nil, errors.Wrapf(err, "unable to create the %s ClusterRoleBinding", kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding) </del> <ins> retryInterval, retryTimeout, true, func(ctx context.Context) (bool, error) { if _, err := superAdminClient.RbacV1().ClusterRoleBindings().Create( ctx, clusterRoleBinding, metav1.CreateOptions{}, ); err != nil { lastError = err if apierrors.IsAlreadyExists(err) { // This should not happen, as the previous "create" call that uses // the admin.conf should have passed. Return the error. return true, err } // Retry on any other type of error. return false, nil } return true, nil }) if err != nil { return nil, errors.Wrapf(lastError, "unable to create the %s ClusterRoleBinding by using %s", kubeadmconstants.ClusterAdminsGroupAndClusterRoleBinding, kubeadmconstants.SuperAdminKubeConfigFileName) </ins> } // Once the CRB is in place, start using the admin.conf client.

Related discussion:
text: thanks
Can you pls tell where is the the log you pasted above? I searched in this file: , and some other logs related with kubeadm but cannot find it. The original issue is expected to be fixed by: It's now continuous green now: But the log you pasted do point to the change we landed last week:
kubeadm introduced a new step in the "init" process. it creates an file but it needs RBAC for it. this RBAC is created in a rather complicated manner (with a fallback), but in your case it's failing at the first step where the API server is not reachable in 40 seconds. do you expect the API server to no be ready in 40 seconds? are you sure there are no other problems with the setup and it just ends up failing at this first API server step where RBAC is created? other jobs like CAPI (non-upgrade), kinder, kind are green with respect to this. i wonder if we can just stop returning this error and fallback to the super- "create" attempt later: this will allow for more time for certain setups to start - 40 + 40 seconds. ... it exactly to catch problems like the one is reporting - no early connectivity to the API server. but if this is now the "first thing" in kubeadm, it might have introduced a bit of a timeout regression for slower setups.
also note that the kubeadm CP provider in CAPI does not yet support this feature and the upgrade CAPI jobs are also failing:
actually, the feature seems change the order of "init": it waits for the apiserver + kubelet (, 40seconds for kubelet) and the RBAC create ( when the first client() creation happens) at the same time. i think what has to be changed here is: the parallel aspect of the apiserver + kubelet wait. it has been difficult to manage and confusing. delay the RBAC create to be after the apiserver + kubelet waiting is done. maybe something we can do for .29 is 2. but 1 is a bigger refactor.
PR with an attempt to improve the kubeadm wait logic: i do think CAPG has unrelated problems. the kubelet might be failing to start or starting but not creating the static pod for kube-apiserver.