Allows loading existing auth from kubeconfig on kube-up if a
valid KUBE_CONTEXT is specified, instead of always force
regenerating auth (basic or token) when creating a new cluster.
In order to make the etcd instances of the VMs join into a single cluster,
we used to use the discovery mechanism.
This made the cluster bootstrap dependent on an external etcd cluster instance.
74601ea replaced the dependency on discovery.etcd.io by a local etcd cluster.
This change completely gets rid of the dynamic discovery mechanism in favor
of the static configuration method.
This should be both safe and light since it completely removes the need of having
an external etcd cluster running somewhere (either discovery.etcd.io, or locally).
KUBERNETES=libvirt-coreos cluster/kube-up.sh produced the following error:
cluster/../cluster/libvirt-coreos/../../cluster/common.sh: line 83: user_args[@]: unbound variable
This was coming from the fact that, as a libvirt-coreos cluster runs locally on local VMs,
there is no authentication mechanism. This led to have user_args of common.sh unset.
In the case of libvirt-coreos, it is in fact expected to have no authentication token.
Whereas CoreOS is still shipped with etcd 0.4.9, kubernetes has moved to etcd 2.0.4.
This version mismatch makes kubernetes unable to use etcd.
Kubernetes’ logs are full of “502: (unhandled http status [Temporary Redirect] with body []) [0]”
This change makes libvirt-coreos cluster explicitly use etcd v2.0.9 instead of the one shipped within CoreOS.
This change aims at being reverted once CoreOS will migrate to etcd 2.
This migration is tracked at:
https://github.com/coreos/bugs/issues/317
Deletion is wonderful. The only weird thing was where to put the
message about the proxy URLs. Satnam suggested kubectl clusterinfo,
which seemed like a good option to put at the end of cluster turn-up.
libvirt-coreos is a cluster provider for kubernetes that starts local VMs and
runs kubernetes on it.
Its goal is to provide a multi-machines environment to develop and test kubernetes.
The purpose is mostly the same as the vagrant provider but with a big focus on
efficiency. The vagrant cluster takes a long time to boot and consumes a huge
amount of disk space. libvirt-coreos aims at being cheaper. As a consequence,
libvirt-coreos allows to start bigger clusters with more minions than vagrant.
Brad Erickson