Custom Resource Definitions

When working with Custom Resource Definitions (CRDs), it is important todistinguish two different pieces:

• There is a declaration of a CRD. This is the YAML file that has the kind

Helm is optimized to load as many resources into Kubernetes as fast as possible.By design, Kubernetes can take an entire set of manifests and bring them allonline (this is called the reconciliation loop).

For a CRD, the declaration must be registered before any resources of that CRDskind(s) can be used. And the registration process sometimes takes a few seconds.

With the arrival of Helm 3, we removed the old hooks for a moresimple methodology. There is now a special directory called crds that you cancreate in your chart to hold your CRDs. These CRDs are not templated, but willbe installed by default when running a helm install for the chart. If the CRDalready exists, it will be skipped with a warning. If you wish to skip the CRDinstallation step, you can pass the —skip-crds flag.

Some caveats (and explanations)

Another important point to consider in the discussion around CRD support is howthe rendering of templates is handled. One of the distinct disadvantages of the method used in Helm 2 was the inability to properly validatecharts due to changing API availability (a CRD is actually adding anotheravailable API to your Kubernetes cluster). If a chart installed a CRD, helm nolonger had a valid set of API versions to work against. This is also the reasonbehind removing templating support from CRDs. With the new crds method of CRDinstallation, we now ensure that helm has completely valid information aboutthe current state of the cluster.

Method 2: Separate Charts

Another way to do this is to put the CRD definition in one chart, and then putany resources that use that CRD in another chart.