Change:
# Build the hyperkube image. # # Usage: <del> #   [ARCH=amd64] [REGISTRY="gcr.io/google_containers"] make (build|push) VERSION={some_released_version_of_kubernetes} </del> <ins> #   [ARCH=amd64] [REGISTRY="gcr.io/google-containers"] make (build|push) VERSION={some_released_version_of_kubernetes} </ins> <del> REGISTRY?=gcr.io/google_containers </del> <ins> REGISTRY?=gcr.io/google-containers </ins> ARCH?=amd64 <del> TEMP_DIR:=$(shell mktemp -d -t hyperkubeXXXXXX) CNI_RELEASE=0799f5732f2a11b329d9e3d51b9c8f2e3759f2ff CACHEBUST?=1 QEMUVERSION=v2.7.0 HYPERKUBE_BIN?=_output/dockerized/bin/linux/${ARCH}/hyperkube HOSTARCH?=amd64 UNAME_S:=$(shell uname -s) ifeq ($(UNAME_S),Darwin) SED_CMD?=sed -i "" endif ifeq ($(UNAME_S),Linux) SED_CMD?=sed -i endif </del> <ins> HYPERKUBE_BIN?=_output/dockerized/bin/linux/$(ARCH)/hyperkube </ins> <del> ifeq ($(ARCH),amd64) BASEIMAGE?=debian:jessie endif ifeq ($(ARCH),arm) BASEIMAGE?=armhf/debian:jessie QEMUARCH=arm endif ifeq ($(ARCH),arm64) BASEIMAGE?=aarch64/debian:jessie QEMUARCH=aarch64 endif ifeq ($(ARCH),ppc64le) BASEIMAGE?=ppc64le/debian:jessie QEMUARCH=ppc64le endif ifeq ($(ARCH),s390x) BASEIMAGE?=s390x/debian:jessie QEMUARCH=s390x endif </del> <ins> BASEIMAGE=gcr.io/google-containers/debian-hyperkube-base-$(ARCH):0.1 TEMP_DIR:=$(shell mktemp -d -t hyperkubeXXXXXX) </ins> all: build

Discussion:
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). <details</detailsNot 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 ? cc
cc (not really sure who "owns" hyperkube, if anyone)
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.
I actually have written a such patch in my local env, but I never uploaded. It removed the docker and docker-multinode-specific stuff and all the unused deps. Also, we will come one step closer once is in. Should I submit the patch so you can take a look at it?
sure!
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: git nfs-common glusterfs-client cifs-utils With containerized volume mounters we'll get rid of that.
When it comes to local rebuilding, should help here. As I've already noted in the PR, maybe we should make CACHEBUST=0 the default for all hack/dev- scripts. This would at least ease development and testing.
can this be closed? or moved to 1.7?
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.
/sig release guess we're saying sig-release owns hyperkube under the general guise of "cutting bits" until/unless there is a better home for it
Yeah, hyperkube definitely belongs to sig-release as it hasn't been owned by a sig so far...