Helm is a package management tool in the Kubernetes ecosystem. This article introduces the concepts and basic working principles of Helm, and uses a concrete example to learn how to use Helm to package, distribute, install, upgrade, and roll back Kubernetes applications.

Kubernetes application deployment challenges

Kubernetes is a container-based application cluster management solution. Kubernetes provides a series of complete functions for containerized applications, such as deployment running, resource scheduling, service discovery and dynamic scaling.

The core design concept of Kubernetes is that the user defines the rules for the application to be deployed, and Kubernetes is responsible for deploying and running the application according to the defined rules. Kubernetes is responsible for automatically correcting the application if it deviates from the defined specifications due to problems. For example, if the defined application rule requires the deployment of two instances (Pod), and one instance terminates abnormally, Kubernetes will detect and restart a new instance.

Users use Kubernetes API objects to describe application rules, including Pod, Service, Volume, Namespace, ReplicaSet, Deployment, Job, and so on. Typically, the definition of these resource objects needs to be written to a series of YAML files and then deployed using the Kubernetes command line tool Kubectl to call the Kubernetes API.

A typical three-tier WordPress application, for example, involves multiple Kubernetes API objects, and it is possible to maintain multiple YAML files simultaneously to describe these Kubernetes API objects.

As you can see from the figure above, we faced the following problems when deploying Kubernetes software:

  • How to manage, edit, and update these scattered Kubernetes application configuration files.

  • How to manage a set of related configuration files as an application.

  • How to distribute and reuse Kubernetes application configuration.

Helm was created to address these problems.

What is Helm?

Helm is a package management tool developed by Deis for Kubernetes applications, mainly for managing Charts. Similar to APT in Ubuntu or YUM in CentOS.

Helm Chart is a series of YAML files that encapsulate Kubernetes native applications. You can customize some of the application Metadata as you deploy the application to facilitate application distribution.

For application publishers, the Helm allows them to package applications, manage application dependencies, manage application versions, and publish applications to a software repository.

For users, there is no need to write complex application deployment files after using Helm. They can find, install, upgrade, roll back and uninstall applications on Kubernetes in a simple way.

Helm components and related terms

  • Helm

Helm is a command-line client tool. It is mainly used for the creation, packaging, and publishing of Kubernetes application Chart as well as the creation and management of local and remote Chart repositories.

  • Tiller

Tiller is a server for Helm and is deployed in the Kubernetes cluster. Tiller is used to receive Helm’s request and generate Kubernetes deployment file (Helm called Release) according to Chart, and then submit to Kubernetes to create the application. Tiller also provides the upgrade, delete, rollback, and other functions of Release.

  • Chart

Helm software package, in TAR format. The APT DEB package or YUM RPM package contains a set of YAML files that define Kubernetes resources.

  • Repoistory

Helm’s software Repository, Repository is essentially a Web server that holds a list of Chart packages for users to download and provides a list of Chart packages for that Repository to query. Helm can manage multiple different repositories simultaneously.

  • Release

Chart deployed in the Kubernetes cluster using the helm install command is called Release.

Note: It is important to note that the Release mentioned in Helm is different from the version in our general concept. Release here can be understood as an application instance deployed by Helm using the Chart package.

Working Principle of Helm

This diagram describes the relationships among Helm’s key components Helm (client), Tiller (server), Repository (Chart software Repository), and Chart (software package).

Chart the Install process

  • Helm parses Chart structure information from a specified directory or TAR file.

  • Helm passes the specified Chart structure and Values information to Tiller via gRPC.

  • Tiller generates a Release based on Chart and Values.

  • Tiller sends releases to Kubernetes to generate releases.

Chart the Update process

  • Helm parses Chart structure information from a specified directory or TAR file.

  • Helm passes Tiller the Release name, Chart structure, and Values information that needs to be updated.

  • Tiller generates a Release and updates the History of the Release with the specified name.

  • Tiller sends releases to Kubernetes to update releases.

Chart the Rollback process

  • The name of the Release Helm will roll back is passed to Tiller.

  • Tiller looks up History based on the name of Release.

  • Tiller took the last Release from History.

  • Tiller sends the previous Release to Kubernetes to replace the current Release.

Chart handles dependency descriptions

When Tiller deals with Chart, he directly merges Chart and all Charts it depends on into a Release and passes it to Kubernetes at the same time. Tiller is therefore not responsible for managing the boot order between dependencies. The application in Chart needs to be able to handle dependencies on its own.

Deploy the Helm

Install the Helm client

The Helm can be installed in binary mode in many ways. For more installation methods, see the Helm’s official help documentation.

  • Use the script provided by the official one click installation

$ curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
$ chmod 700 get_helm.sh
$ ./get_helm.shCopy the code

  • Manual Download and Installation

# download Helm $wget https://storage.googleapis.com/kubernetes-helm/helm-v2.9.1-linux-amd64.tar.gz # decompression Helm $tar ZXVF. - Helm-v2.9.1-linux-amd64.tar. gz # Copy the client execution file to the bin directory $cp linux-amd64/helm /usr/local/bin/Copy the code

Note: Storage.googleapis.com is inaccessible by default. Resolve this problem by yourself.

Install the Helm server Tiller

Tiller is deployed in a Kubernetes cluster in Deployment mode and can be easily installed using the following instructions.

$ helm initCopy the code

Since Helm pulls the image from storage.googleapis.com by default, you can use the following command to install it if your current machine cannot access the domain name:

$helm init --upgrade --tiller-image $helm init --upgrade --tiller-image Registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.9.1 - stable - '08 - url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chartsCopy the code
To the authorization of the Tiller

Since Helm’s server Tiller is a Deployment in Kubernetes under the Namespace of Kube-system, it will connect to kube-API to create and delete applications in Kubernetes.

As of Kubernetes 1.6, API Server has RBAC authorization enabled. Tiller is currently deployed without an authorized ServiceAccount defined by default, which results in access to the API Server being denied. So we need to explicitly add authorization for Tiller deployment.

  • Create Kubernetes service account and bind role

$ kubectl get deployment --all-namespaces
NAMESPACE     NAME                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube-system   tiller-deploy          1         1         1            1           1h
$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tillerCopy the code

  • Set up an account for Tiller

$kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}' deployment.extensions "tiller-deploy" patchedCopy the code

  • Check whether the authorization is successful

$ kubectl get deploy --namespace kube-system   tiller-deploy  --output yaml|grep  serviceAccount
serviceAccount: tiller
serviceAccountName: tillerCopy the code
Verify that Tiller is installed successfully
$ kubectl -n kube-system get pods|grep tiller tiller-deploy-6d68f5c78f-nql2z 1/1 Running 0 5m $ helm version Client: & version. Version {SemVer: "v2.9.1 GitCommit:" 20 adb27c7c5868466912eebdf6664e7390ebe710 GitTreeState: "clean"} Server: & version. Version {SemVer: "v2.9.1 GitCommit:" 20 adb27c7c5868466912eebdf6664e7390ebe710 GitTreeState: "clean"}Copy the code

Uninstall the Tiller on the Helm server

If you need to uninstall a deployed Tiller in Kubernetes, use the following command to do so.

$ helm resetCopy the code

Build a Helm Chart

Let’s go through a complete example to learn how to create, package, distribute, install, upgrade, and roll back Kubernetes applications using Helm.

Create a Chart called myChart

$ helm create mychartCopy the code

This command creates a mychart directory with the following directory structure. Here we focus on the chart. yaml, values.yaml, notes.txt, and Templates directories in the directory.

