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

This article will explain in detail how Helm solves the problem of deploying applications in Kubernetes. The content of the article is of high quality, so Xiaobian shares it with you as a reference. I hope you have a certain understanding of relevant knowledge after reading this article.

I. Background

Kubernetes(k8s) is a leading solution for distributed architecture based on container technology. Based on Docker technology, it provides a series of complete functions such as deployment operation, resource scheduling, service discovery and dynamic scaling for containerized applications, which improves the convenience of large-scale container cluster management.

With container cloud environments and containerized services beginning to be deployed on a large scale in the industry, what is the actual application of Kubernetes in the industry? At this year's JFrog SwampUp user conference, Codefresh showed off some interesting data. As shown below:

According to Codefresh, 80% of JFrog's current enterprise users have already used Kubernetes, indicating that Kubernetes has been recognized by the industry and has begun to be widely used. However, only 5% of JFrog users use Kubernetes in production. In other words, companies are more likely to use Kubernetes in their own R & D and testing environments. What is the reason for this? JFrog has proved through its own practice on Kubernetes that "Kubernetes is hard", directly using Kubernetes to deploy and manage containerized cloud services, especially microservice-based cloud services, is a very challenging job.

How can Kubernetes be applied more easily? JFrog chose Helm, the official package management tool for Kubernetes. Let's look at another set of data provided by Codefresh, as shown below:

As in the previous data set, only 5% of JFrog enterprise users use Kubernetes in production. However, 5% of JFrog users use Helm. It can be seen that when Kubernetes is applied to the production environment, many enterprises, like JFrog, choose Helm.

Why is Helm so popular? This article will introduce and analyze the advantages of Helm through the practice of JFrog implementing Helm and Kubernetes.

2 What is Helm?

Before we talk about Helm, let's look at the challenges of deploying cloud services directly with Kubernetes.

Kubernetes uses yaml files to describe and manage the configuration and deployment requirements of individual components in the service, one for each component. Today's cloud services are usually composed of multiple components, how to configure and handle these components, that is, the association between multiple yaml files, has become an additional task for Kubernetes applications. When a cloud service upgrade involves only one or more modules, the association between the new yaml file and the existing yaml file of the upgrade module becomes more complex, thus increasing the difficulty of configuring and managing the upgrade using Kubernetes.

Second, Kubernetes records component configuration information directly into the yaml file. This approach is indeed clearer from the perspective of describing components. However, when the deployment of cloud services faces multiple environments, such as different development, test, and production environments (which are also common application scenarios today), how do you handle the differences between these environment configurations? To develop and maintain a different set of yaml files for each environment? This obviously increases the difficulty and workload of applying Kubernetes.

Also, Kubernetes 'yaml file itself is not versioned. So when a deployment fails and you need to roll back to the previous stable release, which set of yaml files should you choose to handle? Obviously, it takes a lot of extra work to handle.

How does Helm solve these problems?

