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

How to create their own Helm Chart, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Preface

In our daily life, we often deal with a variety of applications on different platforms, such as Taobao, Gaode and Alipay downloaded from Apple's App Store, or Word, Photoshop and Steam installed on PC. For most of these applications on various platforms, users only need to click to install.

However, on the Kubernetes, deploying an application is often not that easy. If you want to deploy an application to the cloud, you must first prepare the environment it needs and package it into a Docker image, and then put the image in the deployment file (Deployment), configuration service (Service), account (ServiceAccount) and permissions (Role), namespace (Namespace), key information (Secret), persistent storage (PersistentVolumes) and other resources. That is to write a series of interrelated YAML configuration files and deploy them on the Kubernetes cluster.

But even if the developers of the application can store these Docker images in a public repository and provide the required YAML resource files to users, users still need to find these resource files themselves and deploy them one by one. If a user wants to modify the default resources provided by the developer, such as using more copies (Replicas) or modifying the service port (Port), he also needs to find out where the resource files need to be modified, not to mention how much trouble version changes and maintenance will cause to developers and users.

It can be seen that the most primitive Kubernetes application form is not convenient.

Helm and Helm Chart

In such an environment, a series of Kubernetes-based application package management tools came out of nowhere. And our protagonist today, Helm, is one of the most popular choices.

Developers package the resource files required by the application according to Helm Chart format, expose some variable fields (such as which port to expose and how many copies to use) by Templating, and finally store the packaged application package, namely Helm Chart, in a unified warehouse for users to browse and download.

From the user's point of view, the user can install, uninstall and upgrade the application with a simple command. The post-installation status can also be queried through helm list or native kubectl.

$helm install redis stable/redis$ kubectl get podsNAME READY STATUS RESTARTS AGEredis-master-0 1 Running 0 63sredis-slave-0-0 1 63sredis-slave-1 1 Running 0 63sredis-slave-1-0 1 63sredis-slave-1 1 Running 0 13s$ helm delete redis Creative Helm Chart

So from the developer's point of view, how should we create a Helm application package?

Preparatory work

First of all, we need an image ready for deployment. This image can be a Java program, a Python script, or even an empty linux image to run a few commands.

Here we use a simple golang-based hello world HTTP service. The service gets the user-defined name by reading the environment variable USERNAME, and then listens on port 80. For any HTTP request, return Hello ${USERNAME}. For example, if you set USERNAME=world (the default scenario), the service will return Hello world.

Then we use Dockerfile to package the image. First compile the Golang code, and then put the compiled program in an alpine-based image to reduce the size of the image.

After Docker builds the image, we upload the image to the repository, such as Docker Hub or Ali Cloud container image repository. After the preparatory work is done, we can start to create Helm Chart.

Start to create

Run helm create my-hello-world and you will get an empty chart automatically generated by helm. The name in this chart is my-hello-world. It is important to note that the my-hello-world name in Chart needs to be the same as the generated Chart folder name. If you modify the my-hello-world, you need to make consistent changes. Now, we see that the folder directory for Chart is as follows:

My-hello-world ├── charts ├── Chart.yaml ├── templates │ ├── deployment.yaml │ ├── _ helpers.tpl │ ├── ingress.yaml │ ├── NOTES.txt │ └── service.yaml └── values.yaml

In the Chart.yaml file under the root directory, declare the name, version and other basic information of the current Chart, which will be available for users to browse and retrieve after the Chart is put into the warehouse. For example, we can change the Description of Chart to "My first hello world helm chart". There are two version-related fields in Chart.yaml, where version indicates the version of Chart, that is, the version of our application package, and appVersion indicates the actual internal application version.

YAML files, such as Deployment and Service, are stored in the templates folder for all kinds of application deployment. In our current application, we only need one deployment, and some applications may contain different components and require multiple deployments, so we can place deploymentA, deploymentB and so on under the templates folder. Similarly, if we need to configure serviceaccount, secret, volumes, etc., we can also add the corresponding configuration files.

