- enables wait-for-master
- calls GetAndWriteKubeConfig after successful cluster creation to
update the default kubeconfig with the new cluster's details
- does NOT automatically switch the current-context
- outputs a different line saying, that you can switch context now
- imageVolume couldn't be determined before in some cases, because it
tried to extract the name from labels on the masterlb which doesn't have
them.
- now we're only trying get the label from master/worker nodes and this
also adds a failover solution
- also, we ignore non-worker/master nodes upon image import
Before this change, we simply did a search/replace on the
stringified kubeconfig blob.
Now we're parsing it into a kubeconfig struct and modify the fields
directly in a more controlled manner.
Here's what we change:
- server URL: based on the chosen APIHost and APIPort
- cluster name: default -> k3d-CLUSTERNAME
- user name: default -> admin@k3d-CLUSTERNAME
- context name: default -> admin@k3d-CLUSTERNAME
With the updated cobra depencendy, we're now passing a context
from the cmd to the called functions.
When creating a cluster, one can pass a Duration to the --timeout
flag, which will create a new context with a timeout.
In the two blocking functions, where we're waiting for the master nodes
(initializing master nodes and "normal" master nodes), we're now
checking for the context cancellation as well, which may be caused
by the timeout.
To prevent accidental rollbacks of existing clusters with the same name,
we now check if a cluster with the chosen name exists first.
If it exists, we don't do anything at all and just error our
Up to now, we exposed ports on single master nodes, which is quite
inconvenient on user side and troublesome on development side.
Now, we're creating a proxy container which exposes a single port
and proxies traffic to all master nodes.
Currently, this only works with 'k3d create cluster' and won't
update the proxy when using 'k3d create node --role master'.