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

Helm is a package manager for Kubernetes. Two months ago, it released its third major version, Helm 3. There are many major changes in this new version. This article will introduce what I think is the most critical five aspects.

1. Remove Tiller

Helm eventually removed its server-side component, Tiller. Now, it has no agent at all. Tiller used to be a small application running on Kubernetes that listens to Helm commands and handles the actual work of setting up Kubernetes resources.

This is the most significant change in Helm3. Why does the removal of Tiller attract so much attention? First of all, Helm should be a template mechanism on Kubernetes configuration. So why do you need to run some agents on the server?

Tiller itself has some problems because it requires a cluster administrator's ClusterRole to create it. Therefore, suppose you want to run the Helm application on a Kubernetes cluster started in Google Cloud Platform. First, you need to start a new GKE cluster, then initialize the Helm with helm init, and then... Found it failed. This happens because, by default, you do not have administrator privileges assigned to your kubectl context. Now that you know this, start searching for magic commands that assign administrator privileges. After this series of operations, you may have begun to wonder if Helm is really a good choice.

In addition, because the access rights used by Tiller are different from those you configure in the context of kubectl. Therefore, you may be able to create an application using Helm, but you may not be able to create it using kubectl. If this situation is not checked out, it looks 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 results:

Helm uses the same access rights as the kubectl context

You no longer need to use helm init to initialize Helm

Release Name is in the namespace

What remains the same for Helm 3 is that it should be just a tool to perform operations on Kubernetes API. Thus, if you can use pure kubectl commands to perform an operation, you can also use helm to do so.

2. Distributed warehouse and Helm Hub

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

The predefined central warehouse has been 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 needed to execute the following command:

$helm2 install-name my-release stable/hazelcast

Now, this command doesn't work. You need to add a remote repository before you can install it. This is because there is no longer a predefined central warehouse. To install a 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 look for Chart directly in Helm Hub. For example, if you want to know in which warehouse you can find Hazelcast, you can simply execute the following command:

$helm3 search hub hazelcast

The above command lists the Chart with "hazelcast" in the name of all distributed repositories in Helm Hub.

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

The second point of view comes from users of Chart. For them, although it is slightly more difficult to install a chart now than before, on the other hand, they can install the latest chart from the main warehouse.

3. JSON Schema verification

Starting with Helm 3, chart maintainers can define JSON Schema for input values. The improvement of this feature is very important, because so far you can put anything you need in values.yaml, but the end result of the installation may be incorrect or there may be some incomprehensible error messages.

For example, you enter a string instead of a number in the port parameter. Then 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: 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, which means that requests sent to Kubernetes API will be checked for correctness. This is a major boon for Chart maintainers.

4. Helm test

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

1. Previously the test was run as Pod (it seems to need to be run all the time); now you can define it as Job.

2. The test Pod is not automatically removed (unless you use magic flag-cleanup), so by default, there is no skill, and you cannot execute helm test multiple times for a given version. Fortunately, however, test resources (Pod, Job) can now be automatically deleted.

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

5. Command line syntax

Finally, the syntax of the Helm command 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. Therefore, when writing the steps on how to install things using Helm, you need to make it clear whether the commands used are for Helm 2 or Helm 3.

For example, let's start with helm install. Now the version name has become a required parameter, although you can ignore it in Helm 2, and the name can be generated automatically. If you want to achieve the same effect in Helm3, you need to add the parameter-generate-name. Therefore, the 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 good change is that you don't need to add-purge after you delete the Helm version. Simply enter the command helm uninstall to delete all related resources.

There are other changes, such as some commands being renamed (but using the old name as aliases) and some commands being deleted (such as helm init). If you want to know more about the syntax changes of the Helm command, please refer to the official documentation:

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

Conclusion theory

The release of Helm 3 brings the tool to a new stage. As a user, I love that Helm is now just a simple client-side tool. As a Chart maintainer, Helm Hub and the approach to distributed repositories are fascinating to me. I hope to see more and more interesting changes in the future.

If you want to know all the changes in Helm 3, please check the official documentation:

Https://helm.sh/docs/faq/#changes-since-helm-2

Original text link:

Https://dzone.com/articles/helm-3-top-five-improvements

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.