Kubernetes v1.11 doesn't respect alternative container-runtime (cri-o)

[afbjorklund]

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

BUG REPORT

Please provide the following details:

Environment:

• Minikube version (use minikube version):
  v0.28.2-dirty
• OS (e.g. from /etc/os-release):
  Ubuntu
• VM Driver (e.g. cat ~/.minikube/machines/minikube/config.json | grep DriverName):
  kvm2
• ISO version (e.g. cat ~/.minikube/machines/minikube/config.json | grep -i ISO or minikube ssh cat /etc/VERSION):
  v0.28.1-dirty
• Install tools:

What happened:

Still used dockerd

What you expected to happen:

Use crio instead

How to reproduce it (as minimally and precisely as possible):

minikube start --kubernetes-version=v1.11.0 --network-plugin=cni --container-runtime=cri-o --extra-config=kubelet.container-runtime=remote --extra-config=kubelet.container-runtime-endpoint=/var/run/crio/crio.sock --extra-config=kubelet.image-service-endpoint=/var/run/crio/crio.sock

Output of minikube logs (if applicable):

[preflight] Some fatal errors occurred:
	[ERROR Service-Docker]: docker service is not active, please run 'systemctl start docker.service'
	[ERROR SystemVerification]: failed to get docker info: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`

Anything else do we need to know:

Worked OK with v1.10.0

Apparently there is some new cri socket config added, that is still pointing to the wrong thing.

[afbjorklund]

The new required config is:
criSocket: /var/run/crio/crio.sock

Otherwise it will default to:
criSocket: /var/run/dockershim.sock

And then it will complain if docker is not installed and dockerd is not running,
and otherwise start pulling images into docker instead of using the crio ones.

https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-init/#use-kubeadm-with-other-cri-runtimes

You may also want to set --cri-socket to kubeadm init and kubeadm reset when using an external CRI implementation.

Apparently this one also got promoted from a "may also want" to "need",
similar to how crictl got promoted from just a WARNING to an ERROR.

[jayunit100]

seeing this on the version from 11 days ago:

[vagrant@localhost vagrant]$ minikube start --network-plugin=cni --container-runtime=crio --vm-driver=none
Starting local Kubernetes v1.10.0 cluster...
Starting VM...
E1017 00:53:22.002447   25001 start.go:168] Error starting host: Error creating host: Error executing step: Running precreate checks.
: docker cannot be found on the path for this machine. A docker installation is a requirement for using the none driver: exec: "docker": executable file not found in $PATH.

 Retrying.
E1017 00:53:22.005557   25001 start.go:174] Error starting host:  Error creating host: Error executing step: Running precreate checks.
: docker cannot be found on the path for this machine. A docker installation is a requirement for using the none driver: exec: "docker": executable file not found in $PATH

[jayunit100]

pretty sure this happens w/ any minikube, as i think the docker check happens even before the kube version is specified. I trie 1.9, 1.0, and evan --kubernetes-version1=.11z and in all cases the same missing docker failures happen.

Is there a version of minikube that we can run that is known to properly order the check for dockeer?

[afbjorklund]

Currently minikube is based on libmachine, which means that docker is always installed.
But if you apply this patch first, it should not be needed by kubeadm any longer ?

[jayunit100]

So, I'm using the none driver, and in the comments to the code - it sais its a hard requirement to have docker if using the none driver.

[afbjorklund]

You shouldn't need to have docker, if you are running with another container runtime (like crio)...
It is a bug, when kubeadm is looking for it at "init" or when caching tries to "load" images with docker.

[afbjorklund]

@jayunit100:
The check you are quoting (docker on path) does indeed seem to be older (than v1.11.0)
The check referenced in this issue is only when the docker service has not been started...

So it needs a different fix, by addressing: cb8d3c0
There are other hardcodings there too, like "stop".
Open new issue ?