Skip to content
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

Fixing yet another race condition during cluster/kernel upgrade #917

Conversation

yevgeny-shnaidman
Copy link
Contributor

The following scenario causes worker pods to be stuck during cluster upgrade:

  1. kernel module is loaded into the node. NMC contains both spec and status using the current kernel version 2) cluster upgrade starts. As part of the upgrade node becomes
    Unschedulable
  2. Module-NMC removes Spec from NMC, since the node is Uschedulable 4) NMC controller creates an unload worker pod, since the timestamp of
    the ready condition of the node has not been updated yet to a new
    value (the node is still not ready).
  3. once the node becomes ready, the unload worker pod is scheduled with
    the old kernel version and therefore constantly fails.

Solution:
We will skip handling spec, statuses , garbage collection and labelling for the node that are not ready (unschedulable). We will only collect the completed pod and will update NMC statuses accordingly. Once the node becomes ready, the new reconciliation loop will kick in

The following scenario causes worker pods to be stuck during cluster
upgrade:
1) kernel module is loaded into the node. NMC contains both spec and status using the current kernel version
2) cluster upgrade starts. As part of the upgrade node becomes
   Unschedulable
3) Module-NMC removes Spec from NMC, since the node is Uschedulable
4) NMC controller creates an unload worker pod, since the timestamp of
   the ready condition of the node has not been updated yet to a new
   value (the node is still not ready).
5) once the node becomes ready, the unload worker pod is scheduled with
   the old kernel version and therefore constantly fails.

Solution:
We will skip handling spec, statuses , garbage collection and labelling
for the node that are not ready (unschedulable). We will only collect
the completed pod and will update NMC statuses accordingly. Once the
node becomes ready, the new reconciliation loop will kick in
@k8s-ci-robot k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Oct 7, 2024
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yevgeny-shnaidman

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added approved Indicates a PR has been approved by an approver from all required OWNERS files. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 7, 2024
@yevgeny-shnaidman
Copy link
Contributor Author

/assign @ybettan

@ybettan
Copy link
Contributor

ybettan commented Oct 7, 2024

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 7, 2024
@k8s-ci-robot k8s-ci-robot merged commit 4a5518e into kubernetes-sigs:release-2.2 Oct 7, 2024
14 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants