Skip to content

KEP-4603: Correct conflict resolution table #5201

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

KEP-4603: Correct conflict resolution table #5201

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 13 additions & 12 deletions keps/sig-node/4603-tune-crashloopbackoff/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1341,9 +1341,9 @@ kubelet will crash/be unable to start, like it does with other invalid kubelet
configuration today.

If on a given node at a given time, the per-node configured maximum backoff is
higher than the current initial value, but within validation limits as it is
higher than the default maximum backoff, but within validation limits as it is
lower than 300s, it will be honored. In other words, operator-invoked
configuration will have precedence over the default, even if it is slower, as
configuration for the maximum backoff will have precedence over the default, even if it is slower, as
long as it is valid.
Comment on lines 1343 to 1347
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: is this paragraph necessary? Isn't this just stating what a default means? Or am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but then so is the first paragraph (ending in "In other words, operator-invoked configuration will have
precedence over the default if it is faster."). I think both paragraphs were to make that explicit, and separately in the event there was appetite for different conflict resolution depending on if a node's default was slower or faster than what the user's crashloopbackoff.maxSeconds requested (though in the end the behavior ended up being the same).


If `crashloopbackoff.maxSeconds` `KubeletConfiguration` exists but
Expand All @@ -1352,16 +1352,17 @@ not honor the `crashloopbackoff.maxSeconds` `KubeletConfiguration`. In other wor
operator-invoked per node configuration will not be honored if the overall
feature gate is turned off.

scenario | ReduceDefaultCrashLoopBackoffDecay | EnableKubeletCrashLoopBackoffMax | Effective initial value
---------|---------|----------|---------
_today's behavior_ | disabled | disabled | 10s
_new default only_ | enabled | disabled | 1s
_faster per node config_ | disabled | 2s | 2s
" | enabled | 2s | 2s
_slower per node config_ | enabled | 10s | 10s
" | enabled | 300s | 300s
" | disabled | 11s | 11s
" | disabled | 300s | 300s
scenario | ReduceDefaultCrashLoopBackoffDecay | EnableKubeletCrashLoopBackoffMax | Effective initial value | Effective maximum value
---------|---------|----------|---------|---------
_today's behavior_ | disabled | disabled | 10s | 300s
_new default only_ | enabled | disabled | 1s | 60s
_faster per node config_ | disabled | 60s | 10s | 60s
" | disabled | 2s | 2s | 2s
" | enabled | 2s | 1s | 2s
" | enabled | 30s | 1s | 30s
_slower per node config_ | enabled | 300s | 1s | 300s
" | enabled | 61s | 1s | 61s
_valid node config that reimplements today's behavior_ | disabled | 300s | 10s | 300s
_invalid per node config_ | disabled | 301s | kubelet crashes
" | enabled | 301s | kubelet crashes

Expand Down