-
Notifications
You must be signed in to change notification settings - Fork 193
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
feat: support filtering backup target pods by the alternative label selector #7831
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7831 +/- ##
==========================================
- Coverage 64.90% 64.84% -0.07%
==========================================
Files 345 345
Lines 42941 42967 +26
==========================================
- Hits 27873 27864 -9
- Misses 12632 12656 +24
- Partials 2436 2447 +11
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Modify the PR title to describe the implemented functionality. |
done |
/cherry-pick release-0.9 |
🤖 says: cherry pick action finished successfully 🎉! |
fix #7072
Add
fallbackLabelSelector
field to podSelector in backuppolicy, and addfallbackRole
field used to buildfallbackLabelSelector
in backuppolicytemplate. If backup controller fails to filter available target pods, it will usefallbackLabelSelector
to filter target pods. This behavior only takes effect when strategy is set toAny
in the podSelector,Any
means backup controller only selects one available pod as the target.For example, in a primary-secondary cluster, we have scheduled tasks to back up the secondary pod. In the past, If all secondary pods are unavailable, the backups would continuously fail. Now, with the
fallbackLabelSelector
used to filter backup target pod, if all secondary pods are unavailable, we can use it to select the primary pod for backups, to guarantee the continuity of scheduled backup tasks with a high probability.