CODEWITHSUNDEEP
kubernetescluster-computingkubernetes-helmvitess
Anticom
Anticom

Reputation: 1013

Why are Kubernetes operators not deployed using Helm?

I noticed that all the documentations on deploying operators in kubernetes always use a simple kubectl create -f /point/to/some/big/blob/deploying/the/operator.yaml as the "newer" alternative to a plain helm chart. That made me wonder why operator deployments are not usually managed by helm so we can depend upon it in our charts.

For example if I want a Vitess database cluster as part of my helm-managed application deployment to my understanding I'm out of luck because their helm chart is deprecated and they recommend using the operator. However there's no way for me to ensure the operator is present in a cluster by declaring it as a dependency in my Chart.yaml.

Is there any reason we can't deploy operators using helm charts? The only one I could think of is that CRDs are not namespaced so we can't have multiple versions of an operator running in the same cluster and hence we would break stuff if we try to roll out two applications that demand different versions of an operator.

What are my possibilities to solve the issue of not being able to depend upon another piece of software in my deployment?

Upvotes: 2

Views: 365

Answers (1)

Frank Dekervel
Frank Dekervel

Reputation: 109

A problem with helm dependencies is that they cannot be shared between multiple projects. So operator-as-helm-dependency would break anyway as soon as you would have multiple helm charts depending on the same operator: helm would try to deploy multiple instances of that operator, which is probably not what you want.

That being said, multiple operators (eg strimzi) offer a way to install as a helm chart.

Upvotes: 1

Related Questions