Helm is the package manager for Kubernetes. It can greatly simplify the publishing process, but it can sometimes cause problems. Recently, Helm has been officially promoted to the top CNCF project and has been widely used in the community. This shows that Helm is indeed a good project, but I will share with you some of my thoughts on Helm.

This article will show why I don’t believe the hype.

I still don’t know what Helm is worth. It doesn’t offer anything special. What value does Tiller bring (server-side)?

Many Helm diagrams are incomplete and require some effort to apply to Kubernetes clusters, for example, lack of RBAC, resource limits, or network policies; This means you can’t install Helm diagrams in binary mode, forget what’s in them.

I wish someone would explain to me the aspects of a secure multi-tenant production environment, rather than just using the Hello World example to brag about how cool it is.

Linus Torvalds said, “Talk is cheap. Show me the code.”

Tiller has been likened to a “giant Sudo server.” To me, it’s just another layer of authorization with no access control and additional TLS certificates to maintain. Why not leverage the Kubernetes API and rely on an existing security model with proper auditing and RBAC capabilities?

It simply renders and examines the Go-template file using the configuration in values.yaml. The rendered Kuberentes list, along with the corresponding metadata, is then stored in ConfigMap.

This can be replaced with a few simple commands:

$kubectl apply --dry-run -f. $kubectl apply -f.Copy the code

In my observation, teams often have a values.yaml file in each environment, or even render it from values.yaml.tmpl before using it.

For Kubernetes Secrets, this doesn’t make sense because they are usually encrypted and versioned in a library. You can either do this using the Helm-Secrets plug-in or override it with set Key =value, but it adds another layer of complexity.

Forget it. It won’t work, especially for core Kubernetes components such as Kube-DNS, CNI providers, cluster Autoscalers, etc. These components have different life cycles and Helm is not suitable for these components.

Based on my experience with Helm, it works well for simple deployments using base Kubernetes resources that can be easily rebuilt from scratch without a complicated release process.

Unfortunately, Helm cannot handle more advanced and frequent deployments, including namespaces, RBAC, network policies, ResourceQuota, or PodSecurityPolicy.

I know this may offend Helm fanatics, but it’s a sad fact.

The Tiller server stores the information in ConfigMaps located inside Kubernetes. It doesn’t need its own database.

Unfortunately, the ConfigMap limit is only 1MB due to etCD limitations.

Hopefully someone will come up with an idea to extend the ConfigMap storage driver to compress the serialized version before storage, but in my opinion, this still doesn’t solve the real problem.

That’s my biggest fear — I can’t rely on it.

Error: UPGRADE FAILED: “foo” has no deployed release Error: The UPGRADE FAILED: “foo” has no deployed version

With all due respect, this is one of Helm’s annoying problems.

If the first release fails, each subsequent attempt returns an error saying that it cannot be upgraded from an unknown state.

Below PR “fixes” it by adding — forceFlag, but actually hides the problem by executing helm delete&helm install –replace: https://github.com/kubernetes/helm/pull/3597

In most cases, however, you’ll end up cleaning up the release completely.

helm delete --purge $RELEASE_NAMECopy the code

If ServiceAccount is missing or RBAC does not allow the creation of a specific resource, Helm returns the following error message:

Error: release foo failed: timed out waiting for the conditionCopy the code

Unfortunately, Helm does not provide a root cause for this:

kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not foundCopy the code

On rare occasions, Helm has succeeded in failing without doing anything. For example, sometimes it does not update resource limits.

By default, the Tiller is not HA, this PR is still in the open: https://github.com/helm/helm/issues/2334

One day, this could lead to outages…

The next version of Helm will bring some features to look forward to:

  • Single-service architecture without client/server – no Tiller required

  • Embedded Lua scripting engine

  • Pull DevOps workflow, a new Helm Controller project will be launched

For more information, please check the Helm 3 (https://github.com/helm/community/blob/master/helm-v3/000-helm-v3.md), a design proposal.

I like the idea of tiller-free architecture very much, but I’m not sure about Lua scripts because it adds extra complexity to the diagram.

I recently noticed a big change in Operators, which is more Kubernetes native than the Helm chart.

I really hope the community can fix this soon, but in the meantime, I prefer to use Helm as little as possible.

Don’t get me wrong — I spent some time building a hybrid cloud deployment platform on top of Kubernetes, and these are just my personal insights.

Check the English original: https://medium.com/virtuslab/think-twice-before-using-helm-25fbb18bc822

Activity recommended

The rapid development of the Internet has led to an exponential growth in the number of services. Although automated operation and maintenance has improved efficiency, it has also encountered new problems. Faced with various alarm information, how should operation and maintenance personnel deal with it? When a fault occurs, how can I quickly locate the fault?

The 4th CNUTCon conference, hosted by InfoQ, will introduce the changes in the era of intelligent operation and explain the new technologies and practices of Twitter, RIOT Games, BAT, Huawei and other leading domestic and foreign companies.

Currently, in the countdown to 20% off the conference, use my offer [Devops] to get more deals! Scan the qr code below or click “Read the original article” to learn more. If you have any questions, please contact Joy, tel: 13269078023 (wechat number).