-
Notifications
You must be signed in to change notification settings - Fork 56
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
OCPBUGS-42236: (CARRY) Graceful shutdown functionality for multus daemon #252
OCPBUGS-42236: (CARRY) Graceful shutdown functionality for multus daemon #252
Conversation
…on by adding a /readyz endpoint That is added alongside the existing /healthz. The /readyz endpoint starts returning 500 once a SIGTERM is received, indicating the daemon is in shutdown mode. During this time, CNI requests can still be processed for a short window. The daemonset configs have been updated to increase terminationGracePeriodSeconds from 10 to 30 seconds, ensuring we have a bit more time for these clean shutdowns. This addresses a race condition during pod transitions where the readiness check might return true, but a subsequent CNI request could fail if the daemon shuts down too quickly. By introducing the /readyz endpoint and delaying the shutdown, we can handle ongoing CNI requests more gracefully, reducing the risk of disruptions during critical transitions. Major thanks to @deads2k for the find, identification, fix, and of course, the explanations. Appreciate it.
Replaces #251, related to k8snetworkplumbingwg/multus-cni#1338 upstream |
/title OCPBUGS-42236: Graceful shutdown functionality for multus daemon |
/retitle OCPBUGS-42236: Graceful shutdown functionality for multus daemon |
@dougbtv: This pull request references Jira Issue OCPBUGS-42236, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
No GitHub users were found matching the public email listed for the QA contact in Jira (weliang@redhat.com), skipping review request. The bug has been updated to refer to the pull request using the external bug tracker. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
@dougbtv: all tests passed! Full PR test history. Your PR dashboard. 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-sigs/prow repository. I understand the commands that are listed here. |
/lgtm |
/retitle OCPBUGS-42236: (CARRY) Graceful shutdown functionality for multus daemon |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bpickard22, dougbtv 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 |
@dougbtv: Jira Issue OCPBUGS-42236: All pull requests linked via external trackers have merged: Jira Issue OCPBUGS-42236 has been moved to the MODIFIED state. In response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
[ART PR BUILD NOTIFIER] Distgit: multus-cni-container-microshift |
This PR introduces graceful shutdown functionality to the Multus daemon by adding a
/readyz
endpoint alongside the existing/healthz
. The /readyz endpoint starts returning 500 once a SIGTERM is received, indicating the daemon is in shutdown mode. During this time, CNI requests can still be processed for a short window. The daemonset configs have been updated to increaseterminationGracePeriodSeconds
from 10 to 30 seconds, ensuring we have a bit more time for these clean shutdowns.This addresses a race condition during pod transitions where the readiness check might return true, but a subsequent CNI request could fail if the daemon shuts down too quickly. By introducing the /readyz endpoint and delaying the shutdown, we can handle ongoing CNI requests more gracefully, reducing the risk of disruptions during critical transitions.
Major thanks to @deads2k for the find, identification, fix, and of course, the explanations. Appreciate it.