Add blueprint for a 3-node microk8s ha cluster

[sed-i]

This PR adds a blueprint for a 3-node microk8s ha cluster for juju (nested multipass).

graph LR

subgraph microk8s-ha multipass VM

subgraph node-0 multipass VM
microk8s_0[microk8s]
end

subgraph node-1 multipass VM
microk8s_1[microk8s]
end

subgraph node-2 multipass VM
microk8s_2[microk8s]
end

juju

end

As of now, I am unaware of any readily deployable environment with such a setup. We (the o11y team) intend to use this as a baseline for a reference deployment of COS Lite.

A microk8s controller and an empty juju model are created as part of the cloud-init script so you can juju deploy right away. Example.

Manually tested restarting the inner and outer VMs.

Unlike "charm-dev", this blueprint does not install development tools.

References:

• https://discuss.kubernetes.io/t/microk8s-in-lxd/11520

[sed-i]

I set min reqs to 8cpu16gb because deploying COS Lite (3 units per charm) on such a VM resulted in:

• load avg of 6.5 during deployment
• load avg of 1.3 while COS is idle (no external relations)
• 12.6 out of 15.6 GB mem are in use.

[sed-i]

Superseded by https://github.com/canonical/cos-lite-bundle/pull/111

[ricab]

Hey @sed-i, I actually had it in my TODOs for this week to provide formal feedback on this, but you beat me to it.

Summarizing what we discussed in the sprint (and feel free to add any relevant points that I may be missing): I don't think such heavy workloads would be appropriate for most users of Multipass. A curious user who launched this on their laptop would face a significant risk of getting unworkable VMs or, worse, DoS-ing their machine. Those are experiences we'd rather prevent.

However, we can envision improving Multipass's ability to detect such risky launches early and prompting the user for confirmation. If we had that, and if the blueprint's description provided clear indication of the weight, I think this would then be a worthy addition. Until then, I believe your alternative above is the right approach.