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

Today, I would like to talk to you about how to understand Helm 3. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something from this article.

After a long period of development, Helm 3 finally released its first alpha version today. This article will briefly introduce the new features of Helm 3.

Remove Tiller

Helm 2 is the C Release S architecture, which is mainly divided into client-side helm and server-side Tiller;, which are the same as the previous version. Helm 3 also provides precompiled binaries on the Release page. The difference is that when you download the original binary package, you will see helm and tiller. Helm is the only thing left in Helm 3.

Tiller is mainly used to manage the released versions of various applications in the Kubernetes cluster. Tiller is removed from Helm 3, and version-related data is stored directly in Kubernetes.

Now let's use Helm directly on a newly created cluster. To create a test cluster, please refer to my previous article to build your local Kubernetes cluster using Kind.

As in previous versions, we need to execute helm init to initialize. But now the initialization is much easier, and there is no need to deploy Tiller to the cluster.

(MoeLove) ➜~ export HELM_HOME=/tmp/helm3

(MoeLove) ➜~ helm3 init

Creating / tmp/helm3/repository

Creating / tmp/helm3/repository/cache

Creating / tmp/helm3/plugins

Creating / tmp/helm3/starters

Creating / tmp/helm3/cache/archive

Creating / tmp/helm3/repository/repositories.yaml

Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com

$HELM_HOME has been configured at / tmp/helm3.

Happy Helming!

Previously, because of the existence of RBAC, we had to create a ServiceAccount when we started using it, but now the permissions of Helm are the same as those of the users configured in the current KUBECONFIG, which is very easy to control.

This also greatly enhances the security of using Helm.

Release names can be reused between different ns

This is a feature mentioned in Helm Release. However, this feature is not currently available directly and the relevant issue has been created.

(MoeLove) ➜~ helm3 list

NAME NAMESPACE REVISION UPDATED STATUS CHART

Redis1 default 1 2019-05-17 00 21 06.686127031 + 0800

Redis default 1 2019-05-1700 CST deployed redis-7.1.0 19Vera 28.234013017 + 0800

(MoeLove) ➜~ helm3-n moelove install redis1 stable/redis

Error: cannot re-use a name that is still in use

The root lies in the acquisition and implementation of namespace parameters.

The corresponding code is:

Func getNamespace () string {

If ns, _, err: = kubeConfig () .ToRawKubeConfigLoader () .Namespace (); err = = nil {

Return ns

}

Return "default"}

Namespace in Kubeconfig is used directly, so we can do the following to use this feature.

(MoeLove) ➜~ kubectl config current-context

Kubernetes-admin@moelove

(MoeLove) ➜~ kubectl config set-context kubernetes-admin@moelove-- namespace moelove

Context "kubernetes-admin@moelove" modified.

(MoeLove) ➜~ helm3-n moelove install redis stable/redis

.. # omit output

(MoeLove) ➜~ helm3 list

NAME NAMESPACE REVISION UPDATED STATUS CHART

Redis moelove 1 2019-05-17 00 CST deployed redis-7.1.0 26 redis moelove 44.572578745 + 0800

As you can see, the release name redis can be reused in the Namespace of moelove.

You must specify a release name

In Helm 2, if you do not specify a name for release, a name is automatically randomly generated. However, in Helm 3, you must actively specify the name, or add the parameter-- generate-name. For example:

(MoeLove) ➜~ helm3 install stable/redis

Error: must either provide a name or specify-- generate-name

(MoeLove) ➜~ helm3 install stable/redis-- generate-name

.. # omit output

(MoeLove) ➜~ helm3 list

NAME NAMESPACE REVISION UPDATED STATUS CHART

Redis1 default 1 2019-05-17 00 21 06.686127031 + 0800

Redis-1558024567 default 1 2019-05-17 00 36 09.2946 32336 + 0800

Redis default 1 2019-05-17 00 Chart 19V 28.234013017 + 0800 CST deployed redis-7.1.0 supports push of Chart to Docker image repository

In short, use an image repository to store both Docker images and Helm 3 Chart, but I haven't verified this feature yet. We'll verify it later when we have time.

Removed helm serve

In Helm 2, you can simply start a local simple HTTP service through helm serve to host Chart information in the local local repo.

However, this feature has been removed in Helm 3. Maybe the usage scenario is limited.

Summary

The change to Helm 3 is relatively large, but the choice to remove Tiller is very correct, which makes the management of cluster permissions easier and clearer. For more information about Helm 3, please follow ReleaseNote.

After reading the above, do you have any further understanding of how to understand Helm 3? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.