New Features and Changes in Juju 2.7

juju
1

Contents

  • Kubernetes
    • Actions now available in charms
    • Support for juju-run added (to allow workloads to self-report their status)
    • Additional capabilities available to workloads, including secrets
    • Support for custom resources
    • Persistent volume improvements
    • Bind addresses added to network-get hook tool
    • Introspect agents
    • workload permissions and capabilities via roles and role bindings
    • bootstrap to clusters with RBAC enabled
    • better support for working with bare metal k8s clusters
    • configuration of the controller service when bootstrapping to the cluster
  • Cloud-related commands
    • Ask-or-tell approach
    • Region-specific credentials
    • update-credential can take a file as input
    • add-credential can process a batch of credentials
    • list-clouds now omits clouds for which credentials are not registered
    • Credentials can be added to clouds stored on the controller
  • Networking
    • New bind command
    • bind support in upgrade-charm
    • bind restrictions
  • Bundles
    • Trust support
    • Cross-model relations
    • Multi-doc bundle support for overlays
  • Help to test

New Features and Changes in Juju 2.7

Kubernetes

Kubernetes support continues to mature. We are aiming to make Juju the simplest way to deploy and manage your container-centric workloads.

Actions support in Kubernetes charms

Actions are now supported on k8s charms. In addition, a major UX improvement is available behind the juju-v3 feature flag. See the post below for more detail and how to use the feature flag to access the feature today.

Existing documentation for these features can be found:

Command Purpose Link
Actions Pre-defined commands defined by charms https://jaas.ai/docs/working-with-actions
Run Execute ad-hoc commands on units/machines https://jaas.ai/docs/client-usage-tutorial#heading--running-commands-on-a-machine

juju-run support in Kubernetes charms

juju-run (distinct from the juju run client command) is added to /usr/bin on each workload pod. It’s used to allow any workload script to invoke a hook command such as status-set (for example, in this case to report workload status back to Juju).

This feature can be used to communicate from the workload back to Juju:

To experiment with this feature interactively, use kubectl exec to open a shell within a workload pod. juju-run will then be available for you;

kubectl -n mymodel exec -ti mariadb-k8s/0 bash
juju-run --help
Output of juju-run help 
Usage: juju-run [options] [<unit-name>] <commands>

Summary:
run commands in a unit's hook context

Options:
--force-remote-unit  (= false)
    run the commands for a specific relation context, bypassing the remote unit check
--no-context  (= false)
    do not run the command in a unit context
-r, --relation (= "")
    run the commands for a specific relation context on a unit
--remote-unit (= "")
    run the commands for a specific remote unit in a relation context on a unit

Details:
Run the specified commands in the hook context for the unit.

unit-name can be either the unit tag:
 i.e.  unit-ubuntu-0
or the unit id:
 i.e.  ubuntu/0

If --no-context is specified, the <unit-name> positional
argument is not needed.

If the there's one and only one unit on this host, <unit-name>
is automatically inferred and the positional argument is not needed.

The commands are executed with '/bin/bash -s', and the output returned.

Introspect Agents

This is another feature added to bring k8s deployments up to parity with cloud based deployments. The standard introspection tools are now available after exec’ing to either the controller pod or workload pod.

$ juju deploy cs:~juju/mariadb-k8s
$ kubectl -n test exec -ti mariadb-k8s-operator-0 bash
# source /etc/profile.d/juju-introspection.sh 
#
# root@mariadb-k8s-operator-0:/var/lib/juju# juju_engine_report 
Querying @jujud-application-mariadb-k8s introspection socket: /depengine
Dependency Engine Report

manifolds:
  agent:
    inputs: []
...

Extended capabilities, permissions and other features within Kubernetes workloads

There’s a number of new features which charms can make use of when generating the pod spec YAML sent to Juju via the pod-spec-set hook command. These include:

  • cluster min version check
  • service accounts and roles
  • secrets
  • config maps
  • scale policy
  • custom resources

Persistent volume provisioning in Kubernetes

The WaitForFirstConsumer attribute is now set where Juju creates the Storage Class used for persistent volume creation.

Bind addresses added to network-get hook tool

The network-get result now sets the address of the pod’s container as a bind address. This compliments the service address which is set as an ingress address.

Better support for bare metal k8s clusters

The add-k8s command has been enhanced to better cater for the case where you want to register an existing k8s cluster with Juju, but the cluster is running on bare metal rather than being deployed from say a Charmed Kubernetes bundle on top of a running cloud. If the cluster has a default storage class already defined, and ~/.kube/config is in place,

juju add-k8s <mycluster>

will just work. If you need to specify a different storage class, use:

juju add-k8s <mycluster> --storage <mystorage>

Configuring the controller service when bootstrapping

When bootstrapping directly to a k8s cluster, Juju will create the front end service to the controller pod according to the type of the underlying cluster. For microk8s, a ClusterIP service is created; for Charmed Kubernetes on AWS or Azure, a LoadBalancer service is created etc.

