[Cloud native] k8s package manager Helm

foreword

 Every successful software platform has an excellent packaging system, such as Debian, Ubuntu's apt, RedHat, CentOS's yum. Helm is the package manager on Kubernetes, which is convenient for us to better manage applications.

1. Knowledge about  Helm

1.1 Introduction and Understanding of Helm 

 The essence of Helm is to make K8s application management (Deployment, Service, etc.) configurable and dynamically generated in a way similar to passing environment variables. By dynamically generating K8s resource list files (deployment.yaml, service.yaml). Then call Kubectl to automatically execute K8s resource deployment.

Before using helm, to deploy applications to kubernetes, we need to deploy deployment, svc, etc. in turn, and the steps are cumbersome. Moreover, with the micro-service of many projects, the deployment and management of complex applications in containers is more complicated. Helm supports release version management and control through packaging, which greatly simplifies the deployment and management of Kubernetes applications.
 Helm is an official package manager similar to YUM, which is a process encapsulation of the deployment environment.

Helm's official website address: http://https://helm.sh/

1.2 Three important concepts of Helm

There are three important concepts in Helm, namely: Chart, Repository and Release 

●Chart : Helm's software package in TAR format. It is a collection of information for creating an application, including configuration templates, parameter definitions, dependencies, documentation, etc. of various Kubernetes objects. A chart is a self-contained logical unit of application deployment. Chart can be imagined as a software installation package in apt and yum.

●Release : It is a running instance of chart, representing a running application. When the chart is installed in the Kubernetes cluster, a release is generated. A chart can be installed to the same cluster multiple times, and each installation is a release.

●Repository (warehouse) : Charts warehouse for centralized storage and distribution of Charts. Repository is essentially a Web server, which saves a series of Chart packages for users to download, and provides a list file of the Repository's Chart packages for query. Helm can manage multiple different Repositories at the same time.

There is also a concept that was removed in the Helm3 version:

Tiller: In Helm 2.x version, Helm adopts the client/server design. Tiller is the server part of Helm. It needs to have cluster administrator privileges to be installed and run in the K8s cluster. Tiller interacts with the Helm client, receives the client's request, communicates with the K8s API Server, and generates a Release based on the passed Charts. In the latest Helm 3.x, Tiller is said to be removed for security reasons. 

In the application of Helm in k8s cluster, generally speaking, its function process: Helm installs charts into the Kubernetes cluster, and each installation will create a new release. You can find new charts in Helm's chart repositories. 
 

 

2. Deployment of Helm in k8s cluster

(1) Install Helm on the master01 node 

//Download the required version of the binary Helm client installation package in github
https://github.com/helm/helm/tags 
 
tar -zxvf helm-v3.6.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm helm
version
 

 Add helm's auto-completion function for subsequent use:

vim /etc/bashrc
source <(helm completion bash)

(2) Install Chart using helm 

###Helm add chat grammar format:
helm repo add chart warehouse name chart warehouse address
 
###Add commonly used chart warehouse ############
#An open source project warehouse
helm repo add bitnami https://charts.bitnami.com/bitnami
#Microsoft chart warehouse, recommended, the content is basically consistent with the official warehouse
helm repo add stable http://mirror.azure.cn/kubernetes/ charts
#阿里chart warehouse, everything you need
helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
#Official warehouse, domestic network problems, it is not recommended to use
helm repo add incubator https://charts.helm.sh/incubator

 

(3) Basic use of the chart warehouse 

1) Update and view the charts list

helm repo update          
helm repo list
 

 

2) View the list of available charts in a chart warehouse 

//View the list of charts available in the stable warehouse
helm search repo stable
 

 3) Delete the specified chart warehouse

//eg: Because the official warehouse is too slow to use, delete the incubator warehouse
helm repo remove incubator
 

 

 4) View chart information

 
helm show chart stable/mysql #View the basic information of the specified chart

helm show all stable/mysql #Get all the information of the specified chart

(4) Install the chart 

helm install my-redis bitnami/redis [-n default] #Specify the name of the release as my-redis, -n specifies the namespace deployed to k8s helm
 
install bitnami/redis --generate-name #When you do not specify the name of the release, you need to use –generate-name to randomly generate a name

 

(5) Basic management of chart

 1) View all releases

