Overview
Duration: 3:00
Before you get started!
Welcome to the world of operators! In this series of tutorials, we will walk you through all the necessary steps to explore and learn operators through some basic examples. Starting with just your laptop, you will learn how to use operators for sophisticated application management at scale, across multiple Kubernetes clusters, cloud virtual machines, and ultimately bare metal.
This tutorial assumes you have successfully completed the previous tutorial - Teardown.
What are operators?
Operators are pieces of software designed to drive other software. They encapsulate the operational code of applications, shifting the burden of lifecycle management from configuration files and manual steps to an operator instance. Operators are a form of automation that is gaining popularity in the Kubernetes domain where traditional configuration management does not work. However, operators work with traditional virtual and bare metal machines as well.
What is Juju OLM?
Juju is a universal Operator Lifecycle Manager (OLM) which provides services to operators. It provides resources for operators, deploys them, manages their lifecycle, delivers configuration updates, etc. Juju OLM is universal, meaning that it supports container substrates like Kubernetes as well as traditional machine substrates like bare metal, VMware, OpenStack, or public cloud instances.
In this tutorial, you will learn how to:
-
Use model-driven architecture provided by Juju OLM
-
Create models
-
List models
-
Switch between models
You will only need:
-
A machine with 8 GB of RAM
-
Microk8s and Juju installed
-
Juju controller bootstrapped on MicroK8s
Model-driven architecture
Duration: 5:00
What makes operators from the Open Operator Collection unique is model-driven architecture provided by Juju OLM. Standalone operators from individual vendors with no common model are hard to integrate because they all behave differently. That’s why Juju OLM is completely model-driven; it understands all the operators and provides a unified view.
Users can compose complex application topologies by adding operators to the model and connecting them through declarative, automated integration. This allows them to abstract deployments of even very complex systems like OpenStack, Hadoop, Kubernetes or Kubeflow in a form of interactive application graphs. An application graph for Kubeflow can look like:
In general, a model comprises a set of applications serving a common purpose. A Juju controller is not restricted to modelling a single set of applications with a common purpose. A controller can contain many “models”: groups of applications that belong together, but might need to be isolated from other models for organizational, security, or other reasons.
In previous tutorials, we were using the “monitoring” model that we created on the “mk8s” controller. We deployed two applications: Prometheus and Grafana inside of this model. Finally, we removed both of them and the model itself. In the following steps, we will dive deeper into the concept of models in Juju and see how to manage them.
Manage models under a Juju controller
Duration: 5:00
So we’re back to the initial status where we have MicroK8s installed, Juju client installed and Juju controller bootstrapped on MicroK8s. In the following steps, we will create two new models and see how they map to Kubernetes namespaces. We will also demonstrate how to list the existing models and switch between them.
First, let’s see what the current status of the model is:
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
controller mk8s microk8s/localhost 2.9.9 unsupported 09:42:26+01:00
Model "admin/controller" is empty.
As you can see, there’s nothing there as we removed the current model in the previous tutorial. Let’s see whether there are any other models left:
$ juju list-models
Controller: mk8s
Model Cloud/Region Type Status Access Last connection
controller* microk8s/localhost kubernetes available admin just now
Clearly, there is a “controller” model which hasn’t been removed. The “controller” model is used to host the Juju controller itself.
We can now add two new models for our applications:
$ juju add-model monitoring
Added 'monitoring' model on microk8s/localhost with credential 'microk8s' for user 'admin'
$ juju add-model communication
Added 'communication' model on microk8s/localhost with credential 'microk8s' for user 'admin'
$ juju list-models
Controller: mk8s
Model Cloud/Region Type Status Access Last connection
communication* microk8s/localhost kubernetes available admin never connected
controller microk8s/localhost kubernetes available admin just now
monitoring microk8s/localhost kubernetes available admin never connected
We will use the “communication” model to deploy Mattermost application. Mattermost is an open-source, self-hostable online chat service.
$ juju deploy mattermost-k8s
Located charm "mattermost-k8s" in charm-hub, revision 1
Deploying "mattermost-k8s" from charm-hub charm "mattermost-k8s", revision 1 in channel stable
As always we can monitor the progress of the deployment using the juju status command:
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
communication mk8s microk8s/localhost 2.9.9 unsupported 09:56:29+01:00
App Version Status Scale Charm Store Channel Rev OS Address Message
mattermost-k8s waiting 1 mattermost-k8s charmhub stable 1 kubernetes Waiting for database relation
Unit Workload Agent Address Ports Message
mattermost-k8s/0* waiting idle Waiting for database relation
Let’s now have a look at the namespaces created under our MicroK8s cluster:
$ microk8s.kubectl get namespaces
microk8s.kubectl get namespaces
NAME STATUS AGE
...
mk8s Active 1h
monitoring Active 2m41s
communication Active 2m32s
As we can see the output contains the new two namespaces: “monitoring” and “communication” which correspond to our Juju models. For each Juju model there is a separate namespace created on K8s.
Let’s now have a detailed look at the resources created under the “monitoring” namespace:
$ microk8s.kubectl get all -n monitoring
NAME READY STATUS RESTARTS AGE
pod/modeloperator-7df9db7884-2fvh8 1/1 Running 0 4m43s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/modeloperator ClusterIP 10.152.183.253 <none> 17071/TCP 4m43s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/modeloperator 1/1 1 1 4m43s
NAME DESIRED CURRENT READY AGE
replicaset.apps/modeloperator-7df9db7884 1 1 1 4m43s
There’s not much there yet, since we haven’t deployed any applications there. But let’s have a look at how the situation looks like inside of the “communication” namespace:
$ microk8s.kubectl get all -n communication
NAME READY STATUS RESTARTS AGE
pod/modeloperator-55486b776-fw9xj 1/1 Running 0 5m4s
pod/mattermost-k8s-operator-0 1/1 Running 0 4m1s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/modeloperator ClusterIP 10.152.183.226 <none> 17071/TCP 5m4s
service/mattermost-k8s-operator ClusterIP 10.152.183.155 <none> 30666/TCP 4m1s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/modeloperator 1/1 1 1 5m4s
NAME DESIRED CURRENT READY AGE
replicaset.apps/modeloperator-55486b776 1 1 1 5m4s
NAME READY AGE
statefulset.apps/mattermost-k8s-operator 1/1 4m1s
Notice the additional pod and service for the deployed mattermost application. The pod created for each application unit, the operator service for exposing the application over the network.
We can list existing Juju models by executing the juju list-models command:
$ juju list-models
Controller: mk8s
Model Cloud/Region Type Status Units Access Last connection
communication* microk8s/localhost kubernetes available 1 admin 5 minutes ago
controller microk8s/localhost kubernetes available - admin just now
monitoring microk8s/localhost kubernetes available - admin never connected
The model with an asterisk sign (*) next to it is the current model that is being used. If we run the juju status command again, we’ll see the mattermost application deployed. But we can also switch to the “monitoring” model to re-deploy our Prometheus and Grafana.
In order to switch to a different model, execute the juju switch command and pass the name of the model:
$ juju switch monitoring
mk8s:admin/communication -> mk8s:admin/monitoring
Not surprisingly the output of the juju status command is pretty empty here:
$ juju status
Model Controller Cloud/Region Version SLA Timestamp
monitoring mk8s microk8s/localhost 2.9.9 unsupported 10:03:05+01:00
Model "admin/monitoring" is empty.
Next steps
Duration: 2:00
Congratulations! You have reached the end of this tutorial.
You can now move to the next tutorial - “9. Bundles”.
In this tutorial you have learnt how to:
-
Use model-driven architecture provided by Juju OLM
-
Create models
-
List models
-
Switch between models