Tree mychart $/ mychart ├ ─ ─ charts ├ ─ ─ Chart. The yaml ├ ─ ─ templates │ ├ ─ ─ deployment. The yaml │ ├ ─ ─ _helpers. TPL │ ├ ─ ─ ├─ ├─ values. Exdirectories, 3 filesCopy the code

  • Chart.yaml describes information about the Chart, including name, description, and version.

  • Values. yaml is used to store the values of variables used in the templates file in the templates directory.

  • The notes. TXT file describes the information after Chart deployment, for example, how to use Chart and lists the default Settings.

  • In the Templates directory is the template for the YAML file, which follows the Go template syntax.

YAML file Templates in the Templates directory are defined in values.yaml by default, such as the container image image defined in deployment.yaml: “{{.values.image.repository}}:{{.values.image.tag}}” where.values.image.repository value is defined in values.yaml nginx, The value of.values.image. tag is stable.

$ cat mychart/values.yaml|grep repository
repository: nginx

$ cat mychart/values.yaml|grep tag
tag: stableCopy the code

The above two variable values are the default values automatically generated when creating chart, and you can modify them according to your actual situation.

If you need more information about Go templates, check out Hugo’s introduction to Go templates.

Write an introduction to the application

Open chart.yaml and fill in the details of your deployed application, using Mychart as an example:

$cat mychart/ chart. yaml apiVersion: v1 appVersion: "1.0" Description: A Helm Chart for Kubernetes name: Mychart version: 0.1.0 fromCopy the code

Compile application deployment information

Edit values.yaml, which deploys an Nginx in Kubernetes by default. Here is the contents of the values. Yaml file for the Mychart application:

$ cat mychart/values.yaml
# 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:
type: ClusterIP
port: 80

ingress:
enabled: false
annotations: {}
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
path: /
hosts:
- chart-example.local
tls: []
#  - secretName: chart-example-tls
#    hosts:
#      - chart-example.local

resources: {}
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources, such as Minikube. If you do want to specify resources, uncomment the following
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
# limits:
#  cpu: 100m
#  memory: 128Mi
# requests:
#  cpu: 100m
#  memory: 128Mi

nodeSelector: {}

tolerations: []

affinity: {}Copy the code

Check that dependencies and templates are configured correctly

$ helm lint mychart/
==> Linting .
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, no failuresCopy the code

If the file format is incorrect, modify it as prompted.

Package your application

$helm package mychart Successfully packaged chart and saved it to: /home/k8s/mychart-0.1.0.tgzCopy the code

The mychart directory will be packaged as a package in mychart-0.1.0.tgz format, which will be placed in the current directory and also saved in the Helm’s local default repository directory.

If you want to see more detailed output, add the –debug parameter to view the packaged output, which should look something like this:

$ helm package mychart --debug Successfully packaged chart and saved it to: / home/k8s/mychart - 0.1.0 from.tgz/debug Successfully saved/home/k8s/mychart - 0.1.0 from TGZ to/home/k8s /. Helm/repository/localCopy the code

Publish applications to Repository

Although we have packaged Chart and published it in the Helm’s local directory, the myChart package that was just generated cannot be found through the Helm search command.

$ helm search mychart
No results foundCopy the code

This is because the Chart package in the Repository directory is not managed by Helm yet. Using the helm repo list command, you can see information about the Repository currently configured in the helm.

$ helm repo list
NAME    URL
stable  https://kubernetes.oss-cn-hangzhou.aliyuncs.com/chartsCopy the code

Note: In the new version, a local repository named local is configured by default after the helm init command is executed.

We can start a Repository Server locally and add it to the Helm Repo list. Helm Repository must be provided as a Web service. Here we use the Helm Serve command to start a Repository Server. The default Server using the $HOME /. Helm/repository/local directory as a Chart of storage, and provide service on port 8879.

$helm Serve & Now Serving you on 127.0.0.1:8879Copy the code

By default, this service only listens on 127.0.0.1. If you want to bind to another network interface, use the following command:

$helm serve --address 192.168.100.211:8879&Copy the code

If you want to use the specified directory for Helm Repository, add the –repo-path parameter:

$helm serve - address 192.168.100.211:8879 - '08 - path/data/helm/repository/url http://192.168.100.211:8879/charts/Copy the code

