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: