-
Notifications
You must be signed in to change notification settings - Fork 715
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
kubeadm shouldn't depend on a specific shell or binary inside the control plane image #167
Comments
When will the scratch images land in Kubernetes? |
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? |
@timstclair The main question for me at least is; Are the server images ( |
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. |
@timstclair Ok. We're just thinking about whether we can/should rely on the 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... |
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 |
@timstclair the problem is flock needs to run as part of the command that runs each component, e.g. |
Why do we need flock? |
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:
/usr/local/bin/kube-*
, also when hyperkube is used.cc @timstclair @jessfraz @thockin @mikedanese @pires @errordeveloper
The text was updated successfully, but these errors were encountered: