hyperkube images take forever to build #35058
Comments
|
cc @aaronlevy @colemickens @david-mcmahon (not really sure who "owns" hyperkube, if anyone) |
david-mcmahon
added
the
help wanted
|
The hyperkube binary is one thing. I think the image ends up being big as we drag in so much stuff. I wasn't involved in creating the docker image so I can't comment. Ideally this thing would be slim and would have minimal external dependencies. Fixing this starts with mapping why we have each of those deps imported. |
pwittrock
added
area/release-eng
|
I actually have written a such patch in my local env, but I never uploaded. Also, we will come one step closer once #30356 is in. Should I submit the patch so you can take a look at it? |
sure! |
|
@ixdy This needs to be triaged as a release-blocker or not for 1.5 |
|
punting to v1.6. |
|
The main problem here is that we're installing huge packages for supporting some volume types:
With containerized volume mounters we'll get rid of that. |
|
When it comes to local rebuilding, #40011 should help here. As I've already noted in the PR, maybe we should make CACHEBUST=0 the default for all hack/dev-xxx.sh scripts. This would at least ease development and testing. |
|
@ixdy can this be closed? or moved to 1.7? |
|
@ixdy should this be in v1.7? is there an appropriate sig to own this? |
|
cries nope, not v1.7. I'm still not sure who owns hyperkube. |
|
Everyone and no one I suppose. Yeah, agree it's sad. |
k8s-github-robot
added
the
needs-sig
|
/sig release |
k8s-ci-robot
added
the
sig/release
k8s-github-robot
removed
the
needs-sig
|
@spiffxp Yeah, hyperkube definitely belongs to sig-release as it hasn't been owned by a sig so far... |
Automatic merge from submit-queue (batch tested with PRs 48365, 49902, 49808, 48722, 47045) Rebase hyperkube image on debian-hyperkube-base, based on debian-base. **What this PR does / why we need it**: saves all of the hyperkube image dependencies in a cacheable base image, rather than downloading them for every build (which is slow and flaky). This way, at build time, we only need to pull down the hyperkube base image and add the hyperkube binary. I've additionally based the base image on `debian-base` instead of `debian`, though we amusing end up reinstalling a bunch of the things we removed in `debian-base`. **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #35058, at least partially **Special notes for your reviewer**: I'm increasingly convinced that the hyperkube image is a bad pattern, as this image carries the superset of dependencies anyone might need, rather than the limited set of dependencies one needs. hyperkube really needs a proper owner. **Release note**: ```release-note ``` /assign @timstclair @luxas @philips @nikhiljindal cc @kubernetes/sig-release-pr-reviews
I'm pretty sure that building the hyperkube images takes longer than building kubernetes itself now.
At least a large part of this seems to be that we download and install ~172 extra debian packages several times (once for each arch).
Not sure how to improve this - maybe better caching? Do we actually want to install these extra packages? Should we use a better base image than
debian:jessie?cc @jbeda @luxas
The text was updated successfully, but these errors were encountered: