053. Cluster Management - Helm Deployment and Use

1. Overview of Helm

1.1 Introduction to Helm

Helm is a package management tool for Kubernetes.Package Manager, like apt in Ubuntu, yum in Centos, or pip in Python, can quickly find, download, and install packages.Typically, each package is called a Chart, and a Chart is a directory (typically, the directory is packaged and compressed to form a single file in the name-version.tgz format for easy transfer and storage).
Helm is composed of a client component, helm, and a server component, Tiller. The ability to package and manage a set of K8S resources is the best way to find, share, and use software built for Kubernetes.

1.2 Helm Advantage

Deploying a usable application in Kubernetes requires the collaboration of many Kubernetes resources.For example, installing a WordPress blog uses some of Kubernetes'resource objects.This includes Deployment for deploying applications, Service Provider Service Discovery, Secret for configuring WordPress usernames and passwords, and possibly pv and pvc for providing persistence services.WordPress data is stored in mariadb, so you need MariaDB to be ready to start WordPress.These k8s resources are too dispersed to be easily managed.
Deploying an application in k8s based on the scenario above usually has the following issues:
  • How to manage, configure and update these scattered k8s application resource files in a unified way;
  • How to distribute and reuse a set of application templates;
  • How to manage a range of resources that are applied as a package.
For application publishers, you can package applications through Helm, manage application dependencies, manage application versions, and publish applications to the software repository.
For users, instead of writing complex application deployment files after using Helm, you can simply find, install, upgrade, rollback, and uninstall applications on Kubernetes.

1.3 Helm-related components and concepts

Helm consists of two components, the helm client and the Tiller server:
  • helm: is a command-line tool for creating, packaging, publishing, and creating and managing local and remote Chart repositories for the Kubernetes application Chart.
  • Tiller: A server to Helm, deployed in the Kubernetes cluster.Tiller receives Helm's request, generates a deployment file (called Release) of Kubernetes from Chart, and submits it to Kubernetes to create the application.(v3 version removed)
  • Chart:Helm is packaged in a format called chart, which describes a set of related k8s cluster resources, including a set of YAML files that define the Kubernetes resource.
  • Release: Chart s deployed in the Kubernetes cluster using the helm install command are called Releases.
  • Repoistory: A repository of Helm chart s, Repository is essentially a Web server that stores a series of Chart packages for download by users and provides a manifest file for the Repository's Chart packages for query.Helm can manage multiple different Repositories at the same time.
Note: Release mentioned in Helm differs from the version in general concepts, and Helm's Release can be understood as an application instance deployed by Helm using a Chart package.

2. Helm Principle Mechanism

2.1 Helm Principle

The relationships between Helm's main components, Helm (client), Tiller (server), Repository (Chart software repository), Chart (software package), and how they communicate, are described in the following figure.
Helm architecture:

2.2 Main Helm Processes

Create release process:
  • The helm client parses the chart's structure information from a specified directory or local tar file or a remote repo repository;
  • The chart structure and values information specified by the helm client are passed to Tiller via gRPC;
  • The Tiller server generates a release based on chart s and values;
  • Tiller passes the install release request directly to kube-apiserver.
Delete release:
  • The helm client parses the chart's structure information from a specified directory or local tar file or a remote repo repository;
  • The chart structure and values information specified by the helm client are passed to Tiller via gRPC;
  • The Tiller server generates a release based on chart s and values;
  • Tiller passes the delete release request directly to kube-apiserver.
Update release
  • The helm client passes the release name, chart structure, and value information of the updated chart to Tiller;
  • Tiller generates a new release with the information it receives and updates the history of the release at the same time.
  • Tiller passes the new release to kube-apiserver for updates.

2.3 chart Basic Structure

Helm is packaged in a format called chart, which is a series of files that describe a set of related k8s cluster resources.The files in Chart install a specific directory structure organization, and the simplest chart directory is as follows:
Catalog Interpretation:
  • charts: This directory holds dependent chart s;
  • Chart.yaml: Contains basic information about Chart, including its version, name, etc.
  • Templates: This directory stores applications, which are yaml templates for a series of k8s resources;
  • _helpers.tpl: This file defines some reusable template fragments that are available in any resource definition template;
  • NOTES.txt: Describes help information after chart deployment, how to use chart, etc.
  • values.yaml: Contains the necessary value definitions (default values) to store the values of variables used in the template files in the templates directory.
