Juju bootstrap failing with various Kubernetes

[Kenneth Koski]

From a prospective customer:

I tried to spin up a Juju controller on a remote/ local dev- Kubernetes cluster. I used “kind”, “minikube” and my private cluster. Everywhere the same problem. (I had a couple of different problems with juju, but in the end, it all boiled down to one crucial problem)

Steps to reproduce:

```
$ minikube start

$ # manually convert certificate-authority to certificate-authority-data as juju does not play with multiple k8s clusters in a kubeconfig file

$ juju add-k8s myMinikube
[…]

$ juju bootstrap myMinikube
[…]
Contacting Juju controller at 10.99.70.252 to verify accessibility...

$ # now [ctrl] + [c] does not work. Juju is not evaluating SIGKILL correctly.

```

What Juju now tries to do during the “bootstrap” command, is to connect to the ClusterIP of the controller. Usually a 10.x.x.x IP. This of course cannot work. A ClusterIP is only reachable from within the cluster.

I searched and searched… but I did not find a parameter to configure this.

Maybe there is a chance to get a quick tip what I did wrong here? As I said, either a “set x” by someone who knows of Juju – or we have a problem…

[John A Meinel (jameinel)]

There are 3 settings that are relevant:

 * controller-external-name
 * controller-external-ips
 * controller-service-type

These are all allowed as part of "juju bootstrap --bootstrap-config controller-external-ips=XXX", which will inform the Juju bootstrap process how the controller should be exposed to the rest of the world. This seems to be under documented, but is available in places like:
https://discourse.charmhub.io/t/juju-add-k8s-in-openstack-no-route-to-controller/3625/2

[Pen Gale (pengale)]

The error message when failing to contact the controller should suggest those flags.

Going to triage as high, part of 3.0.0 and bitesize. This will be done once the error message guides someone to the solution, I think.

[Kenneth Koski (knkski)]

Would it be possible to have Juju use port forwarding to talk to the controller? By that I mean do something like this in the background:

    kubectl port-forward -n controller-ns svc/controller-service 17070:17070

And then Juju could always just talk to `localhost:17070`, regardless of how the Kubernetes is set up that it's bootstrapping to.

This would make the bootstrapping process a lot more reliable and less manual, particularly for people that are not very familiar with Juju.

[Thomas Miller (tlmiller)]

PR: https://github.com/juju/juju/pull/12416

I think long term what we would like to do is have the option for the controller api to proxy through the kube api.