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
starting container "kube-proxy" fails with : mountpoint for cgroup not found #15406
Comments
@thaJeztah @asridharan From a rough look at the code, this does not seem to have to do with libnetwork, or docker. It looks it is internal to kubernetes code: Error is thrown by kubernetes/cmd/kube-proxy/app/server.go code when trying to create the proxier here, tracing it to here and then probably here |
The error with setting up the iptables does look like an kubernetes issue. But what about the cgroup mount error: "Failed to start in resource-only container "/kube-proxy": mountpoint for cgroup not found" They are not bailing out of the kube-proxy code when they encounter this error, so maybe its not that critical to the creation of kube-proxy? The relevant code piece is here |
@asridharan That one comes from libcontainer, pinging @LK4D4 for libcontainer. |
@asridharan If you found those errors by docker logs, then both of them from kubernetes. I see that it tries to setup Oom, so it should have some cgroups mounted inside container. Latest docker able to mount cgroups inside container, I'm not sure what cgroups tree expected by kube-proxy, though. Maybe @thockin knows. |
Looks like all the errors are contained within the kubernetes code-base. I will move this issue to kubernetes in that case. |
thanks all! closing this one, and hope you find a solution :-) |
Description of problem
I am trying to run kubernetes on a docker-based local setup using the following instructions:
http://kubernetes.io/v1.0/docs/getting-started-guides/docker.html
NOTE: Although the problem is with starting kubernetes, I am filling this issue with docker since looks like the issue is with docker not being able to start a specific container.
All the kuberenetes containers start cleanly, except the "kube-proxy" container.
On looking at the output of the kube-proxy container, looks like the remote API is throwing a error while launching the container:
This is a bit odd, cause all the cgroup mounts seem to be in place:
Also, there doesn't seem to be an issue with starting any of the other containers. The only difference, I could see, in starting the kube-proxy container versus the other containers (etcd, api-server, scheduler) is that kube-proxy needs to be run with --priveleged . However, I did try running a ubuntu container with --privileged and it seems to be coming up fine.
docker version
:Client version: 1.7.1
Client API version: 1.19
Go version (client): go1.4
Git commit (client): 786b29d
OS/Arch (client): linux/amd64
Server version: 1.7.1
Server API version: 1.19
Go version (server): go1.4
Git commit (server): 786b29d
OS/Arch (server): linux/amd64
docker info
:Containers: 9
Images: 97
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 115
Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 3.18.4-aufs
Operating System: Gentoo/Linux
CPUs: 4
Total Memory: 3.862 GiB
Name: stitchserver
ID: NSPJ:6OQ3:FURV:IIES:UIEA:WO65:P3QG:SW2N:NFA6:UTBW:ATHA:4XLF
uname -a
:Linux stitchserver 3.18.4-aufs #4 SMP Thu Aug 6 10:53:19 PDT 2015 x86_64 QEMU Virtual CPU version 2.1.0 GenuineIntel GNU/Linux
Environment details (AWS, VirtualBox, physical, etc.):
Gentoo VM, running a custom kernel. Ran the check-confish.sh script to make sure all kernel configs are turned on:
How reproducible:
Every time.
Steps to Reproduce:
Actual Results:
kube-proxy container fails to start
Expected Results:
kube-proxy should start and configure the iptables with the right entries.
Additional info:
This could be something specific to Gentoo. I am not seeing other users (on Ubuntu for e.g.,) complaining about kubernetes not starting. I am actively discussing this issue with the kubernetes developers as well, but seems like they are also not able to triage the issue cleanly since the problem is with starting the container itself.
The text was updated successfully, but these errors were encountered: