ARTH TASK 24

5 min readJan 12, 2022

Steering Kubernetes Applications with Helm

Ahoy! You’re in for a Kubernetes Treat. Just hear me out. You’re a great Containerization Technology enthusiast working on a highly scalable product over Kubernetes. Everything’s working great until you are told to include some more microservices, manage RBAC and restart all the services. No doubt you’re capable of accomplishing all the tasks, but at what cost. Most likely you’ll be running multiple YAML scripts keeping their chronology in consideration, the state of the dependent pods, containers, services. Wouldn’t it be slightly easier if you could deploy your application just by one command on your CLI without any hassle?

Kubernetes and Helm

This is the part where I introduce you to Helm. Helm is a Kubernetes management tool. Helm build atop of Kubernetes will drastically help you to manage and maintain the complex Kubernetes deployment. Also, making changes and updates to your resources would be fairly straight, be it from the perspective of the developer of the cluster administrator. Helm even eases the potential trouble caused by versioning and rollbacks.

We will be diving into Kubernetes with Helm and a practical front. We will be deploying a WordPress Application over the Kubernetes cluster using Helm.

Let’s create a workspace for our project:

$ mkdir -pv wp-helm/

Helm Architecture

Helm 2

There are 2 architectures of Helm, Helm 2 and Helm 3. Helm 2 has a client-server architecture with the client called Helm and the server called Tiller. The client interacts with Tiller and the chart repository. Tiller interacts with the Kubernetes API server. It renders Helm template files into Kubernetes manifest files, which it uses for operations on the Kubernetes cluster through the Kubernetes API.

Helm3

Helm 3 was released in 2019. It’s built on top of Helm 2. The most interesting update in this update was the removal of the tiller. Therefore, now the Helm client is directly communicating with the Kubernetes API Server. By removing Tiller, Helm 3 supports all the modern security, identity, and authorization features of modern Kubernetes.

Basic Structure of Helm

Director constituents of a Helm Project

The elementary workspace of helm must consist of the following:

Chart.yaml — Helm Charts are simply Kubernetes YAML manifests combined into a single package that can be advertised to your Kubernetes clusters. The Chart.yaml describes basic information about your Chart, e.g. the name, description, or version of your chart.
values.yaml — The values.yaml defines the default values that are used for parsing the templates defined in templates/ when deploying the Helm chart.
templates directory — The templates/ folder contains all templates for your chart. Helm will parse all the .yaml files defined in this folder and parse them as templates together with the values defined in the values.yaml file

Let’s build up our application

Basic Architecture of our application

We will have 2 Deployments, WordPress Pod and MySQL Pod running in 2 different nodes in a default namespace using Helm.

Creating the charts file:

$ vim wp-helm/Charts.yamlapiVersion: v1
name: mywebversion: 0.1
appVersion: 1.1
description: This is my first chart

This file has the basic version information of our release.

Creating the values:

$ vim wp-helm/values.yamlwordpress: mywp1
data_base_root_pass: <<db_rootpass>>
data_base_name: <<db_username>>
user: <<db_username>>
data_base_pass: <<db_userpass>>
sql_image: mysql:5.7
sql_db_name: <<db_name>>
wordpress_image: wordpress:5.1.1-php7.3-apache

The values.YAML file contains all the parameters we will require while deploying our application.

Creating the Templates:

For a WordPress application to run, we have a basic checklist:

✓ A WordPress Container

✓ An SQL Server

✓ Exposing the WebServer Port for Public Connectivity

Thus, we have to create 3 YAML manifests for each of these resources.

wordpress.yml

$ vim wp-helm/templates/wordpress.ymlapiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: {{ .Values.wordpress }}
  name: {{ .Values.wordpress }}
spec:
  replicas: 2
  selector:
    matchLabels:
      run: {{ .Values.wordpress }}
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: {{ .Values.wordpress }}
      name: {{ .Values.wordpress }}
    spec:    
      containers:
      - image: {{ .Values.wordpress_image }}
        name: {{ .Values.wordpress }}
        resources: {}
      dnsPolicy: ClusterFirst
      restartPolicy: Always
status: {}

mysql.yml

$ vim wp-helm/templates/mysql.ymlapiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    run: mydb1
  name: mydb1
spec:
  replicas: 2
  selector:
    matchLabels:
      run: mydb1
  template:
    metadata:
      creationTimestamp: null
      labels:
        run: mydb1
      name: mydb1
    spec:
      containers:
      - env:
        - name: MYSQL_ROOT_PASSWORD
          value: {{ .Values.data_base_root_pass }}
        - name: MYSQL_DATABASE
          value: {{ .Values.data_base_name }}
        - name: MYSQL_USER
          value: {{ .Values.user }}
        - name: MYSQL_PASSWORD
          value: {{ .Values.data_base_pass }}
        image: {{ .Values.sql_image }}
        name: {{ .Values.sql_db_name }}
        resources: {}
      dnsPolicy: ClusterFirst
      restartPolicy: Always
status: {}

service.yml

$ vim wp-helm/templates/service.ymlapiVersion: v1
kind: Service}}
metadata:
  creationTimestamp: null
  labels:
    app.kubernetes.io/managed-by: Helm
    run: mywp1
  name: mywp1ss_image }}
spec:
  ports:s }}
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: mywp1
  type: NodePort
status:
  loadBalancer: {}