You can override this behaviour, to choose a specific service type, and where necessary provide the external IP address(es) with which to configure the service. Here’s how you’d specify to use a k8s ExternalName service

$ juju bootstrap microk8s test
  --config controller-service-type=external
  --config controller-external-name=mydnsname
  --config controller-external-ips=[10.0.0.1,10.0.0.2]

(where “mynamename” and the external ips are provided as dictated by the k8s set up being used).

Other options for service type are cluster and loadbalancer.

Cloud-related commands

Heavy development has taken place relating to credential and cloud management. We hope that this area is now more intuitive and easier to learn.

Ask-or-tell approach

Commands that manipulate clouds or their credentials, gained the ability to deal with both client side information as well as the information on the controller side.

With this support came the ‘ask-or-tell’ - the user has to be explicit about what copy they want to manipulate or the command will prompt for confirmation. To operate on a client copy, use --client option. To operate on a controller copy, use -c or --controller as per usual. Both options can be combined to operate on both client and controller. This change deprecates the --local and --global options.

So by default, when no option is specified, the commands will prompt the user. For example:

$ juju add-credential aws
Do you want to add a credential to:
    1. client only (--client)
    2. controller "controller" only (--controller controller)
    3. both (--client --controller controller)
Enter your choice, or type Q|q to quit:

Commands involved:

  • add-cloud
  • update-cloud
  • remove-cloud
  • show-cloud
  • list-clouds
  • add-credential
  • update-credential
  • remove-credential
  • show-credential
  • list-credentials
  • list-regions
  • autoload-credentials

All read-only type commands such as ‘show-’ and ‘list-’ will assume that the user wants both client and controller copies when current controller can be detected and, thus, will not prompt the user.

Region-specific credentials

Some clouds have region-specific credentials. Juju now provides the ability to add and update these credential using the validation against their desired region. add-credential and update-credential have gained --region option for this purpose.

update-credential can take a file as input

update-credential now can take a file as an input thus gaining the ability to update more than one credential for more than one cloud at a time. This mirrors the convenient behaviour of the add-credential command.

add-credential can process a batch of credentials

The add-credential command can now be used add multiple credentials for a cloud.

list-clouds now omits clouds for which credentials are not registered

‘list-clouds’ default behavior has changed. By default, public clouds from the client are only shown if they have registered credentials. To see all available clouds, use ‘–all’ option.

Credentials can be added to clouds stored on the controller

All credential commands can now operate correctly irrespective of whether current client side is aware of their desired cloud. As long as the cloud exists and is available to the user on the controller, the commands will work reliably.

There is now the ability to unset default region for the cloud on the client side.

Networking

Heavy refactoring in this area has increased area and is expected to make it easier to support several planned features, such as spaces support in all providers.

New bind command

Juju now has a command bind that allows you to make changes to the endpoint bindings of a deployed application matching the normal syntax users expect when using the juju deploy --bind flag. This allows operators to update endpoints to be bound to specific spaces as networks adapt over time.

bind support in upgrade-charm

Along side the bind command is a new --bind argument to the upgrade-charm command. This allows the operator to make sure a new relation endpoint, defined in a charm update, can be properly associated with the correct space to maintain network traffic patterns that are designed in the model. Operators may also change endpoint bindings at this time.

bind restrictions

The new bind command support does not functionally change any of the machines that the applications are running on. In order for a bind or an upgrade-charm --bind to be successful the machines affected must have access to the spaces involved.

New features in Juju Bundles

trust support

Bundles may now declare that an application would like to receive trust support. This mimics the same semantics as a juju deploy --trust, but in a pre-defined bundle form. This means that when deploying a bundle that’s declared an application is to be trusted, the --trust flag must be provided. When this is used the deploy command will note any and all applications that are given trust support.

Cross-Model Relations

Bundles may now declare both the offer and consuming side of a CMR (cross-model relation). In this way a bundle can setup a repeatable deploy of a service that then offers out a relation endpoint for other applications in other models to consume. The offer end may also choose to setup ACL rules and more.

NOTE Offering an endpoint does not change the underlying model and typically will only be used on the production deploy of a model vs in testing and staging. To facilitate this logically offers and their ACL settings must be defined in an overlay to the base bundle that describes the working model. In an effort to make this as simple as possible, bundles may define overlay content in the same bundle.yaml that the base model would be defined in.

A model that relies on an external service can be declared in the bundle and can be deployed repeatedly in one go. Often the external service is relying on a scaled service, such as a database, and cannot function without it. Consuming an application is just another way of defining an application in your bundle.yaml.

Multi-Doc bundle support for overlays

juju export-bundle can now export a multi-doc YAML file. This allows for exporting a model that offers an endpoint for CMR purposes. There may be one or more overlays defined in the YAML file. These will also be merged with any additional overlay files declared as the time of a juju deploy command. They are stacked in the order defined with the last one being the final winner of any disputes.

Help to test

3 Likes