ARTH TASK 24

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: {}

Our directory tree looks like this:

$ tree wp-helm/
wp-helm/
├── Chart.yaml
├── README.md
├── templates
│ ├── mysql.yml
│ ├── service.yml
│ └── wordpress.yml
└── values.yaml

Deploying our application

$ helm install helmdemoapp /ws-helm

You would see a success release message on the terminal if everything is in place.

Let’s check out if everything is running smoothly,

✓ Check Helm Release Status :

$ helm list

✓ Check the Deployment Status:

$ kubectl get deployments

✓ Check where is the WordPress Pod running with the exposed port:

✓ Check the Service Status:

$ kubectl get svc -o wide

All set. Your Application is ready to serve!

Accessing the WordPress Application :

Our Application is Live. Similarly, if have your own application image you could very well plan for its Deployment over Kubernetes using Helm.

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Logistics: Improving Inspection and Maintenance of Locomotives

How Cloud Run Makes Fun Projects Fun Again

A quest for speed: fastening up Mockito

Why you need to automate your Software Testing?

I’m Spending This Thanksgiving With My Dead Relatives

Dynamic Hash in Ruby

The 5 Minute Raspberry Pi Setup Guide without External Display, Keyboard or Mouse

How to analyse “high CPU” in php on production. Part 1

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adithya Gangadhar Shetty

Adithya Gangadhar Shetty

More from Medium

Creative Vixstory Launches ‘I Am Not My Trauma’ An Emotive Factual Docu-Series Exploring What It…

Gates Wide Open

14th October 2021

Hypotheses Refined