TheLazy.Dev
Portfolio GitHub

Blog

kubernetes |helm |beginners |devops

How to deploy application on Kubernetes with Helm

wkrzywiec

Wojtek Krzywiec

Posted on January 14, 2021

How to deploy application on Kubernetes with Helm

Cover image by Andrew Neel on Unsplash

In this blog post I present step-by-step how to deploy multiple applications on Kubernetes cluster using Helm.

This is a second part of my series on Kubernetes. It compares three approaches of deploying applications:

If you haven’t read it first one, I would advise to do that and then go back to this post. But if you prefer to jump right away to this post, don’t worry, I’ll briefly introduce you to the project.

cluster

Above picture presents the target solution. Inside the cluster there will be deployed frontend (kanban-ui) and backend (kanban-app) services together with postgres database. A source code for both microservices can be found in my GitHub repository — kanban-board.

Additionally I’ve added an adminer, which is a GUI client for getting inside the database.

If we focus on one of services, e.g. on kanban-ui we can see that it needs to create two Kubernetes objects — ClusterIP & Deployment. With plain approach, using kubectl we would needed to create two files for each Kubernetes object:

apiVersion: v1
kind: Service
metadata:
  name: kanban-ui
  labels: 
    group: backend
spec:
  type: ClusterIP
  selector:
    app: kanban-ui
  ports:
    - port: 80
      targetPort: 80
Enter fullscreen mode Exit fullscreen mode 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kanban-ui
  labels:
    app: kanban-ui
    group: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kanban-ui
  template:
    metadata:
      labels:
        app: kanban-ui
        group: frontend
    spec:
      containers:
        - name: kanban-ui
          image: wkrzywiec/kanban-ui:k8s
          ports:
            - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

The same story is for any other application — they need at least two definition files. Some of them requires even more, like postgres, which needs to have PersistentVolumeClaims defined in addition. As a result for even small project we can end up with lots of files which are very similar to each other:

definitions

How to achieve the DRY in this case? Is it possible?

To reduce the number of YAML files we could merge them into one, for example, for kanban-ui it will look like this:

apiVersion: v1
kind: Service
metadata:
  name: kanban-ui
  labels: 
    group: backend
spec:
  type: ClusterIP
  selector:
    app: kanban-ui
  ports:
    - port: 80
      targetPort: 80
---

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kanban-ui
  labels:
    app: kanban-ui
    group: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kanban-ui
  template:
    metadata:
      labels:
        app: kanban-ui
        group: frontend
    spec:
      containers:
        - name: kanban-ui
          image: wkrzywiec/kanban-ui:k8s
          ports:
            - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

But it still doesn’t fix the major problem — how to avoid copy-pasting entire file just to replace couple of values? It would be great if there is a way to define a blueprint for both objects and then inject values into specific fields.

Luckily there is a solution! Helm to the rescue!

Accordingly to the official website — Helm is a package manager for Kubernetes. It helps deploy complex application by bundling necessary resources into Charts, which contains all information to run application on a cluster.

There are couple approaches how to work with Helm. One of them is to download publicly available charts from the Helm Hub. They are prepared by community and are free to use.

For instance, if we would like to run Prometheus on a cluster it would just easy as it’s described on this page — https://hub.helm.sh/charts/stable/prometheus — with the single command:

> helm install stable/prometheus
Enter fullscreen mode Exit fullscreen mode

It contains some default configuration, but can be easily overridden with YAML file and passed during installation. The detailed example I’ll show in a minute.

But Helm is not only providing some predefined blueprints, you can create your own charts!

It’s very easy and can be done by a single command helm create <chart-name> , which creates a folder with a basic structure:

> helm create example
Creating example
Enter fullscreen mode Exit fullscreen mode

helm chart

In the templates/ folder there are Helm templates that with combination of values.yaml will result in set of Kubernetes objects.

Let’s create a first chart — postgres.

But just before that, boring installations and configurations (but promise, it’ll go quick). In my demo I’m using:

When everything is installed you can start up the minikube cluster and enable ingress addon:

> minikube start

😄  minikube v1.8.1 on Ubuntu 18.04
✨  Automatically selected the docker driver
🔥  Creating Kubernetes in docker container with (CPUs=2) (8 available), Memory=2200MB (7826MB available) ...
🐳  Preparing Kubernetes v1.17.3 on Docker 19.03.2 ...
▪ kubeadm.pod-network-cidr=10.244.0.0/16
❌  Unable to load cached images: loading cached images: stat /home/wojtek/.minikube/cache/images/k8s.gcr.io/kube-proxy_v1.17.3: no such file or directory
🚀  Launching Kubernetes ...
🌟  Enabling addons: default-storageclass, storage-provisioner
⌛  Waiting for cluster to come online ...
🏄  Done! kubectl is now configured to use "minikube"

