Change:
master-informing: periodic-kubernetes-e2e-kind-kms ! No response /sig cluster-lifecycle
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/milestone v1.29
/assign but this test job is maintained by sig auth: /sig auth looks like the API server has decided to consistently fail on an unpolled CRB create API call from the kubeadm client. this did not happen on the kind presubmit jobs here: or kubeadm periodic jobs using the kinder tool: or my local tests. so what is different here and why are we getting informer errors? is this highlighting a bug in core k8s? cc best we can do in kubeadm is make that API call polled. FTR, the API call exactly prior to this failing API call is already polled.
Hello. I want to echo that the code freeze is starting (next week), and we want to ensure that each PR has a chance to be merged and issues can be addressed. Is this PR still targeting the 1.29 release?
FTR, the API call exactly prior to this failing API call is already polled. +1 to have the API call polled just as the API call with .
here is the kubeadm PR.
we are tracking a failing test in this ticket and we can proceed with fixing this after code freeze is in effect. i just submitted an associated fix PR here:
As the Alpha 3 release cut is approaching (2nd Nov) /priority critical-urgent
/assign
we have a couple of kubeadm passes here: of the presubmit variant of this job: pull-kubernetes-e2e-kind-kms this seems like a flake and not a failure, given the offending PR merged on the 27th and looking at the history of the periodic:
we are having the similar issue with i saw in the logs I am not sure what I should do, could you help me? 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.
Had some discussion with Carlos. I didn't follow this issue here in full detail, but probably the CAPG issue is resolved by the PR that we merged in core CAPI and will be part of the CAPI rc next week
yes, seems to work now :) thank you all!!!

Discussion:
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.

}, expectedError: false, }, <ins> { name: "super-admin.conf: admin.conf cannot create CRB, try to create CRB with super-admin.conf, encounter 'already exists' error", setupAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewForbidden( schema.GroupResource{}, "name", errors.New("")) }) }, setupSuperAdminClient: func(client *clientsetfake.Clientset) { client.PrependReactor("create", "clusterrolebindings", func(action clientgotesting.Action) (bool, runtime.Object, error) { return true, nil, apierrors.NewAlreadyExists( schema.GroupResource{}, "name") }) }, expectedError: true, }, </ins> } for _, tc := range tests {