-
Notifications
You must be signed in to change notification settings - Fork 6.5k
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
Allow pausing after upgrade but before uncordon #8530
Conversation
Welcome @mac-chaffee! |
Hi @mac-chaffee. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
Helps address #8535 |
Actually this would be better as a post-upgrade
I'll implement it that way /hold |
/hold remove |
/unhold |
Signed-off-by: Mac Chaffee <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mac-chaffee Thank you
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: floryut, mac-chaffee 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 |
Looks like I need an ok-to-test approval as well |
/lgtm |
Turns out this might not have the desired effect due to another sort of bug: The "uncordon" step (and thus the prompt) occurs BEFORE all the handlers, which reload systemd and restart kubelet. So the second the node gets uncordoned, kubelet gets rebooted, which may cause issues for pods that were immediately scheduled on that node. So we actually need to move the prompt and the uncordon step after the handlers, maybe making them handlers as well. |
oh and the message "Ready to uncordon node?" may not always be accurate. If the node was already cordoned, uncordoning will be skipped, so the prompt could be confusing. |
* master: Configure Etcd container_manager explicitly (kubernetes-sigs#8521) Fix print_hostnames of inventory.py (kubernetes-sigs#8554) Fix etcd_events not getting upgraded in upgrade-cluster.yml (kubernetes-sigs#8550) nerdctl: upgrade to 0.16.1 (kubernetes-sigs#8539) Allow pausing after upgrade but before uncordon (kubernetes-sigs#8530) [calico] upgrade release checksums (kubernetes-sigs#8544) Allow to specify a source address for metallb peerings, and target only some nodes using node selectors (kubernetes-sigs#8534) add support for Dual Stack node InternalIP (kubernetes-sigs#8542) terraform/gcp: Allow to change extra disk types (kubernetes-sigs#8524) add support for Calico IP6_AUTODETECTION_METHOD (kubernetes-sigs#8541) implement download mirrors support (kubernetes-sigs#8474) Fix: Error when creating subnets more than AZ (kubernetes-sigs#8516) feat(offline): Improve generate_list.sh to generate offline file list using ansible (kubernetes-sigs#8537) (kubernetes-sigs#8538) docs: Update offline-environment.md for containerd (kubernetes-sigs#8520) (kubernetes-sigs#8523) Change Cilium setting identity_allocation_mode to cilium_identity_allocation_mode (kubernetes-sigs#8519) Fix wrong port name in metallb.yml.j2 (kubernetes-sigs#8510)
* Allow pausing after upgrade but before uncordon * Expand docs for upgrade pausing vars Signed-off-by: Mac Chaffee <[email protected]>
* Allow pausing after upgrade but before uncordon * Expand docs for upgrade pausing vars Signed-off-by: Mac Chaffee <[email protected]>
* Allow pausing after upgrade but before uncordon * Expand docs for upgrade pausing vars Signed-off-by: Mac Chaffee <[email protected]>
* Allow pausing after upgrade but before uncordon * Expand docs for upgrade pausing vars Signed-off-by: Mac Chaffee <[email protected]>
What type of PR is this?
/kind feature
What this PR does / why we need it:
Since performing Kubernetes upgrades requires draining all the nodes in sequence, that is an excellent time to perform other maintenance tasks like rebooting to apply kernel upgrades, upgrading packages, or other manual changes. For complex upgrades, it may also be nice to leave a node cordoned after the upgrade to inspect it before allowing it to run workloads.
So this PR adds two optional variables so that users can either be prompted before uncordoning an upgraded node, or just wait a specified duration (just like the pre-upgrade promp/delay setting). The default behavior (no prompting, no delay) is left intact.
Which issue(s) this PR fixes:
Provides a workaround for #8535
Special notes for your reviewer:
Does this PR introduce a user-facing change?: