Shulou(Shulou.com)05/31 Report--

Why must turn as soon as possible, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

We will talk to you about why we should switch to Helm V3 as soon as possible.

After studying "Open Cloud Native Tencent App Center (AppHub)", programmer Xiao Zhang seems to have understood what "cloud native applications" are all about.

"it's just Helm!"

As he spoke, Xiao Zhang prepared to package the "library management system" he had developed for many years into Charts through Helm and submit it to AppHub for a try.

"in this way, developers all over China can use the library management system I developed!"

I'm a little excited to think about it!

However, before the compilation was finished, Xiao Zhang found that there was a prompt on the official Helm document that was very harsh:

So, what's going on?

The Origin of Helm Project

Helm is one of the most widely used open source projects for application management in the cloud native technology system. According to the KubeCon EU 2019 summary report just released by CNCF, Kubernetes (K8s), Prometheus and Helm are once again the top three most watched open source projects on KubeCon.

The release of the Helm project itself dates back to the time when Deis was an independent startup.

Container PaaS (so-called CaaS) was in the ascendant in 2016, but it also began to show signs of homogenized competition and low value-added, and Deis, which was committed to selling to Engine Yard, was particularly difficult in the Red Sea. Fortunately, a keen technical sense of smell finally "saved" the team. At the end of 2016, Deis began to fully switch to the K8s system, and soon released a series of open source projects specifically for K8s application management. Among them, Helm, which is positioned as the "K8s application package manager", is the most popular.

We know that K8s itself does not have the concept of "application". For example, the "library management system" that Xiao Zhang will deploy on K8s is actually made up of four YAML files:

Web-deploy.yaml, Java Web program described by Deployment of K8s

Web-svc.yaml, the entry of program access described in Service of K8s

Mysql.yaml, MySQL instance described in K8s StatefulSet

Mysql-svc.yaml, the access entry to the MySQL instance described in K8s Service.

Then, Xiao Zhang needs to execute four times.

`kubectl apply-f`

Submit these YAML files to K8s to run and manage the application. The trouble here is, how to manage all the K8s resources corresponding to this application?

So the Helm project provides a simple idea: it defines a new application packaging format called Chart. The file layout of a myapp application is as follows:

Myapp/ Chart.yaml values.yaml templates/

Chart.yaml is used to write application metadata, such as:

ApiVersion: v1name: library management system version: 0.1description: the most popular library management system in China maintainers:-name: Xiao Zhang

In the templates/ directory, store the four YAML files written by Xiao Zhang.

In addition, Xiao Zhang can also define the fields that need to be modified in the YAML as "template variables", which will be injected by Helm at deployment time. For example, web-deploy.yaml:

ApiVersion: apps/v1kind: Deploymentmetadata: name: library management system website spec: replicas: {{.Values.replicaCount}} template:. Spec: containers:...

Through the above syntax, Xiao Zhang defines the replicas value of this Deployment as a variable. In the future, he can pass parameters to determine how many instances the library management system will have after startup. For example, specify 100 instances:

Helm install apphub/ Library Management system-- set replicaCount=100

Finally, the Helm project allows you to upload the above series of files and directories into a zip file and upload them online so that they can be downloaded and installed by others through helm install. The uploaded address is Helm Hub.

This method of application packaging solves the difficulty of K8s application management to a great extent, so it won the favor of developers soon after it was launched. Helm Hub has also become the second important application distribution center in the cloud native technology system after Docker Hub.

Architecture issues of Helm

However, the above process sounds simple, but Helm used a "bizarre" architecture at the beginning of the project.

It is conceivable that Helm can actually call K8s API on the client side to complete these functions, whether installing or updating the application. But the reality is that Helm must deploy a Server called Tiller in the Kubernetes cluster, and then submit all the requests to Tiller, and then Tiller will interact with K8s APIServer to complete the installation of the application. This complex process can be clearly shown in the following figure:

This "icing on the cake" architecture not only becomes an assumption where Helm is released, but also runs through the entire project life cycle of Helm v2.

Why does Helm insist on placing a Server end on K8s?

One of the important reasons here is that the Helm project does not just want to be a simple "K8s application packaging tool".

As an authentic PaaS service provider, Deis has known from the very beginning that "application packaging" is only the entrance to its complete puzzle, and the existence of Tiller is an important foreshadowing for Helm to become a "new PaaS" in the future cloud native era.

Tiller, a server-side component, is actually equivalent to an application management controller inserted by Helm in K8s. With it, Helm can not only easily store the application-related state on the K8s side, but also gradually build a micro-PaaS function based on Tiller in K8s. Moreover, the establishment and development of these functions do not need to rely on the application management capability of K8s itself.

This also explains why Helm quickly came up with the concept of Release and released the ability to upgrade and rollback applications such as helm upgrade and helm rollback. In fact, these designs are inextricably linked with the idea of the final PaaS of Helm.

Helm v3: necessity and imperative

However, this evolution of Helm has really stumbled in Kubernetes, an infrastructure system that is inherently "application-centric".

We know that Kubernetes is designed around declarative API. The essential purpose of Kubernetes's container orchestration concept and APIServer implementation and extension mechanism is to help users shield out the complexity of infrastructure management and allow users to describe their intentions and demands through a unified and clean declarative API, which is an important basis for Kubernetes to become a "The Platform of Platform".

This is why Kubernetes combines containers from the beginning to simulate the behavior of process groups with the concept of Pod, and insists on using declarative API with controller models for application orchestration, driving the continuous operation of the entire system through the creation and updating of API resource objects (PATCH).

The final effect of this design is that users only need to store a YAML file that "describes" the application in etcd, and then drive the state of the entire infrastructure through the controller model to constantly approach the state declared by the user, which is the core working principle of Kubernetes. This theory is the core and foundation of Google Borg/Omega application management and orchestration, and it is also the biggest difference between K8s and Mesos resource manager projects.

At this time, it is not difficult for us to find out. Some of the things that Helm is trying to push are in direct conflict with the design of K8s.

In theory, Helm only needs to submit the application description file to K8s, and the rest of the operation such as application startup, release and rollback can be handed over to K8s. For example, in the Deployment semantics of K8s, a very detailed rolling update strategy has been provided for users. These are the main fields in the application description (YAML file):

Yamlstrategy: type: Rolling rollingParams: updatePeriodSeconds: 1 intervalSeconds: 1 timeoutSeconds: 120 maxSurge: "20" maxUnavailable: "10"

But now, Helm itself has built-in application update and rollback strategies, and they have nothing to do with K8s strategy, all through Tiller to help you do it.

This puts users in a very awkward position: do I still want to define and use the scrolling update parameters of K8s?

In addition, Tiller actually takes over some other core functions of K8s, such as the implementation of PATCH API. All this makes users feel confused. after all, in most cases, users learn K8s API before starting to use Helm.

Of course, it is understandable that Helm made such a decision in the first place.

In 2016-2017, application management was not the main core competence of K8s, and few people realized what K8s's extraordinarily complex declarative API, especially PACTH API, meant-even though most of the theory of "K8s declarative application configuration" actually existed in the most inconspicuous corner of K8s document library. Therefore, at that time, the first idea that came to mind for application management on K8s was basically to install a Controller in K8s. In fact, the Google Cloud team itself came up with a plug-in called Deployment Manager, which was later merged with the Tiller section.

But the magic of the open source community lies in the magical power of users to vote with their feet.

The Helm project was set up as a "K8s package management tool" to make the project start in the cloud native community, but at the same time, the strange existence of Tiller has also become a stumbling block to the further development of the Helm project. For a long time, Tiller components bring confusion, security risks, deployment and maintenance complexity, almost occupy the vast majority of the Helm community. Some manufacturers even released their own "go to Tiller" Helm distribution to express their "protest".

On the other hand, the declarative application management idea of K8s did not go to the way of external Controller, but chose to continue to enrich and improve the application management and release capabilities in K8s itself, which soon became a top priority for the entire K8s community (this story, we will introduce you further in the following "Cloud Native Application Management Series"). As a result, the built-in application management system of Helm itself begins to drift away from the upstream community.

When ecology and community begin to run counter to the development of the project, "self-revolution" naturally becomes an imperative choice.

Helm v3, an important milestone in cloud native application management

In addition to removing Tiller and making Helm a pure client-side tool, there are some important changes in Helm v3 over Helm v2:

The Release name can be narrowed down to the scope of Namespace, and the enable option-generate-name needs to be displayed: this further standardizes and improves the name problem of Helm applications.

Merge requirements.yaml to Chart.yaml that describe application dependencies: further reduce the learning burden on users

Support helm push to remote Helm Hub, support login authentication

Support for storing Charts in container image Registry: eliminating the coincident location of Helm Hub and DockerHub

Support for LUA syntax: existing template variables are actually very problematic, which we will describe in more detail in subsequent articles

Verify the content in values.yaml

...

After such refactoring, Helm v3 has begun to adjust its development direction, playing down the idea of making a "micro PaaS", paying more attention to application packaging and basic management functions, and exchanging more freedom and space to the K8s community.

This change is welcome for both the Helm community and cloud native application developers. It is not difficult to predict that Helm v3 will most likely become an important tool in the future cloud native application management system, and the corresponding App Hub will also become an important link in the process of cloud application distribution and hosting.

In the cloud native era, is there any reason not to try Helm v3?

After reading the above, have you mastered the method of why you must turn as soon as possible? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.