Reference link: https://www.jianshu.com/p/4bd853a8068b.
Attachment: helm v3 Description:
Helm 2 is a C/S architecture, mainly divided into client-side helm and server-side Tiller; unlike v2, v3 removes Tiller, only helm.
Tiller is mainly used to manage versions of various application publications in the Kubernetes cluster. Tiller is removed in Helm 3 and version-related data is stored directly in Kubernetes.
1: Remove Tiller, for instructions on removing Tiller for v3 version, refer to: https://blog.csdn.net/zzh_gaoxingjiuhao/article/details/104182596.
2: Remove the advantages of Tiller can be referred to: https://www.sohu.com/a/364182362_609513.
Helm v3 new features reference: https://www.jianshu.com/p/dfb8e2a42db0, https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1.

3. Helm Deployment and Installation

3.1 Pre-preparation

Helm will use kubectl to deploy Kubernetes resources on the configured cluster, so the following preparations are required:
  • Running Kubernetes cluster;
  • Local Docker Client;
  • The preconfigured kubectl client interacts correctly with the Kubernetes cluster.

3.2 Install Helm

  • Binary Installation
  1 [root@master01 ~]# wget https://get.helm.sh/helm-v3.1.2-linux-amd64.tar.gz
  2 [root@master01 ~]# tar -zxvf helm-v3.1.2-linux-amd64.tar.gz 
  3 [root@master01 ~]# cp linux-amd64/helm /usr/local/bin/
  • Script Installation
  1 [root@master01 ~]# curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3
  2 [root@master01 ~]# chmod 700 get_helm.sh
  3 [root@master01 ~]# ./get_helm.sh
Tip: Refer to the official manual for more installation methods: https://helm.sh/docs/intro/install/.
  1 [root@master01 ~]# helm version		#View Installed Version
  2 [root@master01 ~]# echo 'source <(helm completion bash)' >> .bashrc	#helm AutoCompletion

IV Helm Operation

4.1 Find chart

helm search: can be used to search for two different types of sources.
helm search hub: Search Helm Hub, which contains Helm chart s from many different warehouses.
helm search repo: Search has been added to the warehouse of the local header helm client (with helm repo add) through local data and does not require a connection to the public network.
  1 [root@master01 helm]# helm search hub			#Searchable for all available chart s
  2 [root@master01 helm]# helm search hub wordpress

4.2 Add repo

  1 [root@master01 helm]# helm repo list			#View repo
  2 [root@master01 helm]# helm repo add brigade https://brigadecore.github.io/charts
  3 [root@master01 helm]# helm repo add stable https://kubernetes-charts.storage.googleapis.com/ #Add official repo
  4 [root@master01 helm]# helm repo add bitnami https://charts.bitnami.com/bitnami
  6 [root@master01 helm]# helm search repo brigade
  7 [root@master01 helm]# helm search repo stable		#Search for chart s in repo
  8 [root@master01 helm]# helm repo update			#Update the chart of repo
  9 [root@master01 helm]# helm repo remove stable		#Remove repo

4.3 Installation package

  1 [root@master01 helm]# helm search repo mariadb		#Find Confirmation Exists
  2 [root@master01 helm]# helm show chart bitnami/mariadb	#Can view related information in advance
  3 [root@master01 helm]# helm install xhy_mariadb bitnami/mariadb	#Install as chart in repo
  4 [root@master01 helm]# helm install xhy_mariadb2 bitnami.mariadb.tgz	#Install chart in Compressed Package
  5 [root@master01 helm]# helm install xhy_mariadb3 mariadb/		#Install in unzipped directory
  6 [root@master01 helm]# helm install xhy_mariadb4 https://hub.helm.sh/charts/bitnami/mariadb.tgz #Install in remote path
  7 [root@master01 helm]# helm ls				#View installed release
Tip: In Helm 3, you must actively specify the release name or add the--generate-name parameter to make the Helm auto-generated.
During installation, the helm client displays useful information about which resources were created, what publishing status was, and whether other configuration steps could or should be performed.
Note: Since many chart s require large mirrors and take some time to deploy properly to the cluster, Helm will not wait until all resources are running before exiting.

