kubeone reset fails when LB is not functioning

[kron4eg]

$ kubeone reset -v config.yaml -t tf.json
INFO[17:47:27 EEST] Resetting cluster…
INFO[17:47:27 EEST] Destroying worker nodes…
INFO[17:47:27 EEST] Building Kubernetes clientset…
Error: unable to build kubernetes clientset: unable to build dynamic client: unable to build dynamic client: Get https://artioms-api-lb-c768cdec4dc7974a.elb.eu-west-3.amazonaws.com:6443/api?timeout=32s: dial tcp 35.180.146.33:6443: connect: connection refused

[xmudrii]

@kron4eg Isn't this working as expected? We use LB as the API endpoint by default. Therefore, it's also written in kubeconfig. As an eventual fix, we could try to connect to the node directly, but that would require modifying kubeconfig (possible with client-go).

[kron4eg]

I suppose client error shouldn’t be treated as fatal error, and even if it happens — we should retry it it few times and then proceed to ssh-ing to nodes anyway.

…

On Jun 1, 2019, at 12:37, Marko Mudrinić ***@***.***> wrote: @kron4eg Isn't this working as expected? We use LB as the API endpoint by default. Therefore, it's also written in kubeconfig. As an eventual fix, we could try to connect to the node directly, but that would require modifying kubeconfig (possible with client-go). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[xmudrii]

I agree that we should retry a few times, but I disagree that we should skip and proceed to SSH-ing. I prefer showing an error message and instruct the user that the step can be skipped by setting --destroy-workers to false.

[kron4eg]

SGTM

[xmudrii]

kubeone reset also fails on not found error (e.g. if an object has been already deleted). In such cases, we should just skip the object instead of failing. We should cover this by PR fixing this issue.

[xmudrii]

A workaround is to add a log message when this happens to use the --destroy-workers=false flag and then destroy them manually.