$ du -sh server/bin/*
99M     server/bin/federation-apiserver
4.0K    server/bin/federation-apiserver.docker_tag
100M    server/bin/federation-apiserver.tar
57M     server/bin/federation-controller-manager
4.0K    server/bin/federation-controller-manager.docker_tag
58M     server/bin/federation-controller-manager.tar
132M    server/bin/hyperkube
105M    server/bin/kube-apiserver
4.0K    server/bin/kube-apiserver.docker_tag
106M    server/bin/kube-apiserver.tar
95M     server/bin/kube-controller-manager
4.0K    server/bin/kube-controller-manager.docker_tag
97M     server/bin/kube-controller-manager.tar
54M     server/bin/kubectl
48M     server/bin/kube-dns
103M    server/bin/kubelet
101M    server/bin/kubemark
49M     server/bin/kube-proxy
4.0K    server/bin/kube-proxy.docker_tag
178M    server/bin/kube-proxy.tar
57M     server/bin/kube-scheduler
4.0K    server/bin/kube-scheduler.docker_tag
58M     server/bin/kube-scheduler.tar

If the point of the release is for end-users to turn up a kubernetes cluster, do they even need the binaries? Why not just give them the image?

I also think it makes sense to split the release up by server architectures.

@david-mcmahon

Some previous discussion here: #9253 Apparently some of the duplication is/was for CoreOS?

Although kube-up uses this tarball, there's no need to: the expanded files are also available for direct download (kubectl, kubelet), and gcr.io has all the images.

I'm very interested in this and have done some (small) improvements already.

hyperkube admin xxx

Do you have a proposal for which commands admin would have? I'm a huge +1 on a such tool.
That would remove some of the duplication from various deployments in favor for a canonical one, written in go.

Reevaluate all of our targets. Do we really need 32bit Windows?

I've been thinking about if we should deprecate 386 builds in v1.4 and remove them in v1.5.
If we're doing other dramatic changes (like the hyperkube transition), then we might remove them now already.

Why are the federation targets new binaries? They add 150M uncompressed for amd64. (I don't know enough to say here but could these be folded in to hyperkube? I'm guessing they could.)

The federation binaries are already inside hyperkube. The individual binaries was likely added in order to comply with current standards (separate binary + bundle in hyperkube)
cc @kubernetes/sig-cluster-federation

Don't ship binaries that we don't really need. We included kubemark here. No end users will actually use that. This is 100M uncompressed.

This has also been brought up before, I think. I'd prefer moving it to a test target.
cc @kubernetes/sig-testing

@kubernetes/sig-cluster-lifecycle folks might also be interested in this.

cc @roberthbailey

So I just came across this (while downloading the 1.3.0 binaries) and I agree that this is completely ridiculous. We need an owner for this issue for 1.4.

@david-mcmahon Can we stick you with this for 1.4?

I think this falls under @david-mcmahon and the release infra area, so proactively assigning -- David, let us know if you disagree.

I think this is also interesting to install, because downloading a 1.4GB tarball that extracts to 3+GB is a relatively sad install process.

There may be short-term expedient things we could do, e.g. building multiple tar balls with only linux x86-64 or srcs while still supporting the one-big-ball, in addition to hyperkube-style minified builds.

We explode those tars in GCS. We should document how to pull specific pieces of the release.

https://gist.github.com/mikedanese/d3eed580c7f0a0e5c13534220f88eb5a

This looks like a huge meta-issue with several solutions affecting many areas of the product.

If we all agree on @jbeda 's suggested solutions, each should be broken out into their own bug (grouped where appropriate) and assigned.

Many of these solutions potentially have product/user/usability ramifications and need the attention of the area owner(s).

I'll make a first pass at the original list. Others feel free to add/update.

I am unlikely to have the bandwidth to drive this further this quarter or before 1.4. Area leads should be assigning the subtasks @jbeda identified and I filed issues for to get this done before 1.4. @thockin @mikedanese @davidopp @luxas @quinton-hoole @alex-mohr. Please cc anyone I've missed.

@ixdy work on this will move to 1.6? (This needs to be triaged as a release-blocker or not for 1.5)

If I understand correctly, @ixdy has already made some improvements by splitting the monotarball out to one tarball per arch.

But I think there's work left to do, so moving to v1.6

@ixdy can this be closed?

pre-existing for 1.6, not a release blocker

[MILESTONENOTIFIER] Milestone Labels Incomplete

@ixdy @jbeda

Action required: This issue requires label changes. If the required changes are not made within 6 days, the issue will be moved out of the v1.8 milestone.

kind: Must specify at most one of ['kind/bug', 'kind/feature', 'kind/cleanup'].

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Is anyone from @kubernetes/sig-release-feature-requests working on this feature request?

Since 1.6 or so, we've had separate per-arch tarballs, and the main one is only a few MB with a script to download only the arch you're running on. I haven't heard any complaints about tarball size since then.

Should we close this then?

Close enough. I'm closing it. Victory is ours!