- Actions now available in charms
- Support for
juju-runadded (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
- 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
- Ask-or-tell approach
- Region-specific credentials
update-credentialcan take a file as input
add-credentialcan process a batch of credentials
list-cloudsnow omits clouds for which credentials are not registered
- Credentials can be added to clouds stored on the controller
- Trust support
- Cross-model relations
- Multi-doc bundle support for overlays
- Help to test
New Features and Changes in Juju 2.7
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:
|Actions||Pre-defined commands defined by charms||Working with actions | Juju|
|Run||Execute ad-hoc commands on units/machines||Basic client usage - tutorial | Juju|
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.
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
- config maps
- scale policy
- custom resources
Persistent volume provisioning in Kubernetes
WaitForFirstConsumer attribute is now set where Juju creates the Storage Class used for persistent volume creation.
Bind addresses added to
network-get hook tool
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
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
Heavy development has taken place relating to credential and cloud management. We hope that this area is now more intuitive and easier to learn.
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
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:
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.
Some clouds have region-specific credentials. Juju now provides the ability to add and update these credential using the validation against their desired region.
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 can process a batch of credentials
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.
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.
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
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 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
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.
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
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.