Issue 1:
Bringing up a cluster using the new Multiple-AZ Support fails on AWS. The first part of the cluster comes up but we fail on bringing up the second set of nodes. Below is the config to start up:

# this part succeeds
export KUBERNETES_PROVIDER=aws
KUBE_AWS_ZONE=us-west-2a kube-up.sh

# this command fails with: Could not detect Kubernetes master node IP. Make sure you've launched a cluster with 'kube-up.sh'
KUBE_AWS_ZONE=us-west-2b KUBE_SUBNET_CIDR=172.20.1.0/24 KUBE_USE_EXISTING_MASTER=true kube-up.sh

And here is the log of the failure to bring up the second set of nodes:

Creating autoscaling group
0 minions started; waiting
0 minions started; waiting
0 minions started; waiting
0 minions started; waiting
2 minions started; ready
Sanity checking cluster...
Attempt 1 to check Docker on node @ <someIP> ...not working yet
Attempt 2 to check Docker on node @ <someIP> ...not working yet

Attempt 3 to check Docker on node @ <someIP> ...not working yet
Attempt 4 to check Docker on node @ <someIP> ...not working yet
Attempt 5 to check Docker on node @ <someIP> ...not working yet
Attempt 6 to check Docker on node @ <someIP> ...not working yet

Attempt 7 to check Docker on node @ <someIP> ...not working yet
Attempt 8 to check Docker on node @ <someIP> ...not working yet
Attempt 9 to check Docker on node @ <someIP> ...not working yet
Attempt 10 to check Docker on node @ <someIP> ...not working yet
Attempt 11 to check Docker on node @ <someIP> ...not working yet

Your cluster is unlikely to work correctly.
Please run ./cluster/kube-down.sh and re-create the
cluster. (sorry!)

Issue 2:
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. (#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. (#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. (#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. (#28631, owner?)

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.) (#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. (#28635, owner?)

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