Adding / removing units - scale-application command

charm
1

A key difference with Kubernetes models vs vm based cloud models is how applications are scaled. On a traditional cloud, Juju has add/remove unit commands:

juju add-unit mariadb -n 3
juju remove-unit mariadb/2

The key behaviour is that Juju manages the units as named entities. Adding units creates new units with a unique number, and once created, specific units may then be selected for removal, or to have new storage attached, or to have storage detached etc.

Kubernetes works differently. Juju makes use of either a deployment or stateful set depending on whether storage is required. Individual pods are not managed as separate entities. All pods use a common storage configuration, memory and other resource limits etc. The scaling operation is done by requesting how many pods are to run, and Kubernetes will determine which pods to terminate (if any) to satisfy the request.

Juju uses a new scale-application command to manage the number of units for a given application.

juju scale-application mariadb 4

will request that 4 mariadb units/pods be running. New pods are created if needed; any in excess are terminated. Kubernetes will decide how to perform the requested scaling operation and juju status will reflect the outcome.

If you try and run add/remove-unit on a Kubernetes model you’ll get an error.

2
3

Is scale-application the best phrasing here? We are still counting units and the old commands/idea is around number of units. I wonder if scale-units or set-units mariadb 4 would keep the ideas together a bit more?

4

There’s a few lines of thought that lead to choosing scale-application.

Kubernetes itself uses a command like this

kubectl scale statefulset juju-mariadb --replicas 2

You scale a named statefulset/deployment aka application in Juju terms. You don’t scale pods.

Also, juju status has a Scale column for each application to show the number of requested units and number of running units. Scale is already presented as being associated with the application.

5

This isn’t what I thought was being proposed.

I thought that in the k8s model we’d use something like

juju add-unit -n 4

to add four units, and

juju remove-unit -n 3

to remove three units

6

It was considered but there’s friction. add/remove-unit define flags which are incompatible with k8s models, eg those related to attaching or destroying storage. And for IAAS models, the -n flag doesn’t exist for remove-unit and remove-unit takes positional args for the units. So SetFlags() and Init() would have to change what they do based on the model type, but the model type isn’t available when SetFlags() is called early in the process.

Given the above, and the fact that k8s itself operates using a single scale command to scale up/down, it’s more idiomatic and far less confusing/complicated to introduce a new, fit for purpose command.