Exploring bootstraping minikube on my osx box, I have a few questions.
From Juju’s perspective, what makes microk8s different from other installations of k8s?
More directly, why is it that Juju can bootstrap microk8s and recognize it as a standalone k8s cloud, while other k8s need to be added to an already existing controller?
Is it possible to treat all k8s the same? Are there reasons for or against this?
Possibly the microk8s k8s cloud exists because it fit well, to pull down a controller/mongo image and have a k8s cloud and controller in a matter of seconds. This provides; a) an accommodating means for a local development environment for k8s/k8s-charms, b) a great way to demo or develop juju k8s charms (get up and running on your local box in a matter of seconds), c) a step forward in bootstrapping and running juju workloads on k8s. The only downside to this is that the development workflow seems to break when ubuntu/microk8s isn’t available.
Most of my local development is done ssh’d into an ubuntu vm running on my macbook host, which makes testing juju k8s application environments that need front end access difficult. Frontend access to applications deployed in microk8s/minkube probably isn’t a very common use-case, but it has come up a few times recently, and is what sparked these questions.
I guess this makes a good case to get a laptop that runs ubuntu native - which has been on the list for a while already. In the meantime, I thought it may be helpful to do a little prying into what makes it possible to bootstrap k8s using ubuntu/microk8s and what the constraints are that disable other k8s deployments from facilitating native bootstrap also?