Series of articles:

Container & Service: Helm Charts (I)

Container & Service: Helm Charts (II) installation and use

Container & Service: Helm Charts (III) K8s cluster information

I. Introduction

chart is Helm's application packaging format. chart consists of a series of files that describe the resources required for K8s to deploy applications, such as Service, Deployment, PersistentVolumeClaim, Secret, ConfigMap, etc.

chart can be complex or simple, that is, it can only be used to deploy a single service, such as mysql, nginx, etc., or it can be used to deploy the whole application, such as complex applications composed of HTTP services, databases, caches, middleware, etc.

In our application, the entire directory of chart is usually compressed (tgz or tar, etc.) with version and other information for Helm deployment.

Second chart example

As follows, test-0.1-1862.tgz is an output compressed packet of chart:

We unzipped the file. The contents of the obtained directory are shown in the following figure:

It contains configmap, deployment, service, chart and values.yaml configurations. It includes the dependent services, the required variables, and the deployment and service related configurations.

A more complete directory consists of the following:

• Chart.yaml: including warehouse address, version information, etc., describing the summary information of chart;

• values.yaml: chart supports customized configuration according to parameters during installation, while values.yaml provides the default values of these configuration parameters;

• values.schema.json validate values.yaml

• charts: charts files that depend on other packages

• requirements.yaml: dependent charts(v1 api)

• requirements.lock v1 api specific dependent version

• README.md: files read by developers themselves

• LICENSE: copyright document

• crd directory to store crd resource files

Templates directory the configuration templates of various Kubernetes resources are placed here. Helm will inject the parameter values in values.yaml into the template to generate a standard YAML configuration file.

Template is the most important part of chart and the most powerful part of Helm. The template increases the flexibility of application deployment and can be applied to different environments

– deployment.yaml create a yaml file for k8s resources

Another example is the chart directory structure of mysql:

III. file content analysis

From the above two examples, it can be seen that there are five important files in the Chart file: Chart.yaml, values.yaml, and configmap.yaml, deployment.yaml, and service.yaml under templates. Next, we analyze these five files in detail.

3.1 Chart.yaml

Content and rules:

apiVersion: # K8s API version, currently using "v1" (required)
name: # Package name of the project (required)
version: # Chart version number, which shall comply with SemVer 2: http://semver.org/ (semantic version specification) (required)
kubeVersion: # A range of compatible Kubernetes versions (optional)
description: # Chart description, which usually describes the project in one sentence (optional)
keywords:
  - # A list of keywords for this item for easy retrieval (optional)
home: # Project home page URL (optional)
sources:
  - # A list of URL s pointing to the source code of this project (optional)
maintainers: # Maintenance personnel information (optional)
  - name: # Name of maintainer (each maintainer must fill in)
    email: # Maintainer email (optional for each maintainer)
    url: # Maintainer URL (optional for each maintainer)
engine: gotpl # Template engine name (optional, the default is gotpl)
icon: # The URL of the SVG or PNG image to use as an icon (optional)
appVersion: # Included application version (optional). This doesn't have to be SemVer
deprecated: # Is this "chart" deprecated (optional, Boolean)
tillerVersion: This“ chart"Required“ Tiller"Version. This should be expressed as SemVer Scope:“>2.0.0"((optional)

Example:

apiVersion: v1
appVersion: "1.0"
description: A Helm chart for project
name: project
version: 0.1.0

3.2 templates

The templates directory stores the templates of Kubernetes deployment files.

3.2.1 deployment

Here's another introduction to deployment:

Deployment provides a declarative method for Pod and ReplicaSet to replace the previous replication controller for more convenient management applications.

As the most commonly used Kubernetes object, deployment is often used to create ReplicaSet and Pod. We often do not directly use ReplicaSet to deploy a new microservice in the cluster. On the one hand, the function of ReplicaSet is not powerful enough. Some common update, capacity expansion and capacity reduction operation and maintenance operations are not supported. Deployment is introduced to support these Complex operations.

3.2.2 deployment.yaml

The deployment file consists of the following four parts:

• apiVersion: indicates the version
• kind: indicates a resource
• metadata: represents meta information
• spec: resource specification field

Example:

apiVersion: extensions/v1
kind: Deployment
metadata:
  name: {{ template "fullname" . }}
  labels:
    chart: "{{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}"
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ template "fullname" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        ports:
        - containerPort: {{ .Values.service.internalPort }}
        livenessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        readinessProbe:
          httpGet:
            path: /
            port: {{ .Values.service.internalPort }}
        resources:
{{ toyaml .Values.resources | indent 12 }}

It should be noted that in the above yaml configuration file, there are double brace wrapped parts. These are Go template, in which Values is the variable content defined in the values.yaml file.

3.2.3 values.yaml

Take values.yaml, a version of nginx, as an example:

# Default values for mychart.
# This is a yaml-formatted file.
# Declare variables to be passed into your templates.
replicaCount: 1
image:
  repository: nginx
  tag: stable
  pullPolicy: IfNotPresent
service:
  name: nginx
  type: ClusterIP
  externalPort: 80
  internalPort: 80
resources:
  limits:
    cpu: 100m
    memory: 128Mi
  requests:
    cpu: 100m
    memory: 128Mi

In this way, through the values.yaml file and variable mapping rules, we can replace the variables in deployment.yaml with the values in values.yaml. In addition, considering the differences of different environments, we can also distinguish the variable values of development, test and online centralized environments by defining values-dev.yaml, values-qa.yaml and values-online.yaml, and realize different environments in combination with the pipeline Continuous integration of.

IV. appendix

4.1 about apiVersion

apiVersion refers to the api version of kubernetes. For relevant information, please see Which Kubernetes apiVersion Should I Use.

Make complaints about Deployment apps/v1, but there is not a detailed explanation of apiVersion in official document of Kubernetes. Moreover, because K8S itself is also undergoing rapid iteration, some of the resources are still in the beta stage in the low version, and stable becomes a high version.

1.6 Before version apiVsersion: extensions/v1beta1
1.6 Version to 1.9 Between versions: apps/v1beta1
1.9 After version:apps/v1

4.2 introduction to apiversion versions

Early alpha, beta and stable:

alpha

• The software may contain errors. Enabling a feature may cause a bug
• Support for this feature may be discarded at any time without notice

beta

• The software has been well tested. Enabling the function is considered safe.
• The function is on by default
• The details may change, but the function will not be deleted in subsequent versions

stable

• The naming method of the version Name: vX, where X is an integer
• Stable version and safe use
• Will appear in subsequent releases of the software

v1

The stable version of Kubernetes API contains many core objects: pod, service, etc

apps/v1beta2

In kubernetes version 1.8, the concept of apps/v1beta2 is added, and the same is true for apps/v1beta1

The current versions of DaemonSet, Deployment, ReplicaSet and stateful set are migrated to apps/v1beta2, which is compatible with the original extensions/v1beta1

apps/v1

In kubernetes version 1.9, resources such as apps/v1 and deployment are introduced and moved from extensions/v1beta1, apps/v1beta1 and apps/v1beta2 to apps/v1. The original v1beta1 is discarded.

apps/v1 stands for api combinations that contain some common application layers, such as Deployments, RollingUpdates, and ReplicaSets

batch/v1

Represents a combination of job related APIs

In kubernetes version 1.8, batch/v1beta1 is added. After that, CronJob has migrated to batch/v1beta1, and then to batch/v1

autoscaling/v1

Represents the api combination of automatic capacity expansion and reduction, which is introduced in kubernetes version 1.8.

The subsequent alpha and beta versions of this combination will support capacity expansion based on memory usage and other monitoring indicators

extensions/v1beta1

Resources such as deployment are placed in this version in version 1.6, then moved to apps/v1beta2, and then managed uniformly in apps/v1

certificates.k8s.io/v1beta1

api combination related to security authentication

authentication.k8s.io/v1

api combination related to resource authentication

4.3 viewing k8s version and available apiVersion

4.3.1 k8s version information

kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:23:11Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.3", GitCommit:"b3cbbae08ec52a7fc73d334838e18d17e8512749", GitTreeState:"clean", BuildDate:"2019-11-13T11:13:49Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

4.3.2 supported apiVersion

[root@xxx ~]# kubectl api-versions
admissionregistration.k8s.io/v1
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
authentication.k8s.io/v1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1
authorization.k8s.io/v1beta1
autoscaling/v1
autoscaling/v2beta1
autoscaling/v2beta2
batch/v1
batch/v1beta1
certificates.k8s.io/v1beta1
coordination.k8s.io/v1
coordination.k8s.io/v1beta1
custom.metrics.k8s.io/v1beta1
events.k8s.io/v1beta1
extensions/v1beta1
metrics.k8s.io/v1beta1
monitoring.coreos.com/v1
networking.k8s.io/v1
networking.k8s.io/v1beta1
node.k8s.io/v1beta1
policy/v1beta1
rbac.authorization.k8s.io/v1
rbac.authorization.k8s.io/v1beta1
scheduling.k8s.io/v1
scheduling.k8s.io/v1beta1
settings.k8s.io/v1alpha1
stable.example.com/v1
storage.k8s.io/v1
storage.k8s.io/v1beta1
v1