aojea
commented
1 year ago /assign @BenTheElder
Open treatmesubj opened 1 year ago
aojea
commented
1 year ago /assign @BenTheElder
BenTheElder
commented
1 year ago It would certainly be easier to just suggest users enable systemd. The container ecosystem is largely tested with systemd and we do not have WSL2 CI available #1529.
wallrj
commented
11 months ago Thanks for creating this issue and for the link to the "enabling systemd" documentation.
It fixed the problem for me.
The problem only started occurring today after I carelessly ran apt update && apt upgrade which must have upgraded docker.
kind had previously worked very well without using systemd and with me manually running sudo dockerd & in a separate terminal.
$ docker version
Client:
Version: 24.0.5
API version: 1.43
Go version: go1.20.3
Git commit: 24.0.5-0ubuntu1~22.04.1
Built: Mon Aug 21 19:50:14 2023
OS/Arch: linux/amd64
Context: default
Server:
Engine:
Version: 24.0.5
API version: 1.43 (minimum version 1.12)
Go version: go1.20.3
Git commit: 24.0.5-0ubuntu1~22.04.1
Built: Mon Aug 21 19:50:14 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.7.2
GitCommit:
runc:
Version: 1.1.7-0ubuntu1~22.04.1
GitCommit:
docker-init:
Version: 0.19.0
GitCommit:$ wsl.exe --version
WSL version: 2.0.11.0
Kernel version: 5.15.133.1-1
WSLg version: 1.0.59
MSRDC version: 1.2.4677
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22621.2715Can you share more about the VM environment, what init is running, what does "docker info" output (eg we want to know about the cgroups)
kind has code to ensure this path if not created by the host but I guess even priv container is not getting permission in this environment.
wallrj
commented
11 months ago @BenTheElder I disabled systemd again and got the following info. Hope it helps.
BenTheElder
commented
11 months ago Thanks, I don't understand why this is happening. We should be forcing cgroupns=private with kind v0.20.0+ and therefore /sys/fs/cgroup should be namespaced and we should be able to manipulate it as a privileged container.
I suspect that's a bad assumption versus privileged + hostns and instead we're back to relying on the host systemd to ensure the top level mounts exist and #3277 may be ~the same root cause ...?
Unfortunately still not going to get a chance to dig in for a bit and probably not on windows but maybe on alpine
syNack0
commented
4 months ago Any news about this?
BenTheElder
commented
4 months ago @syNack0 no, or else there would be a comment here.
The maintainers do not use windows. If someone with this issue can upload the logs as per the bug template we can look at those.
kind create cluster --retain
kind export logs
kind delete cluster(Also nobody has worked on solving the windows CI problem #1529 so we rely entirely on windows-interested contributors)
wallrj
commented
4 months ago In https://github.com/kubernetes-sigs/kind/issues/3304#issuecomment-1833121421 @BenTheElder wrote:
Thanks, I don't understand why this is happening. We should be forcing cgroupns=private with kind v0.20.0+ and therefore /sys/fs/cgroup should be namespaced and we should be able to manipulate it as a privileged container.
I stumbled across the following answer in https://stackoverflow.com/a/73376219 by @Domest0s and thought it might be relevant:
By default, cgroup2 will likely be mounted at /sys/fs/cgroup/unified. Some apps might not like it (docker in particular). Move it to the conventional place with: $ mount --move /sys/fs/cgroup/unified /sys/fs/cgroup
BenTheElder
commented
4 months ago By default, cgroup2 will likely be mounted at /sys/fs/cgroup/unified. Some apps might not like it (docker in particular). Move it to the conventional place with: $ mount --move /sys/fs/cgroup/unified /sys/fs/cgroup
Ok yeah that is weird, usually you only see that path on a systemd host that has BOTH v1 and v2 mounted ("hybrid" mode; which ... I don't recommend). /sys/fs/cgroup is the normal path in either "unified" (v2) or "legacy" (v1) mode.
It's possible that may fix things, are we sure it's not "hybrid" mode systemd though? Or is this the default WSL2 init system (don't know much about that one yet)
BenTheElder
commented
4 months ago
What would you like to be documented: On WSL2, System D is not enabled by default, but can be easily enabled Docker doesn't require System D, but KinD relies on it, I guess. Without System D enabled, KinD serial logs will show
Why is this needed: KinD has WSL2 docs, but they don't mention this as a an easy fix/requirement