Skip to content
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

Docker & Kubelet are using cgroupfs as Cgroup Driver. #1

Open
vlvasilev opened this issue Aug 16, 2019 · 1 comment
Open

Docker & Kubelet are using cgroupfs as Cgroup Driver. #1

vlvasilev opened this issue Aug 16, 2019 · 1 comment
Assignees
Labels
lifecycle/rotten Nobody worked on this for 12 months (final aging stage)

Comments

@vlvasilev
Copy link
Contributor

Directly from the the source

When systemd is chosen as the init system for a Linux distribution, the init process generates and consumes a root control group (cgroup) and acts as a cgroup manager. Systemd has a tight integration with cgroups and will allocate cgroups per process. It’s possible to configure your container runtime and the kubelet to use cgroupfs. Using cgroupfs alongside systemd means that there will then be two different cgroup managers.

Control groups are used to constrain resources that are allocated to processes. A single cgroup manager will simplify the view of what resources are being allocated and will by default have a more consistent view of the available and in-use resources. When we have two managers we end up with two views of those resources. We have seen cases in the field where nodes that are configured to use cgroupfs for the kubelet and Docker, and systemd for the rest of the processes running on the node becomes unstable under resource pressure.

Changing the settings such that your container runtime and kubelet use systemd as the cgroup driver stabilized the system.

We meet the same problem with Ubuntu. Both docker and kubelet are using cgroupfs.
Docker can be easily set to use systemd as Cgroup Driver vie the Ubuntu Controller Extension but the configuration of the kubelet is comes from the gardener via OperationSystemConfig CRD and is common for all OS distributions.

@rfranzke
Copy link
Member

but the configuration of the kubelet is comes from the gardener via OperationSystemConfig CRD and is common for all OS distributions.

If it's needed for Ubuntu then you can easily change/extend/adapt the configuration. That's what the provider-specific control plane webhooks are doing as well. The "standard" kubelet configuration is coming from Gardener, but the providers inject e.g. the cloud-config (or other flags/configuration) via a webhook. This complexity is not needed in the OSC controllers themselves, because they are the main responsibles for reconciling the OperatingSystemConfig resource. If you need to change something in the kubelet's configuration then just do it and adapt the produced results.

@rfranzke rfranzke transferred this issue from gardener-attic/gardener-extensions Jan 29, 2020
@ghost ghost added the lifecycle/stale Nobody worked on this for 6 months (will further age) label Mar 30, 2020
@ghost ghost added lifecycle/rotten Nobody worked on this for 12 months (final aging stage) and removed lifecycle/stale Nobody worked on this for 6 months (will further age) labels May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/rotten Nobody worked on this for 12 months (final aging stage)
Projects
None yet
Development

No branches or pull requests

2 participants