Low priority of course, but in case you’re not aware we can’t run Kubernetes under Docker for Mac.
1 Like
I have had success reports actually. Instructions to reproduce the failure would be useful.
The following docker-compose config fails to start the Kubelet with the error “[Failed to start ContainerManager [open /proc/sys/vm/overcommit_memory: read-only file system, open /proc/sys/kernel/panic: read-only file system, open /proc/sys/kernel/panic_on_oops: read-only file system]]”
version: '2'
services:
etcd:
image: gcr.io/google_containers/etcd:2.2.1
restart: always
ports:
- 4001:4001
volumes:
- ./volumes/etcd:/var/etcd
command: >
/usr/local/bin/etcd
--listen-client-urls=http://0.0.0.0:4001
--advertise-client-urls=http://0.0.0.0:4001
--data-dir=/var/etcd/data
kubelet:
image: gcr.io/google_containers/hyperkube-amd64:v1.2.2
restart: always
privileged: true
network_mode: host
pid: host
volumes:
- ./volumes/kubelet:/etc/kubernetes/manifests
- /var/lib/kubelet:/var/lib/kubelet
- /var/lib/docker:/var/lib/docker:rw
- /var/run:/var/run:rw
- /sys:/sys:ro
- /:/rootfs:ro
command: >
/hyperkube kubelet
--containerized=true
--address="0.0.0.0"
--allow-privileged=true
--enable-server
--api-servers=http://localhost:8080
--config=/etc/kubernetes/manifests
--hostname-override="localhost"
--cluster-dns=10.0.0.10
--cluster-domain=cluster.local
--v=1
proxy:
image: gcr.io/google_containers/hyperkube-amd64:v1.2.2
restart: always
network_mode: host
privileged: true
command: >
/hyperkube proxy
--master=http://localhost:8080
--v=1
apiserver:
image: gcr.io/google_containers/hyperkube-amd64:v1.2.2
restart: always
links:
- etcd
ports:
- 8080:8080
command: >
/hyperkube apiserver
--service-cluster-ip-range=10.0.0.0/16
--insecure-bind-address=0.0.0.0
--insecure-port=8080
--etcd-servers=http://etcd:4001
--admission-control=NamespaceLifecycle,InitialResources,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota
--min-request-timeout=300
--allow-privileged=true
--runtime-config=extensions/v1beta1=true,extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true
--logtostderr=true
--v=1
controller-manager:
image: gcr.io/google_containers/hyperkube-amd64:v1.2.2
restart: always
links:
- apiserver
command: >
/hyperkube controller-manager
--master=http://apiserver:8080
--terminated-pod-gc-threshold=100
--min-resync-period=3m
--v=1
scheduler:
image: gcr.io/google_containers/hyperkube-amd64:v1.2.2
restart: always
links:
- apiserver
command: >
/hyperkube scheduler
--master=http://apiserver:8080
--v=1
I think that may have been a known issues with last week’s docker release candidate. We are preparing a new beta today, if you could re-test after the update that would be helpful.
More information from @feelobot
http://kubernetes.io/docs/getting-started-guides/docker/ if you run that the api server isn't able to connect even when changing to docker.local:8080
I0413 18:36:43.178340 2387 kubelet.go:2255] skipping pod synchronization - [Failed to start ContainerManager [open /proc/sys/vm/overcommit_memory: read-only file system, open /proc/sys/kernel/panic: read-only file system, open /proc/sys/kernel/panic_on_oops: read-only file system]]
E0413 18:36:46.100370 2387 event.go:201] Unable to write event: 'Post http://docker.local:8080/api/v1/namespaces/default/events: dial tcp: lookup docker.local: no such host' (may retry after sleeping)
I0413 18:17:07.382523 2101 kubelet.go:2618] Recording NodeHasSufficientDisk event message for node 127.0.0.1
I0413 18:17:07.384496 2101 kubelet.go:1069] Attempting to register node 127.0.0.1
I0413 18:17:07.386417 2101 kubelet.go:1072] Unable to register 127.0.0.1 with the apiserver: Post http://localhost:8080/api/v1/nodes: dial tcp 127.0.0.1:8080: connection refused
Thanks! 
Those errors are from the rc, known issue. If you could retry with the new beta that would help.
I am still seeing the unable to register errors. Is there a setting wrong in the yml posted or do you have an example of a correct config or steps to get it running?
Hey folks,
I’ve been able to run it actually, please take a look here: https://github.com/weaveworks/kubernetes-anywhere/blob/master/DOCKER_FOR_MAC.md
Do let me know if you have more questions (file issues, or ask here), as docs are still quite fresh.
Best,
Ilya
1 Like
Thank you. It might be nice to detail how to launch your own pods, etc as it is not clear what is mounted where and from where.
I tried the original way to run kubernetes as docker containers and encountered a strange not implemented error. The Kube itself is up and running and responds to kubctl. But running a simple busybox pod hangs at ContainerCreating with the followings message:
{kubelet 127.0.0.1} Warning FailedMount Unable to mount volumes for pod “busybox_default(d4bf38aa-0fa1-11e6-8863-1ec090dbf22e)”: statfs(“/var/lib/kubelet/pods/d4bf38aa-0fa1-11e6-8863-1ec090dbf22e/volumes/kubernetes.io~secret/default-token-g4bjq”): function not implemented
Could it be that statfs() really isn’t implemented?
@errordeveloper looks good, tried it and managed to create the cluster, configured kubectl to point there from Mac’s machine. Can’t figure out how to see services from a browser though. Any hints on a port connectivity mecanisms (outside the docker context - e.g. chrome)?
2 Likes
statfs is currently not implemented in shared volumes, we are still working on that.
1 Like
I don’t believe /var/lib/kubelet/pods/d4bf38aa-0fa1-11e6-8863-1ec090dbf22e/volumes/kubernetes.io~secret/default-token-g4bjq should be on a shared volume unless kubernetes is doing something odd.
1 Like
@spiddy Kubernetes (via kubectl proxy) provides URL prefixes for you.
Here is the gist:
http://localhost:8081/api/v1/proxy/namespaces/<namespace_name>/services/<service_name>[:port_name]
Thanks, that would work. I tried restarting the service and now I get the following error:
➜ ~ docker run \
> --volume="/:/rootfs" \
> --volume="/var/run/weave/weave.sock:/docker.sock" \
> weaveworks/kubernetes-anywhere:toolbox-v1.2 \
> sh -c 'setup-single-node && compose -p kube up -d'
Creating data volumes container for kubelet (`kubelet-volumes`)...
Docker container `kubelet-volume` aleady exists
Calling `mount --make-rshared /` to ensure `kubelet-volumes` is functional
Service "kubelet" mounts volumes from "kubelet-pki", which is not the name of a service or container.
any hints?
1 Like
@spiddy I’ve seen this once earlier, it’s a bit odd, but I have not managed to reproduce it. To reset, please use docker run ... weaveworks/kubernetes-anywhere:toolbox-v1.2 reset-single-node. I’m testing an up/down wrap at the moment, if you are interested to try it out…
I am having some occasional success with it but it seems a little brittle, especially with suspend resume.
Looks like the kublet container is not coming up either after resume or if you exit docker for mac and relaunch. It is exiting with a status of 2 and I am not seeing anything obvious in the logs