Five highlights of the Helm Summit 2019 in Amsterdam
Note perev. : The increased interest in the “Kubernetes package manager” - Helm, which has been observed recently, is easy to explain. The long-awaited major update to Helm v3, which we already wrote about, is in the active stage - and not only of development, but of releases as well . His latest beta, the third in a row , was released in early September. And quite recently, a rather large (for such a specialized Open Source project) event took place, the impressions from which its visitors from CloudARK, which offers iPaaS (integration platform as a service) for Kubernetes, share.
Original photo taken from CNCF Flickr account
Helm Summit was held in Amsterdam last week. It brought together about 150 enthusiasts representing various users and service providers on Kubernetes. Here are five key points from this event.
The Summit was attended by some of the key members of the core Helm development team. From their speeches and communication on the sidelines, it became clear that Helm 3.0 will be an important milestone for the project. Many of you have probably heard that the third version will not have Tiller - the Helm server component. ( Note : More on this can be found in this article .) Helm 3.0 will introduce other important innovations, such as closer security controls and better support for Custom Resource Definitions (CRDs). Here are three key aspects that I especially remember:
Several sessions were devoted to the problems of storing Helm charts. These sessions were led by Josh Dolitsky , author of the ChartMuseum . He presented the problem, the existing solutions and spoke about the general trends in this space. The main conclusion is that the work with the various artifacts that you have to deal with in the cloud-native approach (Docker images, Helm charts, Kustomize patch files) should be consistent.
The ORAS project - OCI Registry as Storage is called upon to ensure the storage of all these artifacts in a single registry. For Kubernetes users, this is definitely a step in the right direction, since it will allow you to consolidate various artifacts in one registry, while at the same time providing support for things like registry splitting, access control, etc.
Several speakers addressed the topic of user controllers and operators in their speeches. CloudARK's presentation focused on best practices for creating Helm charts for operators. The Red Hat team talked about operators and the Operator Hub .
Representatives from Workday , Weaveworks, and the University of Notre Dame discussed the Kubernetes-native approach to continuously negotiate Helm-based releases in a cluster using a process called GitOps. ( Note translate : Read more about GitOps here .)
The key conclusion of all these performances was that Helm and the operators complement each other well. While the former (Helm) focuses on the template and simplicity of managing artifacts, the latter (operators) concentrate on managing Day-2 tasks (i.e., at the stage of the system’s life cycle when it begins to bear fruit to its creators - approx. ) for third-party software such as relational / non-relational databases running in a Kubernetes cluster.
When it comes to large enterprise applications, one Helm chart is not enough. A few charts are required. The presentation of GitLab was a real discovery in this sense. They have many charts, while the average size of the chart is also quite large (several thousand lines). Managing all of these charts is a challenge in itself.
There were two interesting presentations on various aspects of this problem. In one , the IBM team presented its internal tool that simplifies the search for Helm charts by various criteria. They focused on solving the problem of DevOps engineers, who were forced to select and install charts in their clusters. In another, the Replicated team talked about trying to solve the problem of managing Helm chart edits without creating copies or forks. The essence of their approach is to separate the basic Helm chart, and create custom Helm charts by borrowing the idea of kustomize from patch files. In the future, we can witness rapid activity in this direction as various providers concentrate on various aspects of Helm charts that affect their management. For example, we at CloudARK focus on Helm charts for operators that receive special
annotations to make it easier to discover and make Custom Resources easier to use.
Helm developers and key members of the community turned out to be very friendly people. They were open and available for any discussions and questions, such as release dates, thoughts about Helm and kustomize, joint events with KubeCon, etc.
They also talked about the process of participating in the development of Helm. He did not seem too complicated. The Helm project has not yet adopted the KEP process (Kubernetes Enhancement Proposal). However, this may change after the incubation stage is completed.
Our presentation at the summit was devoted to the principles and best practices of creating Helm charts for operators. We offer iPaaS, which allows DevOps teams to build their own Kubernetes platform stacks without any binding to the Kubernetes provider or proprietary interfaces. The necessary CRD / operators are packaged in the form of Helm charts with special emphasis on the compatibility of Custom Resources from various operators.
The presentation was based on lessons learned from the independent development of several operators and the analysis of more than one hundred publicly available operators in order to get a custom Kubernetes Native platform layer, ready for corporate use.
The conference venue boasts scenic views of one of Amsterdam's many canals.
Helm is on the verge of becoming a top-level CNCF project. Over the past few years, he has become more mature, has gained a strong community and high popularity. If you are not using it yet, give it a try. It offers one of the easiest ways to template and manage Kubernetes artifacts. For those already heavily using it, Helm 3.0 should dispel many security concerns and provide explicit support for Kubernetes extensibility through CRD.
Other impressions of the past Helm Summit and his reports can be found on Twitter using the #HelmSummit tag.
Read also in our blog:
Original photo taken from CNCF Flickr account
Helm Summit was held in Amsterdam last week. It brought together about 150 enthusiasts representing various users and service providers on Kubernetes. Here are five key points from this event.
1. In Helm 3.0 - better security, CRD support and some changes that break the usual approach
The Summit was attended by some of the key members of the core Helm development team. From their speeches and communication on the sidelines, it became clear that Helm 3.0 will be an important milestone for the project. Many of you have probably heard that the third version will not have Tiller - the Helm server component. ( Note : More on this can be found in this article .) Helm 3.0 will introduce other important innovations, such as closer security controls and better support for Custom Resource Definitions (CRDs). Here are three key aspects that I especially remember:
- In the security area, the set of pre-configured permissions for users by default will be minimal. Unlike Tiller, which automatically received administrator rights to the entire cluster, in Helm 3.0 you will have to manually grant privileges to user (User) and service (Service) accounts designed to work with Helm. This change guarantees informed decision-making by administrators about the security of their clusters.
- The second major change is enhanced CRD support. In the current version of Helm, CRD is installed via the
crd-install
hook, defined as an annotation. However, not all CRD developers and operators use it. This makes the Helm charts vulnerable to installation errors, since correctly setting the charts requires CRDs to be placed in front of Custom Resource manifests. Helm 3.0 will bring CRD support to a new level. Thechrts
subdirectory will appear in thecrd
directory. It will be enough for the user to add all the CRD YAML files to this directory. Helm will process it before setting the rest of the chart. This procedure will ensure that CRD is installed before installing Custom Resource manifests. - Major changes will affect the work with the CLI. For example, now during the installation of the chart, a random release name is generated if it is not specified as an input parameter. In Helm 3.0, the situation will be the opposite: a parameter with a name will become mandatory. To preserve the random naming of releases, you will need to specify a special flag when entering the command.
2. Consolidation of cloud native artifacts
Several sessions were devoted to the problems of storing Helm charts. These sessions were led by Josh Dolitsky , author of the ChartMuseum . He presented the problem, the existing solutions and spoke about the general trends in this space. The main conclusion is that the work with the various artifacts that you have to deal with in the cloud-native approach (Docker images, Helm charts, Kustomize patch files) should be consistent.
The ORAS project - OCI Registry as Storage is called upon to ensure the storage of all these artifacts in a single registry. For Kubernetes users, this is definitely a step in the right direction, since it will allow you to consolidate various artifacts in one registry, while at the same time providing support for things like registry splitting, access control, etc.
3. Helm and operators
Several speakers addressed the topic of user controllers and operators in their speeches. CloudARK's presentation focused on best practices for creating Helm charts for operators. The Red Hat team talked about operators and the Operator Hub .
Representatives from Workday , Weaveworks, and the University of Notre Dame discussed the Kubernetes-native approach to continuously negotiate Helm-based releases in a cluster using a process called GitOps. ( Note translate : Read more about GitOps here .)
The key conclusion of all these performances was that Helm and the operators complement each other well. While the former (Helm) focuses on the template and simplicity of managing artifacts, the latter (operators) concentrate on managing Day-2 tasks (i.e., at the stage of the system’s life cycle when it begins to bear fruit to its creators - approx. ) for third-party software such as relational / non-relational databases running in a Kubernetes cluster.
4. Helm Chart Management Issues
When it comes to large enterprise applications, one Helm chart is not enough. A few charts are required. The presentation of GitLab was a real discovery in this sense. They have many charts, while the average size of the chart is also quite large (several thousand lines). Managing all of these charts is a challenge in itself.
There were two interesting presentations on various aspects of this problem. In one , the IBM team presented its internal tool that simplifies the search for Helm charts by various criteria. They focused on solving the problem of DevOps engineers, who were forced to select and install charts in their clusters. In another, the Replicated team talked about trying to solve the problem of managing Helm chart edits without creating copies or forks. The essence of their approach is to separate the basic Helm chart, and create custom Helm charts by borrowing the idea of kustomize from patch files. In the future, we can witness rapid activity in this direction as various providers concentrate on various aspects of Helm charts that affect their management. For example, we at CloudARK focus on Helm charts for operators that receive special
platform-as-code
annotations to make it easier to discover and make Custom Resources easier to use.
5. Hospitable community
Helm developers and key members of the community turned out to be very friendly people. They were open and available for any discussions and questions, such as release dates, thoughts about Helm and kustomize, joint events with KubeCon, etc.
They also talked about the process of participating in the development of Helm. He did not seem too complicated. The Helm project has not yet adopted the KEP process (Kubernetes Enhancement Proposal). However, this may change after the incubation stage is completed.
CloudARK at Helm Summit
Our presentation at the summit was devoted to the principles and best practices of creating Helm charts for operators. We offer iPaaS, which allows DevOps teams to build their own Kubernetes platform stacks without any binding to the Kubernetes provider or proprietary interfaces. The necessary CRD / operators are packaged in the form of Helm charts with special emphasis on the compatibility of Custom Resources from various operators.
The presentation was based on lessons learned from the independent development of several operators and the analysis of more than one hundred publicly available operators in order to get a custom Kubernetes Native platform layer, ready for corporate use.
Amsterdam
The conference venue boasts scenic views of one of Amsterdam's many canals.
Conclusion
Helm is on the verge of becoming a top-level CNCF project. Over the past few years, he has become more mature, has gained a strong community and high popularity. If you are not using it yet, give it a try. It offers one of the easiest ways to template and manage Kubernetes artifacts. For those already heavily using it, Helm 3.0 should dispel many security concerns and provide explicit support for Kubernetes extensibility through CRD.
PS from the translator
Other impressions of the past Helm Summit and his reports can be found on Twitter using the #HelmSummit tag.
Read also in our blog:
All Articles