helm ls 
helm list

 

2) View the specified release status

helm status my-redis 

 

 3) Delete the specified release

helm uninstall my-redis 
 

  3. Helm's custom template

 In addition to being downloaded in the repo, charts can also be customized. After creation, they can be deployed to k8s through helm.

3.1 Pull the chart in the mirror warehouse and view the package structure of the chart

#Pull the chart to the local directory (in the current directory)
helm pull stable/mysql
 
#Decompress the pulled chart package
tar xf mysql-1.6.9.tgz

 

 

 It can be seen from the figure above that a chart package is a collection of folders, and the folder name is the name of the chart package.

 chart is a helm package that contains at least two things:

(1) The package self-describing file Chart.yaml, this file must have the definition of name and version (chart version)
(2) One or more templates, which contain the Kubernetes manifest file:

NOTES.txt: the "help text" of the chart, displayed to the user when the user runs helm install
deployment.yaml: create the resource manifest file of the deployment
service.yaml: create the resource manifest file of the service for the deployment
ingress.yaml: create the resource manifest file of the ingress object
_helpers.tpl: place the template helper, which can be reused throughout the chart
 

3.2 Create a custom chart 

(1) Create a template using the command line

helm create nginx
 
tree nginx

 

cat nginx/templates/deployment.yaml

 

 The value of the variable (go template syntax) in the yaml file template in the templates directory is defined in nginx/values.yaml by default. You only need to modify the content of nginx/values.yaml to complete the configuration of the yaml file in the templates directory.
For example, the container image defined in deployment.yaml:
image: "{ { .Values.image.repository }}:{ { .Values.image.tag | default .Chart.AppVersion }}"
 

Summary: So in actual operation, in most cases, we only need to set the custom chart by manipulating the Chart.yaml and values.yaml files, and the other files are obtained by variables to obtain the values ​​in values.yaml 

(2) Modify the template file to generate a custom chart 

vim nginx/Chart.yaml
apiVersion: v2
name: nginx #chart name
description: A Helm chart for Kubernetes
type: application #chart type, application or library
version: 0.1.0 #chart version
appVersion: 1.16.0 #application deployment version

 vim nginx/values.yaml
replicaCount: 1
 
image:
  repository: nginx
  pullPolicy: IfNotPresent
  tag: "latest"                 #设置镜像标签
 
imagePullSecrets: []
nameOverride: ""
fullnameOverride: ""
 
serviceAccount:
  create: true
  annotations: {}
  name: ""
 
podAnnotations: {}
 
podSecurityContext: {}
  # fsGroup: 2000
 
securityContext: {}
  # capabilities:
  #   drop:
  #   - ALL
  # readOnlyRootFilesystem: true
  # runAsNonRoot: true
  # runAsUser: 1000
 
service:
  type: ClusterIP
  port: 80
 
ingress:
  enabled: true #Open ingress
  className: ""
  annotations: {}
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: www.test.com #Specify ingress domain name
      paths:
        - path: /
          pathType: Prefix #Specify ingress path type
  tls: []
  # - secretName: chart -example-tls
  # hosts:
  # - chart-example.local
 
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi
 
autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80
 
nodeSelector: {}
 
tolerations: []
 
affinity: {}

(3) Carry out chart packaging 

//Package chart
helm lint nginx #Check whether the dependencies and template configuration are correct
 
helm package nginx #Package chart, a compressed package nginx-0.1.0.tgz will be generated in the current directory

 

(4) Use the custom chart package for k8s resource deployment 

helm install nginx ./nginx --dry-run --debug #Use the --dry-run parameter to verify the configuration of Chart, and do not install
 
helm install nginx ./nginx -n default #Deploy chart, the release version defaults to 1
or
helm install nginx ./nginx-0.1.0.tgz
 
#Can be installed according to different configurations, the default is values.yaml
he lm install nginx ./nginx -f ./nginx/values-prod.yaml

(5) Deploy  ingress

wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/mandatory.yaml
wget https://gitee.com/mirrors/ingress-nginx/raw/nginx-0.30.0/deploy/static/provider/baremetal/service-nodeport.yaml
kubectl apply -f mandatory.yaml
kubectl apply -f service-nodeport.yaml

