A new option, --enable-registry, has been added for starting a local, private registry.
This registry will be shared between all the k3d clusters created with --enable-registry.
The registry container will be removed when the last of them is removed.
Two extra options, --registry-name and --registry-port, have been included for specifying
the hostname and port where the registry will be available.
Signed-off-by: Alvaro Saurin <alvaro.saurin@gmail.com>
The kubeconfig generated by docker.io/rancher/k3s:v0.10.2 or earlier
sets the cluster.server address to 127.0.0.1. Previously this seems to
have been localhost. And we only replace localhost with the correct
address for our local kubeconfig.
The error this can lead to:
```
$ k3d --version
k3d version v1.3.4
$ docker-machine --version
docker-machine version 0.16.1, build cce350d7
$ docker --version
Docker version 19.03.1, build 74b1e89
$ k3d create
INFO[0000] Created cluster network with ID 649d6f34b84a4df16d2524f0ea0ce69cd4f964a79ae56e2a07bb1ee11d1fce50
INFO[0001] Add TLS SAN for 192.168.99.100
INFO[0001] Created docker volume k3d-k3s-default-images
INFO[0001] Creating cluster [k3s-default]
INFO[0001] Creating server using docker.io/rancher/k3s:v0.10.2...
INFO[0001] Pulling image docker.io/rancher/k3s:v0.10.2...
INFO[0018] SUCCESS: created cluster [k3s-default]
INFO[0018] You can now use the cluster with:
export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
kubectl cluster-info
$ export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"
$ kubectl cluster-info
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
The connection to the server 127.0.0.1:6443 was refused - did you specify the right host or port?
```
If you are writing a script to launch k3s clusters checking the exit
code of `get-kubeconfig` is an easy way to tell if the kubeconfig is
available for use.
