helm introduction

Helm is a package management tool of kubernetes, just like the package manager under Linux, such as yum/apt, which can easily deploy the previously packaged yaml file to kubernetes.

Helm has three important concepts:

• helm: a command-line client tool, which is mainly used for the creation, packaging, publishing and management of Kubernetes application chart.
• Chart: application description, a collection of files used to describe k8 resources.
• Release: the deployment entity based on chart. After a chart is run by Helm, a corresponding release will be generated; A real running resource object will be created in k8s.

helm v3

• Instead of using tiller, use kubeconfig to connect to kubernets cluster
• The Release name can be reused in different namespaces
• It supports pushing Chart to Docker image warehouse
• ...

Deploy helm

cd /tmp
wget https://get.helm.sh/helm-v3.5.2-linux-amd64.tar.gz
tar -zxvf helm-v3.5.2-linux-amd64.tar.gz 
mv linux-amd64/helm /usr/bin/helm
chmod 700 /usr/bin/helm

Common instructions

Warehouse management

# Add helm warehouse bitnami to local
helm repo add bitnami	https://charts.bitnami.com/bitnami --username ${username} --password ${password}

#List local warehouses
helm repo list

#Delete local warehouse
helm repo remove bitnami

Search warehouse

# Search the helm keyword in the public warehouse of the public network
helm search hub helm

# Search helm in local warehouse
helm search repo helm

Download applications in the warehouse

# Download the application common in bitnami warehouse, version 1.3.9
helm pull bitnami/common --version 1.3.9

#Do not specify the default latest version
helm pull bitnami/common

Create a new app

helm create foo

    foo/
    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
    ├── Chart.yaml    # Information about your chart
    ├── values.yaml   # The default values for your templates
    ├── charts/       # Charts that this chart depends on
    └── templates/    # The template files
        └── tests/    # The test files

Check application syntax

helm lint foo

1 chart(s) linted, 0 chart(s) failed

Rendering application

helm template foo

Simulated release

helm install --dry-run --debug --namespace  ${namespace}  release-name  foo

#--Dry run simulation installation
#--debug print debugging information

Release release

helm install --debug --namespace  ${namespace}  release-name  foo

Update release

 helm upgrade --debug  --install  --namespace ${namespace} -f values.yaml release-name foo

#The app named release name does not exist. A new release name app will be created

#--Dry run also applies

Uninstall release

# Uninstall without deleting
helm uninstall   --debug  ${chartname}  --namespace ${namespace}

# Uninstall and delete
helm uninstall  --purge  --debug  ${chartname}  --namespace ${namespace}

Upload application to warehouse (harbor, nexus, etc.)

# Install the upload plug-in first
helm plugin install https://github.com/chartmuseum/helm-push
helm push foo repo-name

Query the release history of released releases

helm history -n ${namespace} release-name

REVISION    UPDATED                     STATUS          CHART             APP VERSION     DESCRIPTION
1           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Initial install
2           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Upgraded successfully
3           Mon Oct 3 10:15:13 2016     superseded      alpine-0.1.0      1.0             Rolled back to 2
4           Mon Oct 3 10:15:13 2016     deployed        alpine-0.1.0      1.0             Upgraded successfully

Rollback release

#Query the historical version of release [REVISION]
helm history -n ${namespace} release-name

# RollBACK 
helm rollback -n ${namespace} release-name [REVISION] [flags]

Flags:
      --cleanup-on-fail    allow deletion of new resources created in this rollback when rollback fails
      --dry-run            simulate a rollback
      --force              force resource update through delete/recreate if needed
  -h, --help               help for rollback
      --history-max int    limit the maximum number of revisions saved per release. Use 0 for no limit (default 10)
      --no-hooks           prevent hooks from running during rollback
      --recreate-pods      performs pods restart for the resource if applicable
      --timeout duration   time to wait for any individual Kubernetes operation (like Jobs for hooks) (default 5m0s)
      --wait               if set, will wait until all Pods, PVCs, Services, and minimum number of Pods of a Deployment, StatefulSet, or ReplicaSet are in a ready state before marking the release as successful. It will wait for as long as --timeout
      --wait-for-jobs      if set and --wait enabled, will wait until all Jobs have been completed before marking the release as successful. It will wait for as long as --timeout

helm's general play

Create a new app

helm create foo

    foo/
    ├── .helmignore   # Contains patterns to ignore when packaging Helm charts.
    ├── Chart.yaml    # Information about your chart
    ├── values.yaml   # The default values for your templates
    ├── charts/       # Charts that this chart depends on
    └── templates/    # The template files
        └── tests/    # The test files

According to the above directory structure, it is generally in values Define the key information of an application in yaml, such as:

• Mirror information
• service port information
• ingress
• storage
• ...

After definition, you need to describe the version information of the current application. A version is a release, and the release information will be displayed in chart Yaml describes the following as necessary:

• apiVersion: v2 # helm api version, no modification required
• appVersion: v20200706-1044 # the version of the current application. I usually use the mirrored tag directly
• Description: # application description
• Name: common service # application description
• version: 1.0.0 # current release version

The specific layout files of the application will be placed in templates, such as the layout files of deployment, service, configmap, pv, ingress and other resources. The layout files under templates, as described in the directory, are all templates. They are the layout logic of resources, not specific layout files. When deploying the release, it will follow the values According to the key information in yaml, render the specific layout file and install it into the cluster.

In the process of practical application, a general chart will be generated (there are some good general schemes on the Internet that can be applied), and then a specific application will be generated using jenkins or shell (automatic or manual). Of course, during the generation process, you may need to pass in some parameters. For example: