Helm Getting Started Guide

Helm charts

Helm for Kubernetes software package management tool, Helm has two parts: Helm client, tiller Server, helm chart tutorial Helm three main components: Chart, Warehouse, Release;

Jenkins helm chart

Chart: The definition of the resource required for the application in Kubernetes.
warehouses: warehouses for storing helm chart, which can be downloaded from the warehouse directly using the chart
Release: A chart instance running in Kubernetes, each chart can be installed multiple times, each installation is a new version,ed helms;

Helm Common directives:

Helm search find chart in warehouse,levon helm

Helm Inspect Stable/mongodb can view the chart's introductory information;
Helm install Stable/mongodb can download the chart directly and install the chart;heather helm

Grafana helm chart

Prometheus helm chart

Version Upgrade:
Helm upgrade Releasename.

Gitlab helm chart

Helm rollback Releasename 1 rollback to version 1

To publish the Kubernetes project from scratch via helm:max helm

First, the structure of the introduction

Initialize the project:anne helm

helm create nginx

After execution, create a chart named Nginx, and now look at the files in the Nginx directory:tommy helm

Charts: The directory is used to store dependent child chart
Chart.yaml: The document for the current chart, which can also be accessed in the template;
templates: The catalog is a template directory of Nginx projects, usually populated with Values.yaml configuration content, and the Board engine renders the files for this directory tiller submits the rendered results to the Kubernetes object that created the response;
Values.yaml: As a value file, define the values that need to be used in the template, and access the changes in the templates template file;

In the templates directory, you can see Deployment.yaml, Ingress.yaml, service.yaml files that define Kubernetes deployment, ingress, service object template files;
NOTES.txt: documentation for the successful installation of the chart
**_helpers.tpl:** template helper file, defined values can be used in the template;

Ii. deploying Nginx in Kubernetes through Helm

1, Helm preliminary use

Now delete all the files in the template directory, empty all the contents of the Values.yaml file

The deployment of NGINX requires a deployment controller and external services, and now we manually create this two files and write the relevant content;

Deployment.yaml:

apiVersion: apps/v1 kind: Deployment metadata:   name: nginx-deployment   labels:     app: nginx spec:   replicas: 3   selector:     matchLabels:       app: nginx   template:     metadata:       labels:         app: nginx     spec:       containers:       - name: nginx         image: nginx:1.7.9         ports:         - containerPort: 80

Service.yaml

apiVersion: v1 kind: Service metadata:  name: nginx-service spec:  selector:    app: nginx  type: NodePort  ports:  - port: 80    nodePort: 30078

At this time we in the Superior directory execution: Helm install Nginx can be deployed to the kubernetes;

But if you use helm in this way, then it doesn't make much sense, since the template directory is the template directory, of course, it can not just use templates, template files to reflect the nature of its model, the following we will use Helm template and other functions, Let the template file reflect the nature of his template;

2. Helm Template
So far Deployment.yaml and Service.yaml although is placed in the template directory but does not reflect the nature of his template, and now we start the template of these two files;

Template Syntax Basics:

Built-in objects: Helm has such a common built-in object: Release, Values, Chart, Files, capabilities, Template;

Release: This object describes the current release, built-in: Release.name release name, Release.time release time and so on opposite;
values: This object is a pair of value objects passed to the template from the Values.yaml file with the user-supplied file;
Chart: This object is the data object provided by the Chart.yaml file;
Files: provides access to the chart's non-special files;
Capabilities: This provides access to the Kubernetes cluster information;
Template : Current profile information being executed

Below we use Helm built-in object values to achieve Deployment.yaml, Service.yaml file templating, Values object value range:
1, the current chart of the Values.yaml file;
2, if the current is a child chart, then from the parent chart Values.yaml file;
3, in Helm install or helm update execution is passed through the-f parameter of the file;
4, through the helm install through the –set set value;

If the Replicacount:1 object exists in the Values.yaml file, the template file is passed {{. Values.replicacount}} to access the object value defined by the Values.yaml file 1;

You can define a naming template by **_helpers.tpl**, and define a template below Deploy.name

{{- define "deploy.name" -}} demo-deploy-nginx {{- end }}

Where: {{-means delete the left space-}} Remove the space on the right
The named template can be referenced in the template file by {{Template ' Deploy.name '}}.

To implement templating:

Extract the data that needs to be templated, extract the name of the deployment object, labels, replicas, matchlabels, template labels, template spec name, image The service object's name, selector labels, type, port, Nodeport, and so on;
We then select from the extracted configuration name class and labels class configuration defined as named template in the _helpers.tpl file, the other configuration items are defined in the Values.yaml file;

The contents of the **_helpers.tpl** file are as follows: storage of deploy name, service name, deploy Lables, lables of pod in deploy;

{{- define "deploy.name" -}} demo-deploy-nginx{{- end }}{{- define "service.name" -}}demo-service-nginx{{- end }}{{- define "labels" -}}demo: nginx{{- end}}{{- define "deploy.labels" -}}deploy: nginx{{- end}}

Values.yaml file that defines the number of replicas, mirror name and version, service type, port, and so on:

# 定义模板默认值replicaCount: 1image:  repository: nginx  tag: 1.7.9service:  type: NodePort  port: 80  nodePort: 30078

The value file is defined at this point, you need to refer to the values defined by the above two files in the template deployment, service file, and then start refactoring the Deployment.yaml and Service.yaml files:

Service.yaml file:

apiVersion: v1kind: Servicemetadata:  name: {{ template "service.name" . }}spec:  selector:  {{ template "labels" . }} type: {{ .Values.service.type }} ports:  - port: {{ .Values.service.port }}   nodePort: {{ .Values.service.nodePort }}

Deployment.yaml

apiVersion: apps/v1kind: Deploymentmetadata:   name: {{ template "deploy.name" . }}  labels:     {{ template "deploy.labels" .}}spec:  replicas: {{ .Values.replicaCount }}  selector:   matchLabels:      {{ template "labels" . }} template:     metadata:      labels:        {{ template "labels" . }}    spec:      containers:      - name: {{ .Chart.Name}}        image: {{ .Values.image.repository }}:{{ .Values.image.tag }}        ports:        - containerPort: 80

After the template file is written, you can re-use the helm install to deploy Nginx test, execute the helm delete running-chipmunk before uninstalling the installation;

Reference: https://docs.helm.sh/

Article starting address: Solinx
http://www.solinx.co/archives/1247

Helm Getting Started Guide