Your charm can deploy secrets, service accounts, and cluster roles even though those are not yet modelled by Juju. You inlude those in the optional k8s specific YAML file passed to k8s-spec-set.
There’s more below. If there’s a particular use case where more info is needed, maybe provide an example of what’s needed and we can help.
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 …
and here
Background
Juju k8s charms communicate to Juju the artifacts needed to provision their workloads.
The guiding principle is that we model everything that is generic.
The initial model was deliberately quite small in the entities that were defined.
As the kubeflow k8s charms were developed, additional k8s functionality was necessary to be delivered in the pod YAML that Juju passed through to “deploy” the charms.
V1 Features
As a reminder, here’s what was done for v1.
Juju defines a substrate …
and here
Available in the 2.8 edge snap…
New extended volume support
It’s now possible to configure volumes backed by:
config map
secret
host path
empty dir
To do this, you’ll need to mark your YAML as version 3. This new version 3 also:
renames the config block to envConfig (to better reflect its purpose).
renames the files block to volumeConfig.
allows file mode to be specified
With secret and config map, these must be defined in the elsewhere YAML handed to Juju - you can’t reference existing r…
