The Kubernetes 1.3 release tarball is 1.4G. That is insane. While we know that much of this is due to the fact that we include all architectures, it make kubernetes feel heavier than it is.

Much of the space is the fact that 4 server platforms are now created and packaged with everything else. Each target is a ~325M tarball. These tarballs include both individual binaries along with Docker images that include those binaries. They include kubectl (which is available naked in the release).

We also have 9 copies of kubectl for various targets totaling 450MB.

Things we can do to slim this down:

• Start building release tars per-architecture. Either include non-arch specific stuff in every tar or break that out too. (Build release tars per-architecture #28629, owner?)
• Finish transition to hyperkube and deprecate the individual binaries. . We could move the individual binaries into a different tar for those that still need them. For amd64 hyperkube is 132M uncompressed and 26M compressed. This means we could go from a 350M compressed tar for the amd64 target down to 26M. (Finish hyperkube transition #16508, owner?)
• Have the ability to build the Docker images on the fly. It should be easy to automate (as part of the binary) creating a Dockerfile, referencing the running binary and driving docker. hyperkube admin create-container-image could do this. We could also support hyperkube admin create-container-image --aci and hyperkube admin create-container-image --docker --just-dockerfile. (Ability to build the Docker images on the fly #28630, owner?)
  • I understand that gzip does a decent job of de-duping stuff here. But the uncompressed footprint balloons and looks bad.
• Break out kubectl as a separate download from the server components. gcloud already ships it separately. The user cases here differ dramatically. (Break out kubectl as a separate download from the server components #28631, owner?)
• Reevaluate all of our targets. Do we really need 32bit Windows? (Reevaluate all of our targets. Do we really need 32bit Windows? #28632, owner?)
• 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.) (New federation target binaries add 150MB uncompressed for amd64 #28633, @madhusudancs)
• 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. (Do we need to ship the kubemark binary? #28635, owner?)

Also related: #27444 (Builds are taking too long)