kubectl get pod,svc -n ingress-nginx
kubectl get ingress

 

 Perform client test: (just enable a client other than the k8s cluster )

vim /etc/hosts
192.168.73.107 www.test.com 

(6) Make modifications and changes, and upgrade and update the chart 

//修改为 NodePort 访问后，升级
vim nginx/values.yaml
service:
  type: NodePort
  port: 80
  nodePort: 30080
 
ingress:
  enabled: false
 
vim nginx/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: { { include "nginx.fullname" . }}
  labels:
    { {- include "nginx.labels" . | nindent 4 }}
spec:
  type: { { .Values.service.type }}
  ports:
    - port: { { .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
      nodePort: { { .Values.service.nodePort }}              #指定 nodePort
  selector:
    { {- include "nginx.selectorLabels" . | nindent 4 }}

 

 

 
Upgrade release, release version plus 1
helm upgrade nginx nginx 

 

 

Conduct an access test:

 

 (7) Roll back the version of the custom chart (according to the release version)

helm history nginx #View release version history
 
helm rollback nginx 1 #Rollback release to version 1
 
#Usually, after configuring the kubernetes manifest file in the templates directory, subsequent maintenance generally only needs to modify Chart.yaml and values.yaml.

 Use --set to specify parameters on the command line to deploy (install, upgrade) release
#Note: The value of this parameter will overwrite the value in values.yaml. For other predefined variable parameters, please refer to the official helm documentation.
helm upgrade nginx nginx --set image.tag='1.15' (equivalent to the way of patching settings in k8s)

4. Helm's private warehouse-Habor
 

 As mentioned above, Habor is used as a private warehouse for docker images. In fact, Habor can also become a private warehouse for Helm, which is used to store packaged chart packages.

Specific deployment steps

(1) Install habor and docker-compose on the new host (provided that docker has been installed) 

//Install harbor
#Upload harbor-offline-installer-v1.9.1.tgz and docker-compose files to /opt directory
cd /opt
cp docker-compose /usr/local/bin/
chmod +x /usr/local/bin/docker-compose
 
tar zxf harbor-offline-installer-v1.9.1.tgz
cd harbor/

 

vim harbor.yml
hostname: 192.168.73.108
harbor_admin_password: Harbor12345 #admin user initial password
data_volume: /data #Data storage path, automatically create
chart:
  absolute_url: enabled #Enable absolute url in chart log
:
  level: info
  local:
    rotate_count: 50
    rotate_s ize: 200M
    location: /var/log/harbor #Log Path
 
#Install Harbor with Clair service and chart warehouse service
./install.sh --with-clair --with-chartmuseum

(2) Install the push plugin on the helm host 

#Online installation
helm plugin install https://github.com/chartmuseum/helm-push
 
#Offline installation
wget https://github.com/chartmuseum/helm-push/releases/download/v0.8.1/helm-push_0.8.1_linux_amd64.tar.gz
 
mkdir -p ~/.local/share/helm/plugins/helm- push
tar -zxvf helm-push_0.8.1_linux_amd64.tar.gz -C ~/.local/share/helm/plugins/helm-push
 
helm repo ls

(3) Create a project on the habor host, and add a chart warehouse to the helm host 

Open the browser: visit http://192.168.73.108, create a new project 

 

 

Operate on the helm host:

#Add warehouse
helm repo add harbor http://192.168.73.108/chartrepo/chart_repo --username=admin --password=Harbor12345
#Note: The address of the repo here is <Harbor URL>/chartrepo/<project name>, and each project in Harbor is a separate repo. If no project name is provided, the library project is used by default.
 

 

(4) Push and pull test 

Push chart package test:

#Push chart to harbor
cd /opt/helm
helm push nginx-0.1.0.tgz harbor
 

 

Pull chart package test: 

Note: When pulling the private warehouse chart package for the first time, you need to perform helm repo update first to update the helm warehouse source

rm -f nginx-0.1.0.tgz
mkdir repo.bak
mv nginx/ ./repo.bak
 
#Because the harbor warehouse is used for the first time, the warehouse source needs to be updated first
helm repo update
helm pull harbor/nginx

 

 

 Summary of Helm commands

(1) Summary of Helm's common commands

 
helm #View helm basic operation commands
helm version #View helm version
helm env #View environment variables
helm create chartName #Create a chart directory (including basic configuration files and directories) helm
package chartDir #Pack the chart directory
helm template chartName #Render template files in the template directory (that is, fill the fields of these template files with values.yaml, and then output them directly to the terminal) helm search repo keyword # Retrieve the chart package helm search hub keyword according to the keyword #The above two commands are only different in the third field, repo means to search in the warehouse added locally; hub means to search in the Helm
 
Hub . helm list #View the release corresponding to the chart published to k8s helm push chart.tgz repoName Upload the chart to the chart warehouse Example: helm push demo.tgz harbor-10.30.12.211 --username=admin --password=Harbor12345 #Some warehouses have account and password authentication, so you need to add account and password parameters (such as the chart warehouse function provided by Harbor , you can refer to the following private warehouse construction to build a private warehouse first, and then test the warehouse-related commands)


 

 



 
[The relationship between chart and release can be roughly understood as the relationship between program and process, one is static and the other is dynamic] helm install chartName --generate-name #You can not specify the name of the release, you only need to specify –generate-name to generate a name randomly #After creation, you can use helm list to check whether there is a corresponding release helm uninstall releaseName #Uninstall the release deployed to k8s


 


 





 


 
#After uninstalling, use helm list to check whether relDemo has been deleted. At the same time, you can use kubectl get pods to check whether the corresponding pods and other release-related resources have been deleted. Replace deployment release
. As far as helm is concerned, the release is still the original one, but the corresponding chart package has been replaced. For k8s, it is just to delete the original resource, and then create the resource with the new chart package.
#Use helm list to check whether the CHART field of the release is updated, and at the same time, use kubectl get pods to check whether the corresponding pod and other resources related to the release have been updated (see name, running time) helm rollback releaseName revision #Revert the release to the previous version or several versions (k8s will be rolled back synchronously) #revision is the number of versions, 1 means the first version, 2 means the second version, and so
 
on
. Usually rollback will be used with helm history releaseName. Use this command to view all the release history of this release, and then choose which version to roll back to #After the rollback is
successful, use the helm list to check whether the CHART and APP VERSION of the release are updated (specifically, it depends on whether the version and appVersion in chart.yaml in the chart have been modified accordingly). Look at the name, running time)
 
helm history releaseName #View the release history of the release (including installation, upgrade, rollback)
helm status releaseName #View the basic information of the release

(2) View the operation commands of the chart package

helm show chart chartName #View the content of the chart.yaml file in the chart package #The chart package can be a local unpackaged chart directory (
that is, the chart directory created by helm create), or a packaged chart compressed package (packaged by helm package), or a chart package stored in the warehouse. show readme chartName #View the content of the README file in the chart package# There are 3 options in the same package
 


 


 