4.4 Status View

  1 [root@master01 ~]# helm status xhy-mariadb

4.5 Upgrade Rollback

You can use the helm upgrade command when you publish a new version of a chart or when you need to change the configuration of the publication.
  1 [root@master01 helm]# vi mariadb.yml			#Republish with new configuration
  2 rootUser:
  3   password: abcd1234
  4 [root@master01 helm]# helm upgrade -f mariadb.yml xhy-mariadb bitnami/mariadb	#upgrade
  5 [root@master01 helm]# helm get values xhy-mariadb		#View the new configuration
  1 [root@master01 helm]# helm history xhy-mariadb		#View installation history
  2 [root@master01 helm]# helm rollback xhy-mariadb 1		#RollBACK
Tip: The upgrade will take the existing distribution and upgrade it based on the information provided.Since Kubernetes chart s can be large and complex, Helm attempts to perform the least invasive upgrade.It will only update content that has changed since the last release.

4.6 Uninstall release

  1 [root@master01 helm]# helm uninstall xhy-mariadb		#Unload release
  2 [root@master01 helm]# helm list
Tip: In Helm 3, deleting releases also deletes publication records.If you want to keep deleted publication records, use helm uninstall --keep-history.Using helm list --uninstalled will only show the release uninstalled with the--keep-history flag.
Tip: The helm list--all flag queries all publishing records that Helm keeps, including records of failed or deleted items if --keep-history is specified.

4.7 Other common options

--timeout: The number of seconds to wait for the Kubernetes command to complete, defaulting to 5m0s.
--wait: Wait until all Pods are ready, PVC is bound, deployment has a minimum number of Pods available in ready state, and Services have an IP address (if Ingress LoadBalancer is installed) before the publication is marked as successful.It will wait until the value set by --timeout.If the timeout is reached, the release will be marked FAILED.
Note: With Deployment replicas set to 1, maxUnavailable, and not set to 0 as part of a rolling update strategy, --wait will return to its ready state as long as it meets the minimum Pod ready state.
--no-hooks: Skip the run hook on the command line.
--dry-run: Simulated installation.
-n, --namespace: Specify the namespace you want to deploy.
Tip: The hele full command option executes the helm <command> --help view.

5. Helm Custom Installation

5.1 View chart default value

Installation using the method shown in 4.3 above will only use the default configuration options for this chart.Typically, you need to customize the chart to use your preferred configuration.
  1 [root@master01 ~]# helm show values bitnami/mariadb	#View this chart for customizable configurations
  2 ......
  3 rootUser:
  4   ## MariaDB admin password
  5   ## ref: https://github.com/bitnami/bitnami-docker-mariadb#setting-the-root-password-on-first-run
  6   ##
  7   password: ""
  8 ......

5.2 Delivery Configuration

There are two ways to pass configuration data during installation:
--values (or -f): Specifies a YAML file with alternate parameters and values.It can be specified multiple times, with the last file having the highest priority.
--set: Specify a replacement on the command line.
Tip: If you use --set and -f at the same time, the -f priority will be higher.

5.3 Profile Definition Configuration Items

  1 [root@master01 helm]# vi mariadb.yml			#Create Custom Configuration
  2 rootUser:
  3   password: abcd1234
Tip: Set the database password above instead of using the default random password.

5.4 Command line definition configuration item

  1 [root@master01 helm]# helm install --set rootUser.password=abcd1234 xhy_mariadb bitnami/mariadb
Tip: More commands correspond to yaml as follows:
command line
--set name=value
name: value
--set a=b,c=d
a: b
c: d
--set outer.inner=value
inner: value
--set name={a, b, c}
- a
- b
- c
--set servers[0].port=80
- port: 80
--set servers[0].port=80,servers[0].host=example
- port: 80
host: example
--set name=value1\,value2
name: "value1,value2"
--set nodeSelector."kubernetes\.io/role"=master
kubernetes.io/role: master

6. Create a chart

6.1 Create chart command

  1 [root@master01 helm]# helm create test-chart
Tip: Create creates a standard chart directory structure where you can edit the configuration to create your own chart.More chart development guides are available at https://helm.sh/docs/topics/charts/.
Reference for chart fields and writing: https://www.kubernetes.org.cn/3884.html.
  1 [root@master01 helm]# helm lint test-chart/		#Verify that it works after creation
  2 [root@master01 helm]# helm package test-chart		#Package the creation
  3 [root@master01 helm]# helm install test-chart/ ./test-chart/-0.1.0.tgz	#install

