You have to understand the five key new features of Helm 3

Author | Rafal 

REVIEW : Helm is a package manager Kubernetes of. Two months ago, it released the third major version, Helm 3. In this new version, there are many significant changes. The author describes himself as the most critical aspects of five.

Tiller removed

Helm finally removed its server-side components, Tiller. Now, it is no agent. Before Tiller is running on Kubernetes a small application, which is used to monitor and deal with Helm command set Kubernetes resources of the actual work.

This is Helm3 the most significant changes. Why remove Tiller of concern it? First, Helm should be a template mechanism on Kubernetes configuration. So why do you need to run some agents on the server?

Tiller itself, there are some problems, because it requires the cluster administrator to create ClusterRole. Therefore, if you run the application on Helm to start in the Google Cloud Platform in Kubernetes cluster. First, you need to start a new GKE cluster, and then use the helm init initialization Helm, then ... we found that it failed.

The reason this happens is because, by default, you did not give your kubectl assign administrator privileges context. Now that you understand this and start searching for the magic assign administrator privileges command. This series of operations down, perhaps you have begun to wonder whether Helm is a really good choice.

In addition, because access to the Tiller using the access you configure in kubectl different context. So, you may be able to create applications using Helm, but you may not be able to use kubectl create the program. This situation, if the investigation did not come out, looks and feels like a security vulnerability.

Fortunately, now Tiller has been completely removed, Helm is now a client tool. This change will result in the following:

• Helm use the same access rights kubectl context;
• You do not need to use the helm init to initialize Helm;
• Release Name in the namespace.

Helm 3 has remained the same: it should only be a tool operations performed on Kubernetes API. So, if you can perform an action using pure kubectl command, you can also use the helm perform the operation.

Distributed warehouse and Helm Hub

Helm Chart command can be installed from a remote repository. Prior to Helm 3, it is usually to use the predefined central warehouse, but you can also add other warehouses. But from now on, Helm will migrate its warehouse model from centralized to distributed. This means that two important changes:

• Predefined central warehouse has been removed;
• Helm Hub (distributed a chart warehouse platform discovery) is added to the helm search.

In order to better understand this change, I'll give you an example. Prior to Helm 3, if you want to install a Hazelcast cluster, you need to execute the following command:

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

Now, this command does not work. You need to add a remote repository to be installed. This is because there is no longer a pre-defined central warehouse. To install Hazelcast cluster, you first need to add its warehouse and then install the chart:

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

The good news is now Helm command can look directly at the Helm Hub in Chart. For example, if you want to know in which warehouse can be found Hazelcast, you simply execute the following command:

$ helm3 search hub hazelcast

The above command lists all distributed repository name contains "hazelcast" in the Chart in Helm Hub.

Now, let me ask you a question. Remove off central warehouse progress or regress? There are two views. The first is a view chart defenders. For example, we maintain Hazelcast Helm Chart, and each change Chart of all we need to spread it to the central warehouse. This extra work makes many Helm Chart central warehouse in not well maintained. This situation is very similar to us in Ubuntu / Debian package repository experienced. You can use the default repository, but it is often only the old package version.

The second view from the Chart of the user. For them, although it is slightly more difficult to install a chart of some than before, but on the other hand, they can be installed from the main repository to the latest chart.

JSON Schema validation

Helm 3 from the beginning, chart maintainer JSON Schema may be defined as an input value. Improve this very important function, because so far you can put anything you need in values.yaml in, but the final result of the installation may be incorrect or difficult to understand some of the error messages appear.
For example, you enter the string instead of a number in the port parameter. Then you receive the following error:

$ helm2 install --name my-release --set service.port=string-name hazelcast/hazelcast
Error: 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|..., bigger
context ...|fault"},"spec":{"ports":[{"name":"hzport","port":"wrong-name","protocol":
"TCP","targetPort":"hazelca|...

You have to admit this question difficult to analyze and understand.

In addition, Helm 3 default added OpenAPI verified against Kubernetes object, which means that the request sent to Kubernetes API will be checked properly. This Chart defenders, it is a major positive.

Helm test

Helm is a little test optimization. Although small, but it may actually encourage the maintainer to test and write Helm helm test user executes the command after the installation of each chart. Prior to Helm 3, to test how many it is a bit strange:

• Prior to the test execution as Pod (as if need be running); Now you can define it as Job;
  
• Test Pod does not automatically be removed (unless you use the magic flag -cleanup), so by default, without any tricks, for a given version you can not perform the helm test multiple times. Fortunately, you can now automatically delete the test resources (Pod, Job).

Of course, the old version of the test is not can not be used, just use the Pod and always remember to perform the helm test -cleanup. But have to admit, this improvement will help to enhance the testing experience.

Command line syntax

Lastly, Helm command syntax has changed. On the positive side, I think all the changes are to make the experience better; On the negative side, this syntax is not compatible with previous versions. So now when writing procedures on how to use the Helm install anything, need to be clearly pointed out that the command used for Helm 2 or for Helm 3.

For example, start with the helm install begin. Now the version name has become a required parameter, although in Helm 2 you can ignore it, the name can also be generated automatically. If Helm3 want to achieve the same effect, you need to add parameters --generate-name. Therefore, using standard Helm 2 should be installed as follows:

$ helm2 install --name my-release --set service.port=string-
$ helm2 install --name my-release hazelcast/hazelcast

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

$ helm3 install my-release hazelcast/hazelcast

There is another good change is that after you remove Helm version, no need to add - purge. Simply enter the command helm uninstall To delete all associated resources.

There are other changes, such as some of the commands are renamed (but using the old name as an alias), some command will be deleted (eg helm init). If you want to know more about Helm command syntax changes, please refer to the official document: https://helm.sh/docs/faq/#cli-command-renames

in conclusion

Helm Published 3, making this tool towards a new stage. As a user, I am very fond Helm now just a simple client tools. As Chart defenders, methods Helm Hub and distributed warehouses won my heart. I hope to see more and more interesting change in the future.

If you want to know all the changes in the 3 Helm, please see the official document: https://helm.sh/docs/faq/#changes-since-helm-2

This article reprinted from: RancherLabs, Click to view the original text .

" Alibaba Cloud native concern micro service, Serverless, container, Service Mesh and other technical fields, focusing cloud native popular technology trends, cloud native large-scale landing practice, most do understand the developer's native cloud technology circles."