[Cloud native, k8s] Introduction to Helm application package manager

Application services deployed on Kubernetes are composed of specific resource descriptions, including deployment, service, etc. Each resource object is saved in its own file or written collectively to a configuration file. Then deploy it through the kubectl apply –f demo.yaml command.

If the business system only consists of one or several such services, then the above deployment management method is sufficient.

For a complex business system, there will be many resource description files similar to the above. For example, a microservice architecture application may have as many as ten or dozens of services that make up the application. If there is a need to update or roll back an application, it may be necessary to modify and maintain a large number of resource object files involved, and this way of organizing and managing applications becomes insufficient.

Moreover, due to the lack of management and control of published application versions, application maintenance and updates on Kubernetes face many challenges, mainly facing the following problems:

How to manage these services as a whole

How to reuse these resource files efficiently

Application-level version management is not supported

(1) Introduction to Helm

Helm is a Kubernetes package management tool. Just like package managers under Linux, such as yum/apt-get, etc., Helm can easily deploy previously packaged yaml files to kubernetes.

(2) Helm has three important concepts:

helm: A command line client tool mainly used for the creation, packaging, publishing and management of Kubernetes application charts.

Chart: Directory or compressed package, used for application description, consisting of a series of files used to describe k8s resource objects.

Release: Chart-based deployment entity. After a chart is run by Helm, a corresponding release will be generated; a real running resource object will be created in k8s.

(3) Helm features

A package manager developed for kubernetes. Each package is called a Chart, and a Chart is a directory (generally, the directory will be packaged and compressed to form a single file in the name-version.tar.gz format for easy transmission. and storage)

For application publishers, Helm can be used to package applications, manage application dependencies, manage application versions and publish applications to software warehouses.

For users, after using Helm, they no longer need to understand the Yaml syntax of Kubernetes and write application deployment files. They can download and install the required applications on Kubernetes through Helm.

Helm provides powerful functions for software deployment, deletion, upgrade, and rollback of applications on kubernetes

2. Helm V3 changes

On November 13, 2019, the Helm team released the first stable version of Helm v3. The main changes in this version are as follows:

(1) Architecture changes

The most obvious change is the removal of Tiller

1) Release names can be reused in different namespaces

2) Support pushing Chart to Docker mirror warehouse Harbor

3) Use JSONSchema to verify chart values

4) Others

Helm CLI individual renames to better coordinate wording with other package managers

helm delete` was renamed to `helm uninstall

helm inspect` was renamed to `helm show

helm fetch` was renamed to `helm pull

However, the above old commands can still be used.

The helm serve command used to temporarily build Chart Repository locally has been removed.

(2) Automatically create namespace

Helm 2 created the namespace when creating a distribution in a namespace that didn't exist. Helm 3 follows the behavior of other Kubernetes objects and returns an error if the namespace does not exist.

requirements.yaml is no longer needed, dependencies are defined directly in chart.yaml.

3. Helm application package manager deployment

1. Deploy Helm client tool

Helm client download address: Releases · helm/helm · GitHub

Unzip the source code package and move it to the /usr/bin/ directory.

[root@k8s-master ~]# wget https://get.helm.sh/helm-v3.5.2-linux-amd64.tar.gz

[root@k8s-master ~]# tar xf helm-v3.5.2-linux-amd64.tar.gz

[root@k8s-master ~]# cd linux-amd64/

[root@k8s-master linux-amd64]# ls

[root@k8s-master linux-amd64]# mv helm /usr/bin/

[root@k8s-master ~]# helm #Verify whether the helm command is available

2. Helm commonly used commands

Order	describe
create	Create a chart and specify a name
dependency	Manage chart dependencies
get	Download a release. Available subcommands: all, hooks, manifest, notes, values
history	Get release history
install	Install a chart
list	List releases
package	Pack the chart directory into a chart archive file
pull	Download the chart from the remote repository and extract it locally# helm pull stable/mysql --untar
repo	Add, list, remove, update and index chart repositories. Available subcommands: add, index, list, remove, update
rollback	Rollback from previous version
search	Search charts based on keywords. Available subcommands: hub, repo
show	View chart details. Available subcommands: all, chart, readme, values
status	Show the status of a named version
template	Local rendering template
uninstall	Uninstall a release
upgrade	Update a release
version	Check helm client version

3. Configure domestic Chart warehouse

The Microsoft warehouse ( Index of /kubernetes/charts/ ) is highly recommended. Basically, all the charts on the official website are available here.

Alibaba Cloud Warehouse ( https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts )

Official warehouse ( Kubeapps | Home ) The official chart warehouse is a bit difficult to use in China.

Add chart repository

[root@k8s-master ~]# helm repo add stable http://mirror.azure.cn/kubernetes/charts

