Kubernetes project has decided that it is better if kubelet
and kube-proxy use the apiserver REST interface to get and
set resources instead of accessing resource keys in etcd directly.
This is necessary to support kubelet reporting of events,
and also encapsulates the apiserver store details.
This means that the kubelet and kube-proxy need to know the
apiserver host(s) via a flag.
Since the Rackspace config already used etcd to advertise the
minions to the controller-manager, I used the same pattern to advertise
the apiserver(s) to the minions.
Setting --public_address_override=$private_ipv4 is intended to ensure that
the master serves its http interface on the right ethernet device, since I think
there are two on a droplet.
The new apiserver-advertiser.service puts the IPs of any apiservers in etcd.
The kubelet and kube-proxy now take an environment file which contains
the list of apiserver IPs, and that env var goes into a flag. The
etcd_servers argument is removed -- the point is for these binaries
to not access etcd.
The new apiserver-finder.service watches for changes in etcd and
restarts kubelet and kube proxy when there are new apiservers.
Fixes#8196. Maybe. If my theory is correct on how we got there. Also
changes the inference of master to be based on the master name, not
the node instance prefix. That way if we somehow have a bogus
hostname, the master will configure itself as a node, the whole
cluster fails, and it's a ton more obvious.
When MASTER_RESERVED_IP is set to elastic IP from AWS, then aws/util.sh will
associate it with master instance and assign it to KUBE_MASTER_IP. If no MASTER_RESERVED_IP
is set, new elastic ip will be requested from amazon. This allows cluster certificates to
be generated for an IP that doesn't change between stopping & starting cluster instances.
The requested elastic ip is not released when kube-down.sh is run. I think it is good
because user could have created DNS records and it would be bad if the IP was removed.
He can reuse it next time through MASTER_RESERVED_IP when setting up cluster again.
The latest salt version breaks the container_bridge.py _state function
We can lock to the same version as GCE. This is not a full fix,
because we can't update to the latest salt without breaking GCE,
but this at least unbreaks and sync AWS with GCE.
This isn't a straight copy from GCE, because we still use
the salt master on AWS (for now)
Fixes#8114
