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

support cgroup2 #40174

Merged
merged 4 commits into from
Jan 9, 2020
Merged

support cgroup2 #40174

merged 4 commits into from
Jan 9, 2020

Conversation

AkihiroSuda
Copy link
Member

@AkihiroSuda AkihiroSuda commented Nov 5, 2019

- What I did
support cgroup2 (unified mode)

Fix #16238

- How I did it

- How to verify it

Limitations:

- Description for the changelog

support cgroup2

- A picture of a cute animal (not mandatory but encouraged)
🐧

@AkihiroSuda
Copy link
Member Author

containerd/containerd#3799 is merged, but we still need a couple of days to stabilize the interface

@thaJeztah
Copy link
Member

We should look at adding a stage to the Jenkinsfile that runs on a machine with cgroup2 enabled

@AkihiroSuda AkihiroSuda changed the title [DNM] support cgroup2 support cgroup2 Dec 17, 2019
@AkihiroSuda
Copy link
Member Author

Maybe we can merge this PR as-is and work on metrics in separate PRs

@thaJeztah
Copy link
Member

Maybe we can merge this PR as-is and work on metrics in separate PRs

Do we need a more recent version of containerd and run to actually use this? (with containerd/containerd#3799 in it?)

We should look at adding a stage to the Jenkinsfile that runs on a machine with cgroup2 enabled

^ what would be needed for that? Probably at least a host that runs a more recent version of Ubuntu/Debian/Fedora, but given that we run the tests DIND, do we need to update the base-image or a separate stage for that?

@thaJeztah
Copy link
Member

@dmcgowan @crosbymichael @cpuguy83 ptal

@AkihiroSuda
Copy link
Member Author

Do we need a more recent version of containerd and run to actually use this? (with containerd/containerd#3799 in it?)

We need containerd binary built from master, but no need to vendor containerd library at this moment.
Probably we need to revendor containerd when we implement metrics. (Blocked due to vendor hell moby/buildkit#1293)

^ what would be needed for that? Probably at least a host that runs a more recent version of Ubuntu/Debian/Fedora, but given that we run the tests DIND, do we need to update the base-image or a separate stage for that?

Maybe we should wait for adding cgroup v2 CI until we finish basic v2 support.

Or we can use Podman instead, but not sure it is acceptable 😛 https://github.com/opencontainers/runc/blob/201b06374548b64212f4ceb1529688d435e42899/.travis.yml#L29

* Requires containerd binaries from containerd/containerd#3799 . Metrics are unimplemented yet.
* Works with crun v0.10.4, but `--security-opt seccomp=unconfined` is needed unless using master version of libseccomp
  ( containers/crun#156, seccomp/libseccomp#177 )
* Doesn't work with master runc yet
* Resource limitations are unimplemented

Signed-off-by: Akihiro Suda <[email protected]>
enable resource limitation by disabling cgroup v1 warnings

resource limitation still doesn't work with rootless mode (even with systemd mode)

Signed-off-by: Akihiro Suda <[email protected]>
For cgroup v1, we were unable to change the default because of
compatibility issue.

For cgroup v2, we should change the default right now because switching
to cgroup v2 is already breaking change.

See also containers/podman#4363 containers/podman#4374

Privileged containers also use cgroupns=private by default.
containers/podman#4374 (comment)

Signed-off-by: Akihiro Suda <[email protected]>
@AkihiroSuda
Copy link
Member Author

@thaJeztah PTAL?

AkihiroSuda added a commit to AkihiroSuda/cri-containerd that referenced this pull request Jan 9, 2020
In cgroup v1 container implementations, cgroupns is not used by default because
it was not available in the kernel until kernel 4.6 (May 2016), and the default
behavior will not change on cgroup v1 environments, because changing the
default will break compatibility and surprise users.

For cgroup v2, implementations are going to unshare cgroupns by default
so as to hide /sys/fs/cgroup from containers.

* Discussion: containers/podman#4363
* Podman PR (merged): containers/podman#4374
* Moby PR: moby/moby#40174

This PR enables cgroupns for containers, but pod sandboxes are untouched
because probably there is no need to do.

Signed-off-by: Akihiro Suda <[email protected]>
@joemccall86
Copy link

@AkihiroSuda I think it means, "Please Take A Look."

@AkihiroSuda
Copy link
Member Author

Yes, so, I'm asking thaJeztah to PTAL whether we can merge this PR without including metrics stuff 😅

Copy link
Member

@cpuguy83 cpuguy83 left a comment

Choose a reason for hiding this comment

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

LGTM

Tested with Fedora 31 and a master build of containerd and runc.

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM

we should create a tracking issue for what's needed to run CI for this

@thaJeztah thaJeztah merged commit e6c1820 into moby:master Jan 9, 2020
@AkihiroSuda AkihiroSuda mentioned this pull request Jan 10, 2020
8 tasks
@AkihiroSuda
Copy link
Member Author

tracking issue: #40360

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Docker does not run with unified cgroup hierarchy
4 participants