kubeadm shouldn't depend on a specific shell or binary inside the control plane image

[luxas]

ref: kubernetes/kubernetes#40248

It seems like the shift towards FROM scratch images are coming soon, and we should make sure kubeadm doesn't break.

What we have to do:

• Specify full paths to the binary we invoke. For the control plane images, this is /usr/local/bin/kube-*, also when hyperkube is used.
• Do not rely on other binaries in the image(s)

cc @timstclair @jessfraz @thockin @mikedanese @pires @errordeveloper

[pires]

When will the scratch images land in Kubernetes?

[luxas]

@timstclair ^

[timstclair]

I just posted an update over in kubernetes/kubernetes#40248 (comment), but wanted to clarify here: only images based on a static go binary with no external dependencies will be moved to scratch. Hyperkube has lots of external dependencies, and will be based off the Debian base image. Does kubeadm have dependencies?

[luxas]

@timstclair The main question for me at least is; Are the server images (kube-apiserver, kube-scheduler, kube-controller-manager) gonna be based FROM scratch in v1.6?
Is the plan to make them FROM scratch in a future version (v1.7, v1.8)?

[timstclair]

Possibly. I have not yet triaged those images to know whether rebasing on scratch would be trivial. I'm currently prioritizing images that run on the nodes, so if anyone is interested in helping out with the efforts on master images it would be welcome :)

In terms of timeline, I'm not targeting any master images for 1.6 (again, help welcome), but we may update a few on an as-needed basis (e.g. kubernetes-retired/contrib#2390). I don't want to officially commit, but we'll probably target master images for 1.7.

[luxas]

@timstclair Ok. We're just thinking about whether we can/should rely on the flock binary inside the busybox or not. Opinion on that? If we go to scratch we can't, but generally it's a mess to rely on binaries inside of images -- for example -- the busybox and debian flock binaries behave differently and are in different folders.

But I'd like your input on whether we should find a real solution at once and don't depend on flock inside the master images at all or...

[timstclair]

Unless it's a fairly trivial to reimplement the behavior in go, I don't think the decision of whether to depend on an external binary should be gated on the decision of base image. That said, what does the flock binary offer that can't be translated into an os.Flock syscall?

[pires]

@timstclair the problem is flock needs to run as part of the command that runs each component, e.g. flock <args> apiserver <args>.

[mikedanese]

Why do we need flock?