Helm (https://helm.sh) is the official package management tool for Kubernetes. Helm describes and manages cloud services through a package called Helm Chart. Helm Chart corresponds to a structured set of directories and yaml files, which can be roughly divided into three parts:

1. Template

Under the templates directory is a set of yaml files that describe each component of the cloud service, similar to the current usage of Kubernetes. Helm organizes these yaml files in the same directory, which makes it easy to understand the composition of current cloud services, with clear structure and easy management.

2. Configuration and Dependency

The yaml file in the templates directory contains no specific configuration information, only references to configuration keys. The configuration information (values) that actually correspond to the target environment is stored in the values.yaml file. Of course, values.yaml only stores some default, static configuration information, which can be dynamically added or modified during deployment. This separation of configuration and application design makes it easy to deploy the same set of templates to different target environments, simply by updating the values.yaml file or dynamically modifying the configuration information during deployment.

In addition, for some cloud services or components that are already widely used, there are already mature and proven Helm Charts. When these services or components are used, the dependencies can be described directly in the requirements.yaml file. At deployment time, Helm automatically retrieves these dependencies for Helm Chart use and stores them in the charts directory. This dependency design avoids a lot of repetitive work and makes parallel development and sharing of Helm Chart possible.

3. Versioning

Each Helm Chart package can define its own version in the Chart.yaml file. In addition, each Helm deployment automatically generates a release. Using Helm's commands, queries, upgrades, rollbacks, and other administrative tasks for these deployed versions can be easily implemented.

III. Application Practice of Helm

From the above introduction and analysis of Helm, we can see that Helm can solve the problem of Kubernetes application deployment well. JFrog also makes good use of Helm in its Kubernetes practice.

At present, Helm is used on the CI/CD pipeline of each JFrog product for deployment on Kubernetes, and it can be deployed on any version combination of 100+ different product lines every week, with more than 50 microservices deployed each time. JFrog will also provide these Helm Charts to customers to help them quickly deploy JFrog's various products in the Kubernetes environment.

JFrog has also accumulated some experience and best practices in the process of implementing Helm.

1. Separation of configuration and application

Use the same Helm Chart for all environments, but configure your own values.yaml file for different environments. At the same time, these values.yaml files are versioned according to changes in the target environment.

2. Make good use of dependence

There are already many products and common components that implement a well-established and proven Helm Chart, which can be found at https://hub.kubeapps.com. When we develop our own Helm Chart, we can make full use of these existing achievements by defining dependencies, reducing the workload and improving the quality of the product.

Check Helm Chart before actual deployment

Helm provides a number of useful commands to help us check Helm Chart for errors before actual deployment and reduce the risk of using it. For example:

· helm lint

Helm lint can be used to check if there is a problem with the downloaded Helm Chart

· helm install -debug -dry-run

helm install with dry-run parameter to check Helm Chart's various configurations correctly without actually performing deployment

For Helm commands and their specific usage, please refer to Helm's official documentation, https://docs.helm.sh.

4. Fully utilize the power of the community

At present, there are many developers who are studying and practicing Helm. We should make full use of their experience and achievements and actively communicate with them to improve the efficiency and quality of our use of Helm.

Commonly used communities for Helm communication include:

· GitHub issues: https://github.com/helm/charts/issues

· Slack: #helm-users room in the Kubernetes Slack (https://kubernetes.slack.com/)

· Slack: #helm-dev room in the Kubernetes Slack (https://kubernetes.slack.com/)

IV. Helm Warehouse

Here is Helm's application architecture:

Among them, Tiller is deployed in Kubernetes environment to perform application deployment and other operations. Helm, as a client, completes the management and deployment tasks of Helm Chart. In this architecture, the Helm Storage stores the various Chart files, dependency packages, and configuration information needed for Helm deployment, and plays a very important role in Helm deployment.

JFrog's Artifactory product, as the only unified product management warehouse in the world that provides Helm warehouse support, can provide one-stop unified service and management for related products such as docker images, versioned configuration information, and various dependent products while providing warehouse support for Helm Chart. JFrog's Xray product, integrated with Artifactory's unified product warehouse, can automatically scan security vulnerabilities and analyze the impact scope of vulnerabilities.

For detailed introduction, capability analysis and user cases of JFrog products, please refer to the series of articles on this public account and the relevant introduction on the official website (http://jfrogchina.com).

V. Summary

Deploying cloud services through Kubernetes has seen widespread adoption in the industry. Helm can greatly reduce the difficulty of Kubernetes deployment, improve the efficiency and quality of deployment through its unified management, configuration and application separation, versioning and other features, and gradually get a lot of attention and application.

JFrog's Artifactory and Xray products can provide unified product warehouse management and security vulnerability scanning including Helm warehouse, which plays an important role in realizing CI/CD pipeline and automatic deployment scheme based on Helm. Codefresh has built its own product pipeline using JFrog products and related tools and is widely used.

How Helm solves the problem of deploying applications in Kubernetes is shared here. I hope the above content can help you and learn more. If you think the article is good, you can share it so that more people can see it.

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.