-
Notifications
You must be signed in to change notification settings - Fork 618
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
Audit the cgroups in Talos and resource reservation #7081
Comments
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 7 days. |
This issue was closed because it has been stalled for 7 days with no activity. |
Still valid, need a stress test |
smira
added a commit
to smira/talos
that referenced
this issue
Sep 19, 2024
Fixes: siderolabs#7081 Review all reservations and limits set, test under stress load (using both memory and CPU). The goal: system components (Talos itself) and runtime (kubelet, CRI) should survive under extreme resource starvation (workloads consuming all CPU/memory). Uses siderolabs#9337 to visualize changes, but doesn't depend on it. Signed-off-by: Andrey Smirnov <[email protected]>
smira
added a commit
to smira/talos
that referenced
this issue
Sep 19, 2024
Fixes: siderolabs#7081 Review all reservations and limits set, test under stress load (using both memory and CPU). The goal: system components (Talos itself) and runtime (kubelet, CRI) should survive under extreme resource starvation (workloads consuming all CPU/memory). Uses siderolabs#9337 to visualize changes, but doesn't depend on it. Signed-off-by: Andrey Smirnov <[email protected]>
smira
added a commit
to smira/talos
that referenced
this issue
Sep 20, 2024
Fixes: siderolabs#7081 Review all reservations and limits set, test under stress load (using both memory and CPU). The goal: system components (Talos itself) and runtime (kubelet, CRI) should survive under extreme resource starvation (workloads consuming all CPU/memory). Uses siderolabs#9337 to visualize changes, but doesn't depend on it. Signed-off-by: Andrey Smirnov <[email protected]>
smira
added a commit
to smira/talos
that referenced
this issue
Sep 20, 2024
Fixes: siderolabs#7081 Review all reservations and limits set, test under stress load (using both memory and CPU). The goal: system components (Talos itself) and runtime (kubelet, CRI) should survive under extreme resource starvation (workloads consuming all CPU/memory). Uses siderolabs#9337 to visualize changes, but doesn't depend on it. Signed-off-by: Andrey Smirnov <[email protected]>
smira
added a commit
to smira/talos
that referenced
this issue
Sep 21, 2024
Fixes: siderolabs#7081 Review all reservations and limits set, test under stress load (using both memory and CPU). The goal: system components (Talos itself) and runtime (kubelet, CRI) should survive under extreme resource starvation (workloads consuming all CPU/memory). Uses siderolabs#9337 to visualize changes, but doesn't depend on it. Signed-off-by: Andrey Smirnov <[email protected]> (cherry picked from commit 6b15ca1)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Do we need to reserve some CPU for
/init
cgroup (machined
)?Do we want to have some default reservation for the kubelet cgroup?
Can we easily gather some resource consumption data on the dashboard?
The text was updated successfully, but these errors were encountered: