This post describes how to deal with the situation when the chart templates have dependencies. We can easily solve the problem by Helm hooks. Using ServiceAccount and Secret as the example.
I used to deploy the service accounts and service account secrets by Helm, and I encountered Failed to deploy a secret with type kubernetes.io/service-account-token, after diving into deep, I figured out what was happened in my Kubernetes cluster.
We have a bunch of configuration files that can configure the Kubernetes cluster. For example, we are going to build a Kubernetes cluster with
Multus support, we’ll need to have a
Multus service account and configure it. After the configuration, we can make
Multus has the ability to orchestrate Kubernetes container networking.
Therefore, we have some essential objects need to be created:
- Service account: multus-sa
- Service account secret: multus-sa-secret
- Cluster role for RBAC: multus-pod-networks-lister
- Cluster role binding: multus-rb
The Helm client renders templates automatically when deployment, but the sequence of rendered files to apply is not consistent. And this will cause a problem when we have a dependency between 2 objects.
For example, we created
ServiceAccount before the
Secret. But when we actually deployed to Kubernetes cluster, Helm will deploy the
ServiceAccount. And it leads to a fault,
Secret can’t bind to the correct
ServiceAccount, the data in secret will be missing.
Therefore, we need to use Helm Hooks annotations
pre-install to declare which object should be created before every objects else. But once the object is applied to these hooks, it’s not managed by Helm, so you can’t use
helm delete <release-name> --purge to delete it.
However, you can also declare by assigning
hook-delete-policy. And when Helm is trying to deploy a chart, it’ll check if the object exists or not, deletes the object if it’s in Kubernetes cluster.
There are other available hooks can satisfy more needs, you can find all hooks in Helm Docs - The available hooks. And there is one hook looks very useful for me, so I’ll describe and write the example code here.
When we created the
CustomResourceDefinition, sometimes we need the CRDs created before anything else, because we have some objects depend on the CRD resources. In this kind of situation, use the
crd-install to declare this CRD resource is depended on by other objects.