The Storage Support topic shows how Juju storage pools can be used to configure persistent storage in Kubernetes for use by the charms. The end result is that Juju will create a Kubernetes storage class using the configuration defined in the storage pool.
It’s also possible for Juju to make use of existing storage classes set up in Kubernetes directly (although the preferred approach is to model things with Juju via storage pools).
If you do want to set up a storage class outside of Juju, there are things that need to be done so that Juju knows to use that storage class. If you mark a storage pool as the default for the whole cluster, via the storageclass.kubernetes.io/is_default_class annotation, that storage class will be used. You can also use labels to tell Juju to use a particular storage class.
For setting up operate storage, Juju will look for an existing storage class with the following characteristics and pick the first one it finds:
- storage class called
<model>-juju-operator-storage - storage class called
juju-operator-storage - storage class with label key
juju-storage, value set to one of:<app>-operator-storage<model>default
storageclass.kubernetes.io/is-default-class
For Juju units themselves, it’s similar.
- storage class called
<model>-juju-unit-storage - storage class called
juju-unit-storage - storage class with label key
juju-storage, value set to one of:<app>-unit-storage<model>default
storageclass.kubernetes.io/is-default-class
Storage classes are not namespaced, so Juju allows for a default storage class to have the name of the model as the prefix. So if you want the same storage class to be used for all units from any model for example, create one with the name juju-unit_storage. If you want just a given model to use a storage class, prefix that storage class name with the model name.