> minikube addons enable ingress
🌟  The 'ingress' addon is enabled
Enter fullscreen mode Exit fullscreen mode

Then you’ll need to edit you hosts file. Its location varies on OS:

When you find it add following lines:

172.17.0.2  adminer.k8s.com
172.17.0.2  kanban.k8s.com
Enter fullscreen mode Exit fullscreen mode

To make sure that this config is correct you’ll need to check if an IP address of minikube cluster on your machine is the same as it’s above. In order to do that run the command:

> minikube ip
172.17.0.2
Enter fullscreen mode Exit fullscreen mode

Now we can create first Helm chart:

> helm create postgres
Creating postgres
Enter fullscreen mode Exit fullscreen mode

We will not need generated files inside ./templates folder, so remove them and also clear all the content inside values.yaml.

Now we can roll up our sleeves and define all necessary files to create chart for postgres database. For a reminder, in order to deploy it with kubectl we had to have following files:

postgres files

They contain definitions of ConfigMap, Deployment, PersistentVolumeClaim and ClusterIP. Their full definitions could be found in a repository.

First, let’s create a template for postgres Deployment object, therefore inside the ./templates create a deployment.yaml file:

At first glance you might see these strange parts between two pairs of curly brackets, like {{ .Values.postgres.name }} . They are written in Go template language and are referring to a value located in a values.yaml which is located inside the root folder of a chart. For mentioned example Helm will try to match it with a value from values.yaml:

postgres:
    name: postgres
Enter fullscreen mode Exit fullscreen mode

Another example. A value for a base Docker image, defined in image: {{ .Values.postgres.container.image }} will be taken from:

postgres:
    name: postgres
    container:
        image: postgres:9.6-alpine
Enter fullscreen mode Exit fullscreen mode

And so on. We can define the structure inside this file whatever we like.

This database Deployment requires a PersistentVolumeClaim to be created to reserve some storage on a disk, therefore we need to create a Helm template — pvc.yaml inside the ./templates folder:

This one is shorter, and there is nothing new here.

Next template that we need to create is for ClusterIP, which will allow other Pods inside the cluster to enter the* Pod with postgres — service.yaml:

And finally ConfigMap template needs to be created — config.yaml. It’ll hold information about created database, user and its password (yes, not very secure, but for simple example it’s enough).

Here you might see a strange {{ -range ... }} clause, which can be translated as a for each loop known in any programming language. In above example, Helm template will try to inject values from an array defined in values.yaml:

postgres:
    config:
        data:
        - key: key
          value: value
Enter fullscreen mode Exit fullscreen mode

Inside a template, there are only dummy values. If you want to have different ones you would need to override them during installation of this set of objects on a Kubernetes cluster.

The entire values.yaml presents as follow:

replicaCount: 1

postgres:
    name: postgres
    group: db
    container:
        image: postgres:9.6-alpine
        port: 5432
    service:
        type: ClusterIP
        port: 5432
    volume:
        name: postgres-storage
        kind: PersistentVolumeClaim
        mountPath: /var/lib/postgresql/data
        pvc:
          name: postgres-persistent-volume-claim
          accessMode: ReadWriteOnce
          storage: 4Gi
    config:
        name: postgres-config
        data:
        - key: key
          value: value
Enter fullscreen mode Exit fullscreen mode

To finalize creating first chart we need to modify some metadata inside Chart.yaml file:

apiVersion: v2
name: postgres
description: A Helm chart for PostgreSQL database
type: application
version: 0.1.0
appVersion: 1.16.0
keywords:
  - database
  - postgres
home: https://github.com/wkrzywiec/k8s-helm-helmfile/tree/master/helm
maintainers:
  - name: Wojtek Krzywiec
    url: https://github.com/wkrzywiec
Enter fullscreen mode Exit fullscreen mode

Then create a new kanban-postgres.yaml file which will hold some specific values. Put it outside the postgres chart folder so the file structure can be similar to that:

postgres chart

Inside the file put only values that will be specific for this deployment, i.e. postgres database credentials (all other values we can keep as default):

postgres:
    config:
        data:
        - key: POSTGRES_DB
          value: kanban
        - key: POSTGRES_USER
          value: kanban
        - key: POSTGRES_PASSWORD
          value: kanban
Enter fullscreen mode Exit fullscreen mode

Everything is set up, we can now deploy postgres into a cluster. In a Helm world this step is called creating a new release:

> helm install -f kanban-postgres.yaml postgres ./postgres
NAME: postgres
LAST DEPLOYED: Mon Apr 13 16:13:16 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

> helm list
NAME     NAMESPACE REVISION  STATUS    CHART          APP VERSION
postgres default   1         deployed  postgres-0.1.0 1.16.0

> kubectl get deployments
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
postgres   1/1     1            1           2m14s
Enter fullscreen mode Exit fullscreen mode

Cool, the postgres is up and running! Before moving forward let’s have a closer look on helm install command, what each of an argument means:

helm install

If you plan to use a chart only to create one Helm release you might wonder what is a value behind using Helm at all.

Let me show you that on another example. Let’s create a new chart called app — it will be a template chart for three different releases — adminer, kanban-app & kanban-ui.

> helm create app
Creating app
Enter fullscreen mode Exit fullscreen mode

After removing unnecessary file from ./templates folder and cleaning the values.yaml create a deployment.yaml file:

Nothing new in particular, only some placeholders for values & two range loops to inject values from *ConfigMap*s or simple values to application container.

All 3 apps require to have also the ClusterIP objects to be deployed, therefore here is its template — service.yaml:

All default values in both templates are injected from values.yaml:

app:
    name: app
    group: app
    replicaCount: 1
    container:
        image: add-image-here
        port: 8080
        config: []
        env:
        - key: key
          value: value
    service:
        type: ClusterIP
        port: 8080
Enter fullscreen mode Exit fullscreen mode

And to close a task of creating app chart — we need to define some metadata in the Chart.yaml file:

apiVersion: v2
name: app
description: A Helm chart for any application
type: application
version: 0.1.0
appVersion: 1.16.0
keywords:
  - app
  - java
  - javascript
  - angular
home: https://github.com/wkrzywiec/k8s-helm-helmfile/tree/master/helm
maintainers:
  - name: Wojtek Krzywiec
    url: https://github.com/wkrzywiec
Enter fullscreen mode Exit fullscreen mode

Then, similarly to previous example, outside the app folder create YAML files with values which will override ones from values.yaml inside app chart.

An adminer.yaml file looks as follow:

app:
  name: adminer
  group: db
  container:
    image: adminer:4.7.6-standalone
    port: 8080
    env:
      - key: ADMINER_DESIGN
        value: pepa-linha
      - key: ADMINER_DEFAULT_SERVER
        value: postgres
Enter fullscreen mode Exit fullscreen mode

A kanban-app.yaml file:

app:
  name: kanban-app
  group: backend
  container:
    image: wkrzywiec/kanban-app:k8s
    config:
      - name: postgres-config
    env: 
      - key: DB_SERVER
        value: postgres
Enter fullscreen mode Exit fullscreen mode

A kanban-ui.yaml file:

app:
  name: kanban-ui
  group: frontend
  container:
    image: wkrzywiec/kanban-ui:k8s
    port: 80
Enter fullscreen mode Exit fullscreen mode

A resulting file structure:

file structure

Now, in order to create three releases for each application use commands:

> helm install -f adminer.yaml adminer ./app
NAME: adminer
LAST DEPLOYED: Mon Apr 13 16:57:17 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

> helm install -f kanban-app.yaml kanban-app ./app
NAME: kanban-app
LAST DEPLOYED: Mon Apr 13 16:57:36 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

> helm install -f kanban-ui.yaml kanban-ui ./app
NAME: kanban-ui
LAST DEPLOYED: Mon Apr 13 16:57:54 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

> helm list
NAME       NAMESPACE REVISION  STATUS    CHART           APP VERSION
adminer    default   1         deployed  app-0.1.0       1.16.0     
kanban-app default   1         deployed  app-0.1.0       1.16.0     
kanban-ui  default   1         deployed  app-0.1.0       1.16.0     
postgres   default   1         deployed  postgres-0.1.0  1.16.0

> kubectl get deployments
NAME         READY   UP-TO-DATE   AVAILABLE   AGE
adminer      1/1     1            1           112s
kanban-app   1/1     1            1           93s
kanban-ui    1/1     1            1           75s
postgres     1/1     1            1           45m
Enter fullscreen mode Exit fullscreen mode

Perfect! There is one more thing to do — create a chart with Ingress Controller — a gateway to a cluster.

Like before, create a new chart:

> helm create ingress
Creating ingress
Enter fullscreen mode Exit fullscreen mode

Remove all files from templates folder and clear content of values.yaml. This time, before moving straight away to defining a templates, let’s focus on to Chart.yaml first.