ApiVersion: apps/v1beta2kind: Deploymentmetadata: name: {{template "my-hello-world.fullname". }} labels: {{include "my-hello-world.labels". | indent 4}} spec: replicas: {{.Values.replicaCount}} selector: matchLabels: app.kubernetes.io/name: {{include "my-hello-world.name". }} app.kubernetes.io/instance: {{.Release.Name}} template: metadata: labels: app.kubernetes.io/name: {{include "my-hello-world.name". } app.kubernetes.io/instance: {{.Release.Name}} spec: containers:-name: {{.Chart.Name}} image: "{{.Values.image.repository}: {{.Chart.AppVersion}}" imagePullPolicy: {{.Values.image.pullP olicy}} env:-name: USERNAME value: {{.Values.Username}}.

Helm Chart's packaging of applications is not just about integrating Deployment with Service and other resources. We see that the deployment.yaml and service.yaml files are placed in the templates/ folder, with many more injectable fields for rendering than the native Kubernetes configuration. For example, in the spec.replicas of deployment.yaml, you use the static value of .Values.replicaCount instead of the Kubernetes itself. This field, which controls how many running copies the application should have on Kubernetes, can have different values in different application deployment environments, and this value is provided by the injected Values.

ReplicaCount: 1image: repository: somefive/hello-world pullPolicy: IfNotPresentnameOverride: "" fullnameOverride: "" service: type: ClusterIP port: 80.Username: AppHub

In the root directory, we see a values.yaml file that provides the default parameters for the application at installation time. In the default Values, we see replicaCount: 1, indicating that there is only one copy of the application in the default deployment state.

In order to use the image we are going to deploy the application, we see that in deployment.yaml, in spec.template.spec.containers, both image and imagePullPolicy use the values in Values. Where the image field consists of .Values.image.repository and .Chart.AppVersion.

When you see this, you should know the fields that need to be changed: one is image.repository in values.yaml, and the other is AppVersion in Chart.yaml. Match them with the docker image we need to deploy the application. Here, we set the image.repository in values.yaml to somefive/hello-world and the AppVersion in Chart.yaml to 1.0.0.

Similarly, we can look at the services to be deployed in service.yaml, and the main configuration is also in values.yaml. The default generated service exposes port 80 to the Kubernetes cluster. We don't need to modify this part for the time being.

Because the deployed hello-world service reads the USERNAME environment variable from the environment variable, add this configuration to the deployment.yaml.

-name: {{.Chart.Name}} image: "{{.Values.image.repository}: {{.Chart.AppVersion}}" imagePullPolicy: {{.Values.image.pullPolicy}} env:-name: USERNAME value: {{.Values.Username}}

Now our deployment.yaml template loads the Username field from values.yaml, so we also add Username: AppHub to values.yaml accordingly. In this way, our application will read the Username from the values.yaml and start it in the mirrored environment variable.

Check packing

After preparing our application, we can use Helm lint to roughly check whether there are any grammatical errors in the created Chart. If there is no problem, we can use the helm package command to package our Chart folder, and after packaging we can get a my-hello-world-0.1.0.tgz application package. This is the application we have completed.

$helm lint-strict my-hello-world1 chart (s) linted, 0 chart (s) failed [INFO] Chart.yaml: icon is recommended$ helm package my-hello-world

We can use the helm install command to try to install the application package we just made, and then use kubectl to check the status of running pod. Use the port-forward command to map the port of the pod to the local port, and at this point you can access the deployed application by accessing localhost.

$helm install my-hello-world-chart-test my-hello-world-0.1.0.tgz$ kubectl get podsNAME READY STATUS RESTARTS AGEmy-hello-world-chart-test-65d6c7b4b6-ptk4x-0 1ax 1 Running 0 4m3s $kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 8080 kubectl port-forward my-hello-world-chart-test-65d6c7b4b6-ptk4x 80$ curl localhost:8080Hello AppHub parameter overload

Some students may wonder, although we application developers expose configurable information in values.yaml, what should users do if they want to modify it when using the application? The answer is simple: users only need to use the set parameter when install and set the parameters they want to override.

Application developers only provide default installation parameters in the values configuration of Chart, and users can also specify their own configuration during installation. Similarly, if the user can replace install with the upgrade command, the configuration can be changed based on the previously deployed application.

$helm install my-app my-hello-world-0.1.0.tgz-- set Username= "Cloud Native" $helm install my-super-app my-hello-world-0.1.0.tgz-f my-values.yaml$ helm upgrade my-super-app my-hello-world-0.1.0.tgz-f my-new-values.yaml modification prompt

We notice that after the installation Chart instruction runs, the output of the screen appears:

NOTES:1. Get the application URL by running these commands: export POD_NAME=$ (kubectl get pods-l "app=my-hello-world,release=my-hello-world-chart-test2"-o jsonpath= "{.items [0] .metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080

The comments here are provided by templates/NOTES.txt in Chart.

We noticed that the "app= {{template" my-hello-world.name ".}}, release= {{.Release.Name}" written in the original NOTES is different from the configuration written in deployment.yaml. We can change it to "app.kubernetes.io/name= {{template" my-hello-world.name ".}, app.kubernetes.io/instance= {{.Release.Name}" and update the version in values.yaml to 0.1.1. Then repackage Chart (run helm package), get the new my-hello-world-0.1.1.tgz, upgrade the original Chart (run helm upgrade my-hello-world-chart-test2 my-hello-world-0.1.1.tgz-- set Username= "New Chart"), and you can see the updated NOTES.

NOTES:1. Get the application URL by running these commands: export POD_NAME=$ (kubectl get pods-l "app.kubernetes.io/name=my-hello-world,app.kubernetes.io/instance=my-hello-world-chart-test2"-o jsonpath= "{.items [0] .metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080 export POD_NAME=$ App sharing

So how do you share the finished application with others? ChartMuseum, officially launched by Helm, provides a way to build Chart repositories, which you can use to create your own Chart repositories. However, it is expensive to maintain a warehouse on its own, and for users, if each developer is his own warehouse, he needs to add the corresponding warehouse of the required applications to his own search list, which is not conducive to the dissemination and sharing of applications.

Our team recently launched open cloud native Tencent App Center and Cloud Native App Hub, which synchronizes all kinds of applications and provides a channel for developers to upload applications.

In our open cloud native Tencent App Center, applications come from two channels:

On the one hand, we regularly synchronize Chart resources from some well-known foreign Helm repositories. In the process of synchronization, we synchronously replace some Docker images used internally in Chart (such as gcr.io or quay.io images) to facilitate domestic users to access and use them.

On the other hand, like the Helm official library, we accept developers to submit their applications through Pull Request on Github. Successful applications will be synchronized to the cloud native Tencent App Center in a short time and displayed together with other official apps for other users.

After reading the above, have you mastered how to create your own Helm Chart? 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.