See also: Agent
The location where a Juju agent is deployed and run depends on the type of the agent and the type of provider where it is deployed. A controller agent runs at the provider where user applications are deployed by Juju, whereas the location where machine and unit agents run depends on the type of the provider, i.e. Kubernetes (K8S) based provider, or a non-K8S provider (bare-metal, virtual machine, Linux container). The following summarises this in a nutshell.
When a deployment is on bare-metal (BM) or on a virtual machine (VM), the machine is the BM/VM, and the machine agent runs on that BM/VM. This is depicted in the following figure:
Here, the machine agent, which runs the charm code in a container in the machine, contains machine workers as well as a separate unit worker for each application deployed on that machine. Note that applications run as workload processes in a machine.
When a deployment is on a container running in a BM or VM, the machine is the container, and a machine agent runs in it. Each deployed application runs as a workload process in the machine, and a dedicated unit worker for each application is run in the machine agent, in addition to the agent’s machine workers. This is depicted as follows:
Agents are deployed in a different way in a Kubernetes (K8S) provider, compared to BM/VM and Linux container cases above. As seen in the figure below, when a deployment is on K8S, there is no concept of a machine, but a machine agent runs in each K8S node where workloads are deployed. The main deployment entity in this case is the K8S pod, where a workload (i.e. an application unit) is deployed in a container. A unit agent runs in a sidecar container in the same pod, which runs a unit worker. This unit worker performs Juju operations on the deployed workload.
In contrast to VM/BM and Linux container cases, it is the unit agent and not the machine agent that runs the charm code, i.e. the operator, for the deployed workload.
Pebble is the init system that runs in the workload container in a K8S pod.
In the case of K8S, Juju runs each unit of an application in a single container of a separate pod; therefore a Juju unit in a K8S provider is equivalent to a K8S pod.
In the case of K8S, the K8S namespace where a deployment has been made is equivalent to the Juju model for that deployment.