[root@k8s-master ~]# helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

[root@k8s-master ~]# helm repo update

View the configured chart repository

[root@k8s-master ~]# helm repo list

Delete the repository:

[root@k8s-master ~]# helm repo remove aliyun

[root@k8s-master ~]# helm repo list

4. Use chart to deploy an Nginx application

1) Create chart

[root@k8s-master ~]# helm create nginx

[root@k8s-master ~]# tree nginx/

Detailed explanation:

nginx/

├── charts #depend on charts files from other packages

├── Chart.yaml #The description file of the chart, including IP address, version information, etc.

├── templates # Directory to store k8s template files

│ ├── deployment.yaml #Create a yaml template for k8s deployment resources

│ ├── _helpers.tpl #Files starting with an underscore can be referenced by other templates

│ ├── hpa.yaml #Configure service resources CPU memory

│ ├── ingress.yaml # Ingress configuration to access service domain name

│ ├── NOTES.txt #Description file, the content displayed to the user after helm install

│   ├── serviceaccount.yaml

│ ├── service.yaml #kubernetes Serivce yaml template

│   └── tests

│       └── test-connection.yaml

└── values.yaml #Variables used for template files

2) Modify the service type in values.yaml to NodePort

[root@k8s-master ~]# cd nginx/

[root@k8s-master nginx]# vim values.yaml

3) Install the chart task (note the last dot in the command)

[root@k8s-master nginx]# helm install -f values.yaml

4) View release

[root@k8s-master nginx]# helm ls #or helm list

5) Delete release

[root@k8s-master nginx]# helm delete nginx

6) Check pod status

[root@k8s-master nginx]# kubectl get pod

[root@k8s-master nginx]# kubectl get pod -o wide

7) Check svc status

[root@k8s-master nginx]# kubectl get svc

Visit 192.168.100.132:30281

5. Use chart to deploy a Tomcat application

[root@k8s-master ~]# helm create tomcat

Creating tomcat

[root@k8s-master ~]# cd tomcat/

Modify deployment.yaml and service.yaml files

[root@k8s-master tomcat]# vim templates/deployment.yaml

[root@k8s-master tomcat]# vim templates/service.yaml

Create release

[root@k8s-master tomcat]# helm install tomcat .

View release

[root@k8s-master tomcat]# helm ls

View pods and svc

[root@k8s-master tomcat]# kubectl get pod

[root@k8s-master tomcat]# kubectl get pod -o wide

[root@k8s-master tomcat]# kubectl get svc

Prepare test page

[root@k8s-master tomcat]# kubectl exec -it tomcat-67df6cd4d6-s7qxl /bin/bash

root@tomcat-67df6cd4d6-s7qxl:/usr/local/tomcat# mkdir webapps/ROOT

root@tomcat-67df6cd4d6-s7qxl:/usr/local/tomcat# echo "helm test1" > webapps/ROOT/index.jsp

[root@k8s-master tomcat]# kubectl exec -it tomcat-67df6cd4d6-tkp95 /bin/bash

root@tomcat-67df6cd4d6-tkp95:/usr/local/tomcat# mkdir webapps/ROOT

root@tomcat-67df6cd4d6-tkp95:/usr/local/tomcat# echo "helm test2" > webapps/ROOT/index.jsp

Access test:

Visit 192.168.100.132:32092

Visit 192.168.100.133:32092

delete

[root@k8s-master tomcat]# helm delete tomcat

[root@k8s-master tomcat]# helm ls

Upgrade (reapply after changing the yaml file)

[root@k8s-master tomcat]# helm install tomcat .

[root@k8s-master tomcat]# helm ls

[root@k8s-master tomcat]# kubectl get pod

[root@k8s-master tomcat]# vim templates/deployment.yaml

[root@k8s-master tomcat]# helm upgrade tomcat .

[root@k8s-master tomcat]# kubectl get pod

[root@k8s-master tomcat]# helm ls

rollback

[root@k8s-master tomcat]# helm rollback tomcat 1

[root@k8s-master tomcat]# helm ls

[root@k8s-master tomcat]# kubectl get pod

6. Render templates with variables

Test whether the template is normal

[root@k8s-master tomcat]# helm install --dry-run tomcat .

Define variables in values.yaml file

[root@k8s-master tomcat]# cat values.yaml

[root@k8s-master tomcat]# cat templates/deployment.yaml

[root@k8s-master tomcat]# cat templates/service.yaml

The variables in the deployment.yaml and service.yaml files are pre-defined and referenced values in values.yaml.

Release.Name represents the name after helm install

[root@k8s-master tomcat]# helm delete tomcat

Delete all redundant files in the templates directory, leaving only two test files.

[root@k8s-master tomcat]# ls templates/