7. Monocular

7.1 Introduction to Monocular

Monocular is an open source software that manages services created as Helm Charts on kubernetes based on a web UI graphical interface

7.2 Monocular Installation

  1 [root@master01 ~]# helm repo add monocular https://helm.github.io/monocular #Add repo
  2 [root@master01 ~]# kubectl create ns helm
  3 [root@master01 ~]# cat > custom-repos.yaml <<EOF
  4 sync:
  5   repos:
  6     - name: stable
  7       url: https://kubernetes-charts.storage.googleapis.com
  8       schedule: "0 * * * *"
  9       successfulJobsHistoryLimit: 1
 10     - name: incubator
 11       url: https://kubernetes-charts-incubator.storage.googleapis.com
 12       schedule: "*/5 * * * *"
 13     - name: monocular
 14       url: https://helm.github.io/monocular
 15 ui:
 16   replicaCount: 2
 17   service:
 18     name: monocular-ui
 19     type: NodePort
 20     externalPort: 80
 21     internalPort: 8080
 22     annotations: {}
 23       # foo.io/bar: "true"
 24 ingress:
 25   hosts:
 26   - monocular.odocker.com
 27 EOF			#Add custom configuration: Configure repo and ingress host added by default
 28 [root@master01 ~]# helm install mymonocular monocular/monocular -f custom-repos.yaml -n helm

7.3 Confirm installation

  1 [root@master01 ~]# kubectl get pods -n helm -o wide
  2 [root@master01 ~]# kubectl get svc -n helm -o wide
  3 [root@master01 ~]# kubectl get ingresses -n helm -o wide
Reference: https://github.com/helm/monocular

8. helm Deploy WordPress

8.1 View the chart package

  1 [root@master01 ~]# helm repo add bitnami https://charts.bitnami.com/bitnami
  2 [root@master01 ~]# helm search repo wordpress
  4 bitnami/wordpress       9.2.4           5.4.1           Web publishing platform for building blogs and ...

8.2 Install WordPress

  1 [root@master01 ~]# kubectl create ns wp
  2 [root@master01 ~]# vi custom-wordpress.yaml
  3 wordpressUsername: admin
  4 wordpressPassword: admin12345
  5 wordpressBlogName: Xhy Blog!
  6 persistence:
  7   enabled: true
  8   storageClass: "ghsc"
  9   accessMode: ReadWriteOnce
 10   size: 5Gi
 13 mariadb:
 14   db:
 15     name: wpdb
 16     user: wpuser
 17     password: wppass12345
 18     rootUser: wpadmin
 19     password: wpadminpass12345
 22   master:
 23     persistence:
 24       enabled: true
 25       storageClass: "ghsc"
 26       accessModes:
 27         - ReadWriteOnce
 28       size: 5Gi
 31 service:
 32   type: NodePort
 33   nodePorts:
 34     http: "30005"
 35     https: "30006"
Default reference configuration reference: https://github.com/bitnami/charts/blob/master/bitnami/wordpress/values.yaml
Reference for more parameter settings: https://github.com/bitnami/charts/tree/master/bitnami/wordpress
  1 [root@master01 ~]# helm install mywp bitnami/wordpress -f custom-wordpress.yaml -n wp

8.3 Confirm installation

  1 [root@master02 ~]# kubectl get pods -n wp -o wide
  2 [root@master02 ~]# kubectl get pv -n wp -o wide | grep wp
  3 [root@master02 ~]# kubectl get pvc -n wp -o wide          
  4 [root@master02 ~]# kubectl get svc -n wp -o wide 

8.4 Access testing

  1 [root@master01 ~]# kubectl get --namespace wp -o jsonpath="{.spec.ports[0].nodePort}" services mywp-wordpress		#View Port
  2 30005
  3 [root@master01 ~]# kubectl get nodes --namespace wp -o jsonpath="{.items[0].status.addresses[0].address}"	#View node ip
Browser access: or
Browser access:, enter the management interface.

Reference documents:

Tags: Linux Kubernetes MariaDB github

Posted on Tue, 12 May 2020 00:46:24 -0700 by kettle_drum