(3) View the release specified content (same function and format as helm show)

 
helm get notes releaseName #View the description information of the release (equivalent to NOTES.TXT in the chart)
helm get manifest releaseName #View the resources created by the release in k8s
helm get hooks releaseName #View the callback of the release to create resources
helm get values ​​releaseName #View the values ​​configuration of the release
helm get all releaseName #View all the above

(4) helm plugin - plugin management

 

 
helm plugin list #View locally installed plugins (plugin management)
 
helm plugin install pluginURL #Install plugins
Example: helm plugin install https://github.com/chartmuseum/helm-push
#The final url address is the download address of the plugin, please refer to https://github.com/chartmuseum/helm-push
 
helm plugin uninstall pluginName #Uninstall plugin
helm plugin up date pluginName #Update the plugin, upgrade the plugin to the latest version
# When downloading the plugin, the plugin and its download address will be saved. When updating, use the original download address to directly download the latest version instead

(5) helm repo - warehouse management

At this time, if the chart is uploaded to the warehouse, the local need to execute the HELM repo update to update the local caching data to retrieve the specified Chart, because Helm Search is the helm repox rephr = repourted warehouse directory according to the specified warehouse directory. CHART Pack to generate index.yaml index file example: helm repo index repo -url = http: //192.168.73.108: 8080 /
 



 

 


 


#repoDir specifies a warehouse directory, which is used to store chart packages and index files index.yaml. url specifies the access path of the warehouse, and the generated index file will use the url as the address prefix to splice the chart package name as the access path of the chart package