-
Notifications
You must be signed in to change notification settings - Fork 376
overconstraining sandbox in case of k8s #2792
Comments
heads up @devimc @jcvenegas |
Thanks for open the issue, so now given that Correct me if I am wrong but this is a consequence of the fragmentation on how Kata is expected to manage resources. PodLavel vs Container Level. Based on our previous checks, trying to do assumptions of how resources should be contain for a Pod makes difficult. I still missing context, but #2408 documents that sandbox_cgroup_only=true + docker was not applying limits. Something we could do is suggest if folks want docker limited host level keep using Anyway, some questions may help us to understand.
|
There is no annotation from CRI to indicate K8S. K8S is and should be the default configuration for Kata Containers (and is the priority). The prior PR breaks this. I would recommend creating a flag in toml for indicating that the runtime should manage cpu/mem group subsystems on the host, and this should be disabled by default. This would be set if folks want to constrain and are using Docker or Podman. In any case - we should be careful not to break kata+k8s... |
There is a mix of handling in the runtime code around cgroups. Let's go ahead and allow for constraining the cpuset. Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, started or updated, or when containers are removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's updateResources function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
There is a mix of handling in the runtime code around cgroups. Let's go ahead and allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, started or updated, or when containers are removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's updateResources function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's go ahead and add to the Sandbox's cgroupsUpdat function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's add to the Sandbox's cgroupsUpdate function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's add to the Sandbox's cgroupsUpdate function. Fixes: #2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com>
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's add to the Sandbox's cgroupsUpdate function. Fixes: kata-containers#2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com> (cherry picked from commit 8b4c299)
Allow for constraining the cpuset as well as the devices-whitelist . Revert sandbox constraints for cpu/memory, as they break the K8S use case. Can re-add behind a non-default flag in the future. The sandbox CPUSet should be updated every time a container is created, updated, or removed. To facilitate this without rewriting the 'non constrained cgroup' handling, let's add to the Sandbox's cgroupsUpdate function. Fixes: kata-containers#2792 Signed-off-by: Eric Ernst <eric@amperecomputing.com> (cherry picked from commit 8b4c299)
Description of problem
#2409 introduced an undesirable behavior in the scenario where Kata is being integrated with Kubernetes. In this case, kubelet manages the sandbox cgroup, including memory and cpu subsystems. By applying these cgroups, we are over-constraining the sandbox cgroup
Expected result
CPU and Memory subsystems are left untouched by default.
Actual result
It looks like the cgroup would be set based on pause container in case of k8s, or at least doesn't appear to take into consideration the sum of container requests. Further, even if it was considering container summation, it is not able to apply an overhead for running in a sandbox.
I'd recommend reverting 2409 and hiding this behavior change behind a non-default flag.
The text was updated successfully, but these errors were encountered: