Shulou(Shulou.com)06/03 Report--

What has changed in Helm 3? In response to this problem, today's small editor summarizes this article about Helm 3, hoping to help more friends who want to solve this problem find a simpler and easier way.

1. Remove Tiller

Helm eventually removed its server-side component, Tiller. Now, it has no proxy at all. Tiller was previously a small application running on Kubernetes that listened for Helm commands and handled the actual work of setting up Kubernetes resources.

This is the most significant change in Helm3. Why is Tiller's removal so much of a concern? First, Helm should be a template mechanism on Kubernetes configuration. So why do you need to run certain agents on servers?

Tiller itself has some problems because it requires the Cluster Administrator's ClusterRole to create it. So suppose you want to run the Helm app on a Kubernetes cluster launched in Google Cloud Platform. First, you need to start a new GKE cluster, then initialize Helm with helm init, and…find that it fails. This happens because, by default, you do not assign administrator privileges to your kubectl context. Now that you know this, start searching for magic commands that assign administrator privileges. With this series of maneuvers, you may have begun to wonder if Helm is really a good choice.

Also, because Tiller uses different access rights than you configured in the kubectl context. So, you might be able to create an application using Helm, but you might not be able to create it using kubectl. If this situation is not checked out, it looks and feels like a security breach.

Fortunately, now that Tiller has been completely removed, Helm is now a client-side tool. This change results in the following:

Helm uses the same access rights as kubectl context

You no longer need to use helm init to initialize Helm

Release Name in namespace

What Helm 3 has always remained the same: it should just be a tool that performs operations on the Kubernetes API. Thus, if you can perform an operation using pure kubectl, you can also perform it using helm.

Distributed repositories and Helm Hub

The Helm command installs Chart from a remote repository. Before Helm 3, it usually used a predefined central repository, but you can add other repositories as well. But from now on, Helm is migrating its warehouse model from centralized to distributed. This means two important changes:

Predefined central repository removed

Helm Hub (a platform for discovering distributed chart repositories) was added to helm search

To better understand this change, I'll give you an example. Before Helm 3, if you wanted to install a Hazelcast cluster, you would need to execute the following command:

$ helm2 install --name my-release stable/hazelcast

Now, that command doesn't work. You need to add a remote repository before installing it. This is because there is no longer a predefined central repository. To install Hazelcast cluster, you first need to add its repository and then install chart:

$ helm3 repo add hazelcast https://hazelcast.github.io/charts/$ helm3 repo update$ helm3 install my-release hazelcast/hazelcast

The good news is that the Helm command can now find Charts directly in Helm Hub. For example, if you want to know in which repository Hazelcast can be found, you can simply execute the following command:

$ helm3 search hub hazelcast

The above command lists charts that contain "hazelcast" in the name of all distributed repositories in Helm Hub.

Now, let me ask you a question. Is removing the central warehouse a step forward or a step backward? There are two views. The first is the view of chart maintainers. For example, we maintain a Hazelcast Helm Chart, and every change in the Chart requires us to propagate it to the central repository. This extra work resulted in many Helm Charts in the central warehouse not being well maintained. This situation is similar to what we experienced in the Ubuntu/Debian package repository. You can use the default repository, but it often only has older package versions.

The second view comes from Chart users. For them, although installing a chart is now slightly more difficult than before, on the other hand, they are able to install the latest chart from the main repository.

3. JSON Schema validation

Starting with Helm 3, chart maintainers can define JSON Schema for input values. This feature is important because so far you can put anything you want in values.yaml, but the final result of the installation may be incorrect or have some difficult to understand error messages.

For example, you enter a string instead of a number in the port parameter. You will receive the following error:

$ helm2 install --name my-release --set service.port=string-name hazelcast/hazelcastError: release my-release failed: Service in version "v1" cannot be handled as a Service:v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32:unexpected character: �, error found in #10 byte of ...| ","port":"wrong-name|..., biggercontext ...| fault"},"spec":{"ports":[{"name":"hzport","port":"wrong-name","protocol":"TCP","targetPort":"hazelca|...

You have to admit that the problem is difficult to analyze and understand.

In addition, Helm 3 adds OpenAPI validation for Kubernetes objects by default, meaning that requests sent to the Kubernetes API will be checked for correctness. This is a major positive for Chart maintainers.

4. Helm test

The Helm test is a small optimization. Although minor, it may actually encourage maintainers to write Helm tests and users to execute helm tests after installing each chart. Before Helm 3, testing was somewhat strange:

Previously the test was executed as a Pod (as if it needed to run all the time); now you can define it as a Job.

Test pods are not automatically removed (unless you use magic flag -cleanup), so by default, without any tricks, you cannot run helm tests multiple times for a given version. Fortunately, test resources (Pods, Jobs) can now be deleted automatically.

Of course, the old test version is not unusable, just use Pod and always remember to perform helm test-cleanup. But I have to admit, this improvement helps improve the testing experience.

5. Command line syntax

Finally, the Helm command syntax has changed. On the positive side, I think all of the changes were made to make the experience better; on the negative side, this syntax is not compatible with previous versions. So now when writing the steps on how to install something using Helm, you need to make it clear whether the command you are using is for Helm 2 or Helm 3.

For example, start with helm install. The version name is now required, although you can omit it in Helm 2 and the name can be generated automatically. To achieve the same effect in Helm3, you need to add the parameter--generate-name. Therefore, a standard installation using Helm 2 should be as follows:

$ helm2 install --name my-release hazelcast/hazelcast

In Helm 3, you need to execute the following command:

$ helm3 install my-release hazelcast/hazelcast

Another nice change is that removing the Helm version eliminates the need to add-purge. Simply enter the command helm uninstall to remove all related resources.

There were other changes, such as some commands being renamed (but using the old names as aliases) and others being removed (such as helm init). If you would like to learn more about Helm syntax changes, please refer to the official documentation:

https://helm.sh/docs/faq/#cli-command-renames

The new features of Helm 3 are shared here. I hope the above content can be helpful to everyone and learn more. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.