Charms vs. Kubernetes operators

doc
1

A charm is an expansion and generalization of the Kubernetes notion of an operator.

In the Kubernetes tradition, an operator is a container that drives lifecycle management, configuration, integration, and daily actions for an application. It handles instantiation, scaling, configuration, optimisation, networking, service mesh, observability, and Day 2 operations specific to that application. On the principle that an operator should ‘do one thing and do it well’, each operator drives a single application or service. However, it can be composed with other operators to deliver a complex application or service. Because operators package expert knowledge in a reusable and shareable form, they hugely simplify software management and operations.

In Juju, an operator does all that but supports even more uses and more infrastructures: With charms (coordinated by Juju) you can not only deploy an application but also connect it to other applications, and you can use not just Kubernetes clusters, but containers, virtual machines, and bare metal machines as well, on public or private cloud.

2

Is this referring to the ‘tradition’ only, or is it still so in charmed operators (do charms run in containers?)

I would maybe split more clearly a section explaining what an operator is in k8s, then a section explaining what a charmed operator/charm is in juju as compared to that.

1 Like
3

Thanks for your question, @ppasotti. Made a note to check with the engineers and update.

4

On Kubernetes, a charm is following the operator pattern (software that monitors and drives other software). The charm itself runs inside a separate container from the workload container(s). On systems other than Kubernetes, the charm runs inside the same process space as their associated workload. This may be a container (running in an LXD container, for example), or it may be a virtual machine, or it may be a physical machine.

1 Like
5
6