Hello, I have small (4 machine) MaaS/Juju cluster where I want to install Rancher’s K3S (lightweight Kubernetes distro). I know Juju offers Canonical’s “Charmed Kubernetes” but it’s much heavier than what I need and requires more machines than I’ve got.
K3S is extremely easy to install simply by running their install script (we’ll leave aside the security implications of piping curl into your shell…) but is there any sensible way to orchestrate this using Juju? Would I have to write my own charm or something? Or is there some other way to create a Juju application without using a charm?
Canonical also offers MicroK8s that’s much closer to upstream K8s than K3s.
That said, writing a K3S charm is certainly a realistic thing to do if that’s the tool you would like to choose. Do you already have experience with Juju?
I’m familiar with MicroK8s for local development, but I thought it was only suitable for a single-node deployment using Snap? Is there a MicroK8s charm? Or how would I deploy that?
At any rate, K3s looks like a better fit for what I want: an opinionated “batteries-included” Kubernetes with low operational overhead.
I have virtually no experience with Juju, except for going through some basic tutorials. I take it there’s no way to say “give me a Juju app by running this script”? I’ve seen “juju exec” but that won’t provision machines.
How would I get started writing a charm? In brief, I need to be able to set some environment variables and run the Rancher install script. The agent nodes will need to get a token from the server node (control plane) in order to join that Kubernetes cluster.
MicroK8s’s initial selling point is the developer-centric workflow, but it also supports a clustered deployment. I don’t believe that this has been charmed up. As you mentioned earlier, Charmed Kubernetes sits in this position.
Writing a Juju charm might not offer a lot of benefit for you right now. If you’re looking to reduce cognitive load, then learning a new tool complicates that objective.
To answer a broader question - why bother learning charms/Juju - Juju aims at a more difficult problem than the day-1 provisioning/set up step.
It takes care of a lot operational problems that are fairly brittle (hard coded CIDR blocks, hostnames, etc) with other tools. For example, your deployment can auto-configure itself depending the current situation. It greatly reduces the need for a service-discovery tool in the middle of your architecture. Each unit of inter-related applications have the ability to exchange information.
Learning Juju involves setting your expectations of DevOps tooling much higher than you’re used to. But that mental shift is quite a barrier to many people. We’ve used it to good effect here at Canonical. Every .deb and .snap delivered to you all around the world is served from a computer managed by Juju. We also manage infrastructure for banks and telcos. Without Juju, our service would be more expensive and less reliable.
That said - if you are starting from scratch, you may wish to park Juju as an option and come back to it when you’re off the ground with your current project. I have a suspicion that you’ll find the learning process frustrating, because it’s a little bit more complicated than it should be (we’re working on fixing that!).
