CustomResourceDefinitions (CRDs) allow you to extend Kubernetes to manage components (“resources”) of your infrastructure that it doesn’t support by default.
A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind; for example, the built-in pods resource contains a collection of Pod objects.
A custom resource is an extension of the Kubernetes API that is not necessarily available in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.
Custom resources can appear and disappear in a running cluster through dynamic registration, and cluster admins can update custom resources independently of the cluster itself. Once a custom resource is installed, users can create and access its objects using kubectl, just as they do for built-in resources like Pods .
For some use cases, a mismatch exists between the lifecycle of Juju applications lifecycle of custom resources. Some use cases for custom resources require that they would exist for the lifetime of the k8s cluster itself.
In Juju 2.8, Juju administrators can control how custom resources are removed:
- the default behaviour is for CRDs to be removed when the application is removed, e.g.
juju remove-applicationorjuju remove-modelis run - adding
juju-resource-lifecycle: modelto the pod spec requests that Juju remove the CRD whenjuju remove-modelis run - adding
juju-resource-lifecycle: persistentmeans that Juju will not remove the CRD
This feature is further elaborated on in this post: