-
Notifications
You must be signed in to change notification settings - Fork 42
kubernetes: let kubelet start when swap is on #473
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 8000 of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Ben Cressey <bcressey@amazon.com>
Do you want to go ahead and open the |
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.
This has been running ok
on a lot of upstream CI jobs for a while now.
From what I gathered based on the release notes for 1.28 and 1.30:
Consequently I don't want to enable the feature gate for the older versions. In the short term, I'd like swap to be available as a tool to manage the kernel's reclaim behavior in near-OOM conditions. It'll be more difficult to evaluate its effectiveness if pods are also utilizing available swap space. |
Makes sense, I didn’t catch the change in default swapBehavior 👍 |
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.
What is the underlying reason for the cgroups v1 and cgroups v2 configs being tested differently?
The mechanism for disabling swap in containers is different, and I wanted to make sure the right thing happened for both. Also, the k8s 1.32 post says:
The pairing of these two statements could imply that kubelet would fail to run if swap was enabled on a host using cgroup v1, and I wanted to confirm that wasn't the case. If it's merely "unsupported" that's fine since the goal is not to enable swap for pods. |
Issue number:
Related: bottlerocket-os/bottlerocket#4075
Description of changes:
Set
failSwapOn: false
for all kubelet configs.The goal of this change is to simplify experiments with swap enabled on the host as a possible remedy for the unreachable nodes discussed in the related issue. This requires letting
kubelet
actually start if swap is enabled. Allowing pods to use swap is a larger change that's out of scope here.Testing done:
For each Kubernetes variant from 1.25 to 1.32, I confirmed that
kubelet
started when swap was enabled on the node, in both cgroups v1 and cgroups v2 configurations.With cgroups v1, I confirmed that
memory.memsw.limit_in_bytes
was set to the same value asmemory.limit_in_bytes
, which prevents the use of swap:With cgroups v2, I confirmed that
memory.swap.max
was set to zero for workload containers.Terms of contribution:
By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.