Since the beginning of last year, Helm V3 was about to start development. At the end of last year, KubeConn Shanghai was asked by a bunch of people when the version would be released. In May, the first alpha version of Helm V3 was finally released, so let’s take a look at what the new version of Helm has to offer.

Removal of Tiller

The biggest hope at Helm 3 is to get rid of Tiller. It’s hard to imagine an open source project where the removal of one of its core components would be so popular, but it’s fair to say that Helm V3 Alpha 1’s biggest feature is the removal of Tiller.

Tiller has historically played an important role in versioning and querying cluster applications. However, with the improvement of the components of the permission control system such as RBAC and the rising demand for multi-tenancy and security, Tiller has become increasingly insecure, and the community has encountered great obstacles in the area of permission control.

The benefits of removing tiller are as follows:

  • A simpler and more flexible architecture
  • You can interact directly using the Kubernetes API
  • The client renders Chart and stores release information in the Kubernetes cluster
  • Customer barriers to use more reduced

CLI changes

  • helm delete —> helm uninstall: Once completely removed a release needhelm delete xxx --purgeNow we just need touninstallYou can,purgeAs a default behavior
  • helm inspect —> helm show: You can view the specific information of Chart here
  • helm fetch —> helm pullAnd:docker pullTo prepare for the next step of compatibility with Registry, pull Chart deployment like pull image

Breaking Changes (Warning)

  • Namespaces changes

    Helm V2 only uses Tiller’s namespace as the storage of release information, so the release name of the whole set group cannot be repeated. Helm V3 only records the corresponding information in the namespace where release is installed, so that different Namepsace releases can appear with the same name.

    For the same reason, if a release has been created using Helm V2, the upgrade cannot be performed using Helm V3 because the original single namespace information cannot be migrated to the owning namespace. This piece of migration function, the community is in development

  • Chart dependency management

    • Older versions manage Chart dependencies through requirements.yaml and requirements.lock. A requirements.yaml looks like this
    dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
- databaseCopy the code


    • The new version uses chart.yaml directly to record dependency information. The new chart.yaml format is basically the same as requirements.yaml
      dependencies:
  - name: mariadb
    version: 5.x.x
    repository: https://kubernetes-charts.storage.googleapis.com/
    condition: mariadb.enabled
    tags:
      - databaseCopy the code


  • Generate Name

    The old Helm can be installed directly without specifying a name. Helm V3 requires specifying a name

Try

Take a look at Helm V3 and download it here at github.com/helm/helm/r… . To prevent conflicts with Helm V2 installed, $HELM_HOME set an alternative location for Helm files. By default, these are stored in ~/. Helm, e.g. / TMP. Once installed, helmv3 init is initialized and ready to use.

Let’s use wordpress as an example

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 install stabel/wordpress

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 ls
NAME       NAMESPACE    REVISION    UPDATED                                    STATUS      CHART
test-v3    default      1           2019-05-27 16:50:46.100265945 +0800 CST    deployed    wordpress-0.6.13Copy the code


As you can see, the existing Chart can be migrated seamlessly to HELmV3 and is fully compatible. You just don’t need tiller to help with the setup. Previously, Helm V2 stored releases in the namespace where Tiller resides.

[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get cm -n kube-system -l OWNER=TILLER
NAME                   DATA   AGE
wordpress-default.v1   1      26h
wordpress-default.v2   1      26h
wordpress-default.v3   1      26hCopy the code


This is where Helm V2 stores the release information, and you can see it’s all in the Kube-System namespace.

[root@iZ8vbbnhdit552y4lytxpiZ ~]# kubectl get secret | grep word
test-v3-wordpress                                 Opaque                                2      26h
wordpress-default-mariadb                         Opaque                                2      26h
wordpress-default-wordpress                       Opaque                                2      26hCopy the code


At Helm V3, all information is stored under the namespace corresponding to release and is stored as Secret. That’s a big difference between V2 and V3.

Migrate from v2 to v3

  • The helm V3 can be installed seamlessly against the existing Chart, without migration
  • V2 and V3 can coexist, and Tiller can continue to exist

  • V2 installation release has been used, cannot be upgraded through V3, check

Pushing Charts to OCI Registries

There have been many developments in how to remotely host Chart. At first, it was saved locally, then compressed into a package and uploaded to remote storage such as OSS. Then, open source tools like Chartmuseum emerged in the community to provide public Chart hosting. But there is no good solution for the convenience of authority authentication. At the same time, in the back-end storage, there is no good space saving function like Docker Registry to avoid duplicate storage.

Therefore, all eyes turn to Docker Registry. After all, at present, major manufacturers have provided image hosting function, and it is a good direction to reuse this ability to host Chart. Therefore, Microsoft launched OCI Registry As Storage. According to the mirror OCI standard specification, Registry is reused to store Chart. This is now integrated into the Helm V3 pilot version.

Let’s try this feature out. Registry docker run-dp 55:5000 –restart=always –name registry registry:2

Then download a Chart package helm Fetch Stable /wordpress

[root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart save wordpress localhost:5000/wordpress:latestName: wordpress Version: 0.6.13 Meta: sha256:83 c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590 Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97 latest: saved [root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart listREF NAME VERSION DIGEST SIZE CREATED localhost: 5000 / wordpress: latest wordpress 0.6.13 c8c6 12.0 248 KiB 11 seconds [root@iZ8vbbnhdit552y4lytxpiZ ~]# ./helmv3 chart push localhost:5000/wordpress:latestThe push refers to repository [localhost:5000/wordpress] Name: wordpress Version: 0.6.13 Meta: sha256:83c48dd3c01a2952066ead67023ea14963a88db4287650baad5ea1ddd8ff9590 Content: sha256:248c8c68f4f614003c8b1a9d78787e5f07e979e9b996981df993cf380f498c97 latest: Pushed to Remote (2 layers, 12.6kib total)Copy the code


This completes the ability to push Chart to Registry. The feature is currently experimental, but the community expects everyone to switch to it in the future.

What’s Next

  • Alpha1: Remove Tiller, provide Library Charts, change the storage format to Secret, and start OCI integration
  • Alpha2: Better OCI integration, Lua template support
  • Alpha3: Refactoring the update policy (either client-side or server-side)

Container Services Kubernetes Edition (ACK)

Ali Cloud Container Service is Kubernetes certified service provider (KCSP), the only public cloud container platform that enters Gartner’s competition pattern in China. Container service Kubernetes edition (ACK) is a secure and stable enterprise container platform that supports high-performance network and storage, provides unified management of application-oriented heterogeneous resources, and provides the best cloud native support for enterprise clouds.


By: Xianlubird

The original link

This article is the original content of the cloud habitat community, shall not be reproduced without permission.