apiVersion: v2
name: ingress
description: A Helm chart for Ingress Controller
type: application
version: 0.1.0
appVersion: 1.16.0
keywords:
  - ingress
  - nginx
  - api-gateway
home: https://github.com/wkrzywiec/k8s-helm-helmfile/tree/master/helm
maintainers:
  - name: Wojtek Krzywiec
    url: https://github.com/wkrzywiec
dependencies:
  - name: nginx-ingress
    version: 1.36.0
    repository: https://kubernetes-charts.storage.googleapis.com/
Enter fullscreen mode Exit fullscreen mode

Here there is a new section — dependencies— which has been added. It creates default backend services which enables the Ingress Controller features.

But it’s not the only thing we need to do here. This section only defines on what this chart depends on, it won’t download it automatically during the installation. We need to take care of it ourselves. To do that run the command:

> helm dependency update ./ingress/
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading nginx-ingress from repo [https://kubernetes-charts.storage.googleapis.com/](https://kubernetes-charts.storage.googleapis.com/)
Deleting outdated charts
Enter fullscreen mode Exit fullscreen mode

Inside the ingress/charts folder a new file will appear — nginx-ingress-1.36.0.tgz .

Now we can define a template for Ingress — it will be located inside ./templates folder and will be called ingress.yaml:

The most interesting part is inside specification section. There are two nested loops there which allow to define multiple hosts and multiple paths for each host.

And also, here is a default values.yaml file:

ingress:
  name: ingress-service
  replicaCount: 1
  annotations: 
    class: nginx
  hosts:
    - host: chart-example.local
      paths: 
        - path: /
          backend:
            serviceName: serviceName
            servicePort: 8080
Enter fullscreen mode Exit fullscreen mode

The resulting folder structure:

ingress chart

Outside the ingress chart we can now create an ingress.yaml file which will hold all routing rules for our cluster.

ingress:
  hosts:
    - host: adminer.k8s.com
      paths:
        - path: /
          backend:  
            serviceName: adminer
            servicePort: 8080
    - host: kanban.k8s.com
      paths: 
        - path: /api/
          backend:
            serviceName: kanban-app
            servicePort: 8080
        - path: /
          backend:
            serviceName: kanban-ui
            servicePort: 80
Enter fullscreen mode Exit fullscreen mode

And now we’re able to create a Helm release:

> helm install -f ingress.yaml ingress ./ingress
NAME: ingress
LAST DEPLOYED: Tue Apr 14 07:22:44 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

> helm list
NAME       NAMESPACE  REVISION  STATUS    CHART          APP VERSION
adminer    default    1         deployed  app-0.1.0      1.16.0     
ingress    default    1         deployed  ingress-0.1.0  1.16.0     
kanban-app default    1         deployed  app-0.1.0      1.16.0     
kanban-ui  default    1         deployed  app-0.1.0      1.16.0     
postgres   default    1         deployed  postgres-0.1.0 1.16.0

> kubectl get deployments
NAME                                    READY  UP-TO-DATE  AVAILABLE
adminer                                 1/1    1           1           
ingress-nginx-ingress-controller        1/1    1           1           
ingress-nginx-ingress-default-backend   1/1    1           1           
kanban-app                              1/1    1           1           
kanban-ui                               1/1    1           1           
postgres                                1/1    1           1
Enter fullscreen mode Exit fullscreen mode

Everything is set up, you can start testing it. Go to the http://kanban.k8s.com and you should get this page:

kanban-ui

Congrats! 🍾🤘

Conclusions

In this short entry I’ve presented how, with Helm, you can reduce of copy-pasting tasks and can bring a one single template for deploying multiple applications on a Kubernetes cluster, which might be very handy in a microservice world. I hope you’ve enjoyed it.

But there is still one thing left, which holds us from establishing a fully declarative approach for an infrastructure. In order to deploy each application we still need to run imperative commands, like helm install. But luckily there is another tool — helmfile! But this one I’ll describe in my next story.

For now, here is my GitHub repository with a source code for this project:
wkrzywiec/k8s-helm-helmfile on github.com

And here is a source code of Kanban project:
wkrzywiec/kanban-board on github.com

References

💖 💪 🙅 🚩
wkrzywiec
Wojtek Krzywiec

Posted on January 14, 2021

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related

Manage existing resources via Helm!
kubernetes Manage existing resources via Helm!

May 7, 2023

How to deploy application on Kubernetes with Helm
kubernetes How to deploy application on Kubernetes with Helm

January 14, 2021