Update the Chart Metadata record to the index.yaml file using the helm repo index command:

# update Helm Repository index file $CD/home/k8s /. Helm/Repository/local $Helm repo index - url = HTTP: / / http://192.168.100.211:8879.Copy the code

After starting the local Helm Repository Server, you can add the local Repository to the Helm’s Repo list.

$helm Repo add local http://127.0.0.1:8879 "Local" has been added to your RepositoriesCopy the code

Now look at the MyChart package again and you’ll find it.

$helm repo Update $helm Search mychart NAME CHART VERSION APP VERSION DESCRIPTION local/mychart 0.1.0 1.0 A helm CHART  for KubernetesCopy the code

Deploy the application in Kubernetes

Deploying an application

After Chart is published to the repository, it can be deployed using the Helm install command.

  • Check whether the configuration and template are valid

When you deploy an application using the helm install command, you actually render the templates file in the Templates directory into a YAML format that Kubernetes recognizes.

We can use helm install –dry-run –debug

–name

to verify the Chart configuration before deployment. This output contains the variable configuration of the template and the YAML file for final rendering.

$ helm install --dry-run --debug local/mychart --name mike-test [debug] Created tunnel using local port: '46649' [debug] SERVER: "127.0.0.1:46649" [debug] Original chart version: "" [debug] Fetched local/mychart to/home/k8s /. Helm/cache/archive/mychart - 0.1.0 from..tgz/debug CHART PATH: / home/k8s /. Helm/cache/archive/mychart - 0.1.0 from. TGZ NAME: mike - test REVISION: 1 RELEASED: Mon Jul 23 10:39:49 2018 CHART: Mychart-0.1.0 user-supplied VALUES: {} COMPUTED VALUES: affinity: {} image: pullPolicy: IfNotPresent Repository: nginx tag: stable ingress: annotations: {} enabled: false hosts: - chart-example.local path: / tls: [] nodeSelector: {} replicaCount: 1 resources: {} service: port: 80 type: ClusterIP tolerations: [] HOOKS: MANIFEST: --- # Source: mychart/templates/service.yaml apiVersion: v1 kind: Service metadata: name: mike-test-mychart labels: app: Mychart chart: mychart-0.1.0 Release: Mike-test Heritage: Tiller spec: type: ClusterIP Ports: -port: 80 targetPort: http protocol: TCP name: http selector: app: mychart release: mike-test --- # Source: mychart/templates/deployment.yaml apiVersion: apps/v1beta2 kind: Deployment metadata: name: mike-test-mychart labels: App: mychart chart: mychart-0.1.0 release: Mik-test Heritage: Tiller spec: replicas: 1 selector: matchLabels: app: mychart release: mike-test template: metadata: labels: app: mychart release: mike-test spec: containers: - name: mychart image: "nginx:stable" imagePullPolicy: IfNotPresent ports: - name: http containerPort: 80 protocol: TCP livenessProbe: httpGet: path: / port: http readinessProbe: httpGet: path: / port: http resources: {}Copy the code

Once the validation is complete, we can deploy it to Kubernetes using the following command.

We need to specify Chart name and Release (deployed instance) name. $ helm install local/mychart --name mike-test NAME: mike-test LAST DEPLOYED: Mon Jul 23 10:41:20 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE cluster-ip external-ip PORT(S) AGE mike-test-mychart ClusterIP 10.254.120.177 < None > 80/TCP 1s ==> v1beta2/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mike-test-mychart 1 0 0 0 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE mike-test-mychart-6d56f8c8c9-d685v 0/1 Pending 0 0s NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app=mychart,release=mike-test" -o Jsonpath ="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080:80Copy the code

Note: Helm Install uses SOcat by default. You need to install the SOcat package on all nodes.

With deployment complete, Nginx is now deployed on the Kubernetes cluster. After executing the commands prompted on the local host, you can access the Nginx instance locally.

$ export POD_NAME=$(kubectl get pods --namespace default -l "app=mychart,release=mike-test" -o Jsonpath ="{.items[0].metadata.name}") $echo "Visit http://127.0.0.1:8080 to use your application" $kubectl port-forward $POD_NAME 8080:80Copy the code

Access Nginx locally

$curl http://127.0.0.1:8080... <title>Welcome to nginx! </title> <body> <h1>Welcome to nginx! </h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> ......Copy the code

Use the following command to list all deployed Releases and their corresponding Chart.

$helm List NAME REVISION UPDATED STATUS CHART NAMESPACE Mike-test 1 Mon Jul 23 10:41:20 2018 DEPLOYED MyCHARt-0.1.0 defaultCopy the code

You can also use helm Status to query the status of a particular Release.

$ helm status mike-test LAST DEPLOYED: Mon Jul 23 10:41:20 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE mike-test-mychart-6d56f8c8c9-d685v 1/1 Running 0 1m ==> v1/Service NAME TYPE cluster-ip external-ip PORT(S) AGE mike-test-mychart ClusterIP 10.254.120.177 < None > 80/TCP 1M ==> v1beta2/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mike-test-mychart 1 1 1 1 1m NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app=mychart,release=mike-test" -o Jsonpath ="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080:80Copy the code
Upgrade and roll back an application

As you can see from the helm List output above, there is a Revision field that indicates how many times a Release was updated, and we can use this feature to roll back deployed releases.

  • Modify the chart.yaml file

Change the version number from 0.1.0 to 0.2.0, and then use the helm Package command to package and publish to the local repository.

$ cat mychart/Chart.yaml
apiVersion: v1
appVersion: "1.0"
description: A Helm chart for Kubernetes
name: mychart
version: 0.2.0

$ helm package mychart
Successfully packaged chart and saved it to: /home/k8s/mychart-0.2.0.tgzCopy the code

  • Example Query Chart information in the local repository

We can see that there are two versions of MyChart in the local repository.

$helm search mychart -l NAME CHART VERSION APP VERSION DESCRIPTION local/mychart 0.2.0 1.0 A helm CHART for Kubernetes Local/myChart 0.1.0 1.0 A Helm chart for KubernetesCopy the code

  • Upgrading an application

Now upgrade the deployed Mike-test to the new version using the helm upgrade command. You can specify the version you want to upgrade by using the –version parameter. If no version is specified, the latest version is used by default.

$ helm upgrade mike-test local/mychart Release "mike-test" has been upgraded. Happy Helming! LAST DEPLOYED: Mon Jul 23 10:50:25 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE mike-test-mychart-6d56f8c8c9-d685v 1/1 Running 0 9m ==> v1/Service NAME TYPE cluster-ip external-ip PORT(S) AGE Mike-test-mychart ClusterIP 10.254.120.177 < None > 80/TCP 9m ==> v1beta2/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE mike-test-mychart 1 1 1 1 9m NOTES: 1. Get the application URL by running these commands: export POD_NAME=$(kubectl get pods --namespace default -l "app=mychart,release=mike-test" -o Jsonpath ="{.items[0].metadata.name}") echo "Visit http://127.0.0.1:8080 to use your application" kubectl port-forward $POD_NAME 8080:80Copy the code

Once complete, you can see that the deployed Mike-test has been upgraded to version 0.2.0.

$helm List NAME REVISION UPDATED STATUS CHART NAMESPACE Mike-test 2 Mon Jul 23 10:50:25 2018 DEPLOYED Mychart-0.2.0 defaultCopy the code

  • Roll back an application

If the updated application fails to run for some reason, you need to roll back to the old version of the application. First we can use the helm History command to view all the changes to a Release.

$helm History Mike - Test REVISION UPDATED STATUS CHART DESCRIPTION 1 Mon Jul 23 10:41:20 2018 SUPERSEDED Mychart-0.1.0 DEPLOYED Mychart-0.2.0 Upgrade CompleteCopy the code

Second, we can roll back the specified application using the following command.

$ helm rollback mike-test 1
Rollback was a success! Happy Helming!Copy the code

Note: parameter 1 is the value of REVISION in the Release history of helm History.

Finally, using both the Helm List and helm History commands, we can see that myChart has reverted to version 0.1.0.

$ helm list
NAME      REVISION  UPDATED                   STATUS    CHART         NAMESPACE
mike-test 3         Mon Jul 23 10:53:42 2018  DEPLOYED  mychart-0.1.0 default

$ helm history mike-test
REVISION  UPDATED                   STATUS      CHART         DESCRIPTION
1         Mon Jul 23 10:41:20 2018  SUPERSEDED  mychart-0.1.0 Install complete
2         Mon Jul 23 10:50:25 2018  SUPERSEDED  mychart-0.2.0 Upgrade complete
3         Mon Jul 23 10:53:42 2018  DEPLOYED    mychart-0.1.0 Rollback to 1Copy the code
Deleting an Application

If you need to remove a deployed Release, you can do so using the helm delete command.

$ helm delete mike-test
release "mike-test" deletedCopy the code

Check whether the application has been DELETED and the application has been marked as DELETED.

$ helm ls -a mike-test NAME REVISION UPDATED STATUS CHART NAMESPACE mike-test 3 Mon Jul 23 10:53:42 2018 DELETED Mychart - 0.1.0 from defaultCopy the code

You can also use the –deleted parameter to list releases that have been deleted

$ helm ls --deleted NAME REVISION UPDATED STATUS CHART NAMESPACE mike-test 3 Mon Jul 23 10:53:42 2018 DELETED Mychart - 0.1.0 from defaultCopy the code

As you can also see from the above results, by default, DELETED releases are only identified as DELETED, but the history of the Release continues to be saved.

$helm Hist Mike - Test REVISION UPDATED STATUS CHART DESCRIPTION 1 Mon Jul 23 10:41:20 2018 SUPERSEDED Mychart-0.1.0 Install complete 2 Mon Jul 23 10:50:25 2018 SUPERSEDED Mychart-0.2.0 Upgrade complete 3 Mon Jul 23 10:53:42 2018 DELETED Mychart - 0.1.0 from Deletion completeCopy the code

To remove the history of all Kubernetes resources and releases associated with a specified Release, use the following command:

$ helm delete --purge mike-test
release "mike-test" deletedCopy the code

When I checked the deleted Release again, I could not find relevant information.

$helm hist mike-test Error: release: "mike-test" not found # helm ls $ helm ls --deleted $ helm ls -a mike-testCopy the code

The Helm deploys the application instance

The deployment of WordPress

Here is an example of a typical three-tier WordPress application, including MySQL, PHP, and Apache.

PersistentVolume (PV) is temporarily closed because it is not available in the test environment. We will explain the relevant information about Persistent Volumes in the following articles.

$ helm install --name wordpress-test --set "persistence.enabled=false,mariadb.persistence.enabled=false,serviceType=NodePort" stable/wordpress NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE wordpress-test-mariadb 1 1 1 1 26m wordpress-test-wordpress 1 1 1 1 26m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE wordpress-test-mariadb-84b866bf95-n26ff 1/1 Running 1 26m wordpress-test-wordpress-5ff8c64b6c-sgtvv 1/1 Running 6 26m ==> v1/Secret NAME TYPE DATA AGE wordpress-test-mariadb Opaque 2 26m wordpress-test-wordpress Opaque 2 26m ==> v1/ConfigMap NAME DATA AGE wordpress-test-mariadb 1 26m wordpress-test-mariadb-tests 1 26m ==> v1/Service NAME TYPE Cluster-ip external-ip PORT(S) AGE Wordpus-test-mariadb ClusterIP 10.254.99.67 < None > 3306/TCP 26m WordPress-test-wordpress NodePort 10.254.175.16 < None > 80:8563/TCP,443:8839/TCP 26m NOTES: 1. Or running: export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services wordpress-test-wordpress) export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}") echo http://$NODE_IP:$NODE_PORT/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default wordpress-test-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)Copy the code

Access to the WordPress

After the deployment is complete, you can use the preceding prompt to generate the corresponding access address, user name, and password.

$export NODE_PORT=$(kubectl get --namespace default -o jsonPath ="{.spec.ports[0].nodePort}" services wordpress-test-wordpress) $ export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}") $ echo http://$NODE_IP:$NODE_PORT/admin http://192.168.100.211:8433/admin # WordPress management account and Password generated $echo Username: user Username: user $echo the Password: $(kubectl get secret --namespace default wordpress-test-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode) Password: 9jEXJgnVAYCopy the code

Here’s an image of the visit:

Helm other usage tips

  • How do I set the helm command automatic completion?

To facilitate the use of the helm command, the helm provides the automatic completion function. To use ZSH, run the following command:

$ source <(helm completion zsh)Copy the code

If you use BASH, run:

$ source <(helm completion bash)Copy the code

  • How do I use the third-party Chart repository?

As Helm became more and more popular, in addition to the use of preset official repositories, there were more and more third-party repositories (provided the network was reachable). You can add a tripartite Chart repository using the following command format.

$helm Repo add Repository name Repository URL $helm Repo UpdateCopy the code

Some third-party repository resources:

# Prometheus Operator
https://github.com/coreos/prometheus-operator/tree/master/helm

# Bitnami Library for Kubernetes
https://github.com/bitnami/charts

# Openstack-Helm
https://github.com/att-comdev/openstack-helm
https://github.com/sapcc/openstack-helm

# Tick-Charts
https://github.com/jackzampolin/tick-chartsCopy the code

  • How does Helm integrate CI/CD?

Using Helm can be scattered Kubernetes application configuration file as a Chart management, Chart source code and source code can be put together in Git library management. By parameterizing Chart, different Chart parameter configurations can be used in test and production environments.

The following figure shows a CI/CD process with Helm

  • How does the Helm manage business configuration in multiple environments (Test, Staging, Production)?

Chart supports parameter substitution and can set parameters related to business configuration as template variables. When deployed using the helm install command, specify a parameter value file so that business parameters can be stripped from Chart. For example, helm install –values=values-production.yaml wordpress.

  • How does Helm address service dependencies?

In Chart, you can declare dependencies on other charts through requirements.yaml. As shown in the following statement, Chart relies on Apache and MySQL, two third-party charts.

Dependencies: - name: mariadb version: 2.1.1 repository: https://kubernetes-charts.storage.googleapis.com/ condition: Mariadb. enabled tags: - wordpress-database-name: Apache version: 1.4.0 repository: https://kubernetes-charts.storage.googleapis.com/Copy the code

  • How do I connect Helm to the specified Kubernetes cluster?

By default, Helm accesses the Kubernetes cluster using the same configuration as the kubectl command, which is in ~/.kube/config by default.

  • How do I specify a namespace at deployment time?

Helm Install is deployed in the default namespace by default. If you want to deploy to a specified command space, you can add the –namespace argument, as in:

$ helm install local/mychart --name mike-test --namespace mynamespaceCopy the code

  • How do I view details about deployed applications?

$ helm get wordpress-testCopy the code

By default, information about the latest release is displayed. If you want to see information about a specific release, add the — Revision parameter.

$ helm get  --revision 1  wordpress-testCopy the code

Reference documentation

http://www.google.comhttp://t.cn/RgEE0dmhttp://t.cn/RgE3MyPhttp://t.cn/RgpiUAz

Today’s idea

The problem is never how to use the mind to generate new and creative ideas, but how to eliminate old ideas from the mind.

“– Dee Hawke

Recommended reading

  • Diagram of Docker architecture

  • Illustrates the Kubernetes architecture

  • MySQL User and role management

  • How Docker commands work

  • Analysis of external access to Kubernetes cluster applications in several ways