Kubeadm: Package crictl in our debs/rpms so kubeadm can depend on it

[chuckha]

Problem

kubeadm runs preflight checks before it runs. One of those that is not enforced is validating the container runtime through the Container Runtime Interface (CRI).

kubeadm uses crictl info to validate the container runtime. However, if it can't find the crictl binary, kubeadm warns and give the user a suggestion for how to fix the warning and then we continue with the installation anyway.

The suggestion kubeadm provides is incomplete and difficult for users to follow.

The two problems in order of severity are:

1. go get github.com/kubernetes-incubator/cri-tools/cmd/crictl installs the latest version which may or may not match the version kubeadm is trying to install.
2. If you are unfamiliar with installing go binaries this may not be a simple command. Installation packages (yum, apt-get, etc) can be out of date.

Proposed fixes/improvements/ideas

Change the warning

If crictl is not installed, the warning should be something like "kubeadm cannot validate the container runtime satisfies the CRI. This is usually fine but should be investigated on unsupported versions of docker or other runtime interfaces (cri-o, others?)"

Improve the suggestion

The suggestion should point to the the cri-tools repo or provide more detailed instructions such as using gimme to install go and then fetching the correct version of crictl based on the version of kubeadm.

bundle crictl with kubeadm deb/rpm

This would ensure we get the right version of crictl with kubeadm.

reimplement crictl info in kubeadm

There really isn't much code to the info command. We could potentially pull this code into kubadm, but that would result in pulling in the CRI protobuf code and also Yet Another Version Management Issue. Since kubeadm works on multiple versions but the protobuf code doesn't this could get too messy to be worth it.

[chuckha]

also maybe relevant https://github.com/kubernetes/kubernetes/pull/63357 thx @luxas for having eyes everywhere

[luxas]

bundle crictl with kubeadm deb/rpm

I strongly think we should do this. crictl goes GA in v1.11, which is very good timing for us to package and bundle it by default :+1:. Then we can also depend on crictl for other things, like prepulling the images xref: #812

[luxas]

I assigned this to you @chuckha so you can see how our deb/rpm packaging works in https://github.com/kubernetes/release

[luxas]

https://github.com/kubernetes-incubator/cri-tools/pull/303 is merged so we can now download artifacts very easily from Github when building the debs/rpms :+1:

[Random-Liu]

Cool! Thanks a lot for working on this!

[feiskyer]

cool! Looking forward to it

[bart0sh]

kubeadm runs preflight checks before it runs. One of those that is not enforced is validating the container runtime through the Container Runtime Interface (CRI).

The check is confusing as having crictl installed doesn't mean that kubeadm should use it. I'd propose to quickly fix it the way similar to this, i.e. by running "crictl info" only if user specified cri socket explicitly using --cri-socket.

kubeadm uses crictl info to validate the container runtime. However, if it can't find the crictl binary, kubeadm warns and give the user a suggestion for how to fix the warning and then we continue with the installation anyway.

This is very confusing and can lead to further confusion if user installs crictl. Having crictl installed doesn't mean that runtime is functional. If it's not functional "crictl info" will fail, confusing user even more.

[luxas]

Great to see this merge for the the bazel packages. Reopening for kubernetes/release

[chuckha]

https://github.com/kubernetes/kubernetes-anywhere < need to update kubernetes-anywhere to install the cri-tools deb pkg

https://github.com/kubernetes/release < actual place to get this into the release

[luxas]

@chuckha Please don't put "Closes: #issue" in the commit message, Github don't understand how to interpret that and starts closing the issue n times as you see here :/