Looking at the juju add-k8s --controller <controller> command in the Juju client, I realized that most of it should be probably handled by the controller instead.
When doing juju add-k8s, the client will, using the k8s client version for go, create a serviceaccount, clusterrole, and secret that later on will be used for creating a CloudCredentials object for the cloud. This means the client needs access to the k8s cluster.
I think it would be nice to move that logic to the controller, and just use the k8s client from the controller to create the resources, removing the need for the client to have access to the k8s cluster.
While I am writing this, I realize that this will only work when you add a k8s cloud to an existing controller, but there must exist this controller already. If you want to add a k8s cloud to the client so that later on you can bootstrap a controller… this won’t work for obvious reasons.
Anyway, if someone could share some thoughts about this I would appreciate it
add-k8s is like add-cloud - both commands can be used to add a cloud to an existing controller, thereby allowing that controller to manage models on more than one cloud. But, those commands also need to support creating a local definition of the cloud / k8s cluster on the client. This is so that a new controller can be bootstrapped.
For the add-cloud case, consider an example where someone has set up an Openstack or MAAS cloud and you want to be able to use Juju with that cloud - you would first need to add-cloud to set up the cloud endpoint and authentication info so that Juju could then provision resources in that cloud to bootstrap a controller.
It’s the same with add-k8s - you want to bootstrap to an existing k8s cluster but first need to teach the client from where you are bootstrapping how to talk to the cluster. And yes, as with add-cloud (and subsequent bootstrap), the client does need access to the cloud / cluster.
Note - in Juju 2.9, there’s been an improvement whereby Juju will automatically parse the local kubeconfig file and present any clusters as available to bootstrap on without the need for the separate add-k8s step. But add-k8s is still useful as it supports options like --aks or --gke or --eks to step you through the process of setting up one of those public clusters for use with Juju.
