Packaging and Deployment on Kubernetes With Helm and Uploading Chart In S3 Bucket

../images/helmgraduation.png
Image Source: – https://helm.sh/blog/celebrating-helms-cncf-graduation/

Today Helm as moved from incubator to graduate level . In short Helm is a Package manager and its provides an easy way to find , share and use software build for Kubernetes.

What is HELM ! in detail and why we need Helm ?

  • Helm helps user to maintain the Application.
  • Helm is managed by CNCF – Cloud Native Computing Foundation.
  • Helm manages Kubernetes “charts”, which are “preconfigured packages of Kubernetes resources.”
  • Helm enables you to easily install packages, make revisions, and even roll back complex changes.

Why we Need Helm ?

  • Helm lets you fetch, deploy and manage the lifecycle of applications, both 3rd party products and your own.
  • With helm, there is a structure and a convention for a software package that defines a layer of YAML templates and another layer that changes the templates called values.
  • Values are injected into templates, thus allowing a separation of configuration, and defines where changes are allowed.
  • This whole package is called a Helm Chart.
  • Essentially you create structured application packages that contain everything they need to run on a Kubernetes cluster;
  • including dependencies the application requires.

Helm CLI or Tiller

  • Helm is a CLI tool that interacts with its backend server called “Tiller”.
  • Tiller is typically installed by sending the command helm-init and lives in the kube-system namespace.
  • When a Chart is installed, Tiller creates a “Release” and starts tracking it for changes.
  • This way Helm not only takes part in installation but is an actual deploy tool that manages the lifecycle of applications in a cluster using Chart Releases and their revisions.

Helm Charts or Packages

  • Helm uses Charts to pack all the required K8S components for an application to deploy, run and scale.
  • Helm chart is simply a collection of YAML template files organized into a specific directory structure.
  • Chart is also where dependencies are defined, and configurations are updated and maintained.
  • A chart root has to have only one file named Chart.yml by convention.
  • Templates are an optional subdirectory in a chart that combines the K8S components of it, e.g. Services, ReplicaSet, Deployment etc.
  • Values are described in the values.yml file which is necessarily a YAML structure holding values to match the templates.
  • Values basically define the Deployment values like name, labels.
  • Subcharts also named dependencies, are required charts for the current one.
  • Another way of using Subcharts is considering it as an inheritance mechanism which allows fetching a standard chart with templates and uses it as a Subcharts in multiple parent charts that would provide the values.

Helm concepts | Repository

  • Repositories are where helm charts are held and maintained. Sometimes HELM packed repository as a .tar.gz file.

Helm concepts | Release

  • Release is a mechanism to track installed applications on a K8S cluster; when an application is installed by Helm, a release is being created.
  • Releases can be tracked with helm ls, each would have a “revision” which is the Helm release versioning terminology; if a specific release is updated, e.g., adding more memory to the Redis release, the revision would be incremented.
  • Helm allows rolling back to a particular revision, making it virtually the manager for deployments and production status handler.

Installing HELM on Kubernetes

# Helm v2

Step 1: Install helm

wget https://storage.googleapis.com/kubernetes-helm/helm-v2.14.1-linux-amd64.tar.gztar -xzvf helm-v2.14.1-linux-amd64.tar.gzsudo mv linux-amd64/helm /usr/local/bin/helm

Step 2: Verify Helm Package

helm -h

Step 3: Initialize helm

apiVersion: v1
kind: ServiceAccount
metadata:
  name: helm-tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: helm-tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: helm-tiller
    namespace: kube-system
kubectl create -f helm-rbac.yml 
helm init --service-account helm-tiller

Step 4: Verify Where it deployed

kubectl get pods -n kube-system

Step 5 : Serch for some application like

helm search <Application Name>

Step 6 : Install Application via Helm

helm install <Application Name>

– Each installation of a Helm chart to your cluster is referred to as a release.

– With Helm it’s easy to have multiple releases installed to a single cluster, each with its own specific configuration.

helm install --name <releasename> <ApplicationName>

Create & Deploy HELM Chart on Cluster

Step 1: Create HELM Chart

- helm create <chart-name>

– Name of the chart provided here will be the name of the directory where the chart is created and stored.

Let’s understand the relevance of these files and folders created for us:

Chart.yaml: This is the main file that contains the description of our chart

values.yaml: this is the file that contains the default values for our chart

templates: This is the directory where Kubernetes resources are defined as templates

charts: This is an optional directory that may contain sub-charts

step 2: HELM Commands for Chart

- helm lint <chart-full-path>

This is a simple command that takes the path to a chart and runs a battery of tests to ensure that the chart is well-formed

- helm template <chart-full-path>

This will generate all templates with variables without a Tiller Server, for quick feedback, and show the output. Now that we know everything is OK, we can deploy the chart:

- helm install --name <release-name> <chart-full-path>

Run this command to install the chart into the Kubernetes cluster:

- helm ls --all

We would like to see which charts are installed as what release.

- helm upgrade <release-name> <chart-full-path>

This command helps us to upgrade a release to a specified or current version of the chart or configuration:

- helm rollback <release-name> <release-version>

This is the command to rollback a release to the previous version:

- helm delete --purge <release-name>

We can use this command to delete a release from Kubernetes:

Upload HELM Chart in S3 Bucket

Step 1 : AWS CLI Credentials must be Set on Machine

Step 2: Verify

aws sts get-caller-identity

Step 3: Create Chart in S3 Bucket

Execute Shell Script:

#!/bin/bash
set -e
# create random string
RANDOM_STRING=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 8 |
tr '[:upper:]' '[:lower:]' | head -n 1)
echo "My Random String - $RANDOM_STRING "
# it's important to set the AWS_REGION if not set. Change the
default
DEFAULT_REGION="ap-south-1"
AWS_REGION="${AWS_REGION:-${DEFAULT_REGION}}"
export AWS_REGION
# create s3 bucket
if [ "$AWS_REGION" == "ap-south-1" ] ; then
    aws s3api create-bucket --bucket helm-${RANDOM_STRING} --region
$AWS_REGION --create-bucket-configuration LocationConstraint=$
{AWS_REGION}
else
    echo "Please Specify the Correct Region"
fi
# install helm s3 plugin
helm plugin install https://github.com/hypnoglow/helm-s3.git
echo "Helm Plugin Insalled Successfully"
# initialize s3 bucket
helm s3 init s3://helm-${RANDOM_STRING}/charts
# add repository to helm
helm repo add anshul-charts s3://helm-${RANDOM_STRING}/charts
 
./s3-helm-repo.sh

Step 4: List all Repos

helm repo list

Step 5: Export AWS Resion in Variable

export AWS_REGION=ap-south-1

Step 6 : Package your Charts

helm package hello-world

Step 7: Upload your helm package

helm s3 push <tar-file> <s3chart-name>

Step 8: Search for your repository

helm search <repo-name>

Its using HELM 2 and we will see whats new in HELM 3 and how to migrate from v2 to v3 in future blog

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *