helm-kubernetes

Helm and kubernetes

In my last post, I have explainded Azure Kubernetes Service (AKS)  and I showed how to deploy an application to AKS using the dashboard. In this post, I am going to explain the basics of Helm, and also explain  what Helm, Helm charts are and how to automate application deployment to Kubernetes.

Introduction

Helm is a Kubernetes deployment tool for automating creation, packaging, configuration, and deployment of applications and services to Kubernetes clusters.

Kubernetes is a powerful container-orchestration system for application deployment. There are multiple independent resources to deal with, and each requires a dedicated YAML manifest file.

What is Helm?

If Kubernetes were an operating system, Helm would be the package manager. Ubuntu uses apt , CentOS uses yum and Kubernetes uses helm.

Helm deploys packaged applications to Kubernetes and structures them into charts. The charts contain all pre-configured application resources along with all the versions into one easily manageable package.

Helm streamlines installing, upgrading, fetching dependencies, and configuring deployments on Kubernetes with simple CLI commands. Software packages are found in repositories or are created. For more info look to here

Now adding a Helm chart to our ProductMicroservice

Add Helm Charts to a Microservice

Now adding a Helm chart to our ProductMicroservice. Visual Studio comes with great Helm support. Right-click on your project(ProductMicroservice and select Add –> Container Orchestrator Support.

This opens a new window where you can select Helm or Docker-compose. Select Kubernetes/Helm and click OK.

 

In case you haven’t Kubernetes/Helm as an option, make sure that you have the Visual Studio Tools for Kubernetes installed.

In Visual Studio Under your project (in my case ProductMicroservice) creates a new folder called charts and places a folder inside this charts folder with the name of your project. It’s important to only use lowercase because Kubernetes can process only lowercase names.

Helm Chart Templates

Helm created a subfolder, with name templates, and creates a number of files into it. with ignoring of Notes  and -helpers files, the remaining file names are Kubernetes objects. The service.yaml  is Service file, Deployment, Ingress, and Secrets. These four objects are needed to run  application in Kubernetes. These files look a bit complicated but  you should know the yaml definition of the Kubernetes objects. Basically templates are  the same, but values are added dynamically.

Here is the code of service.yaml file:

apiVersion: v1
kind: Service
metadata:
  name: {{ template "productmicroservice.fullname" . }}
  labels:
     app: {{ template "productmicroservice.name" . }}
     chart: {{ template "productmicroservice.chart" . }}
     release: {{ .Release.Name }}
     heritage: {{ .Release.Service }}
spec:
   type: {{ .Values.service.type }}
   ports:
      - port: {{ .Values.service.port }}
        targetPort: http
        protocol: TCP
        name: http
selector:
    app: {{ template "productmicroservice.name" . }}
    release: {{ .Release.Name }}

This file first defines a service, adds labels, and then configures its ports and protocol. Helm replaces all values inside the two braces. The important thing is  to notice that some start with “.Values”  like (.Values.service.type ). These values come from the values.yaml file which is outside of the templates folder (under chart folder) .

The service.yaml : this file reads two values from the values.yaml file (look to chart/values.yaml) ( .Values.service.type) and (.Values.service.port). You can find the respective values (type and port) in the values.yaml file in the service section as following:

service:
  type: ClusterIP
 port: 80

look to the Values.yaml file in visual studio under Chart/Values.yaml file, you will see that the type of the service is ClusterIP and its port is 80. This approach enables us to configure our application with changes in only one file (values.yaml). The same principle applies to all files inside the templates folder.

again in the values.yaml file the fullnameOverride parameter (fullnameOverride: productmicroservice) is used to replace the variable “productmicroservice.fullname”  in the service.yaml file, which serves, for example, as name of the deployment.

Override Values from values.yaml file.

service.yaml file reads two values from the values.yaml file: “.Values.service.type”  and  “.Values.service.port”.  This values can be found  in in the service section of values.yaml file shown as bellow:

fullnameOverride: productmicroservice
replicaCount: 1
image:
  repository: mehzan07/productmicroservice
  tag: latest
  pullPolicy: IfNotPresent
 imagePullSecrets: []
service:
  type: LoadBalancer
  port: 8080

If we take a look in the values.yaml file and you can find that the type of the service is ClusterIP and its port is 80. By this cam enables you to configure your application with changes in only one file and it is the same principle to all files inside the templates folder.

The fullnameOverride parameter is used to replace the variable productmicroservice.fullname which serves, for example, as the name of the deployment and service.

Conclusion

This post, was a very short introduction to Helm. Helm is a package manager for Kubernetes and helps you to deploy your application including all its dependencies to Kubernetes. Helm also serves as a template engine which makes it very easy to change values.

In the next post I will explain, Deploy microservice to Kubernetes using Helm Charts

You can find the code on my  GitHub.

This post is part of “Kubernetes step by step”.

Back to home page