Basic Kubernetes Deployments Using Helm

Helm is a package manager for Kubernetes applications.It allows you to install/deploy/remove/update applications on our Kubernetes cluster in a similar manner to yum/apt for Linux distributions.

Helm lets you fetch,deploy and manage the lifecycle of applications, both 3rd party products and your own.

Helm introduces several familiar concepts such as:

• Charts which are the helm packages(Like deb/rpm)
• Helm repositories which hold charts(Similar to package repositories)
• A CLI with install/remove/upgrade/remove commands.

Prerequisites

The following prerequisites are required for a successful and properly secured use of Helm.

1. A Kubernetes cluster
2. Deciding what security configurations to apply to your installation, if any
3. Installing and configuring Helm.

Install Kubernetes or have access to a cluster

• You must have Kubernetes installed. For the latest release of Helm, we recommend the latest stable release of Kubernetes, which in most cases is the second-latest minor release.
• You should also have a locally configured copy of kubectl.

Why use Helm?

Kubernetes can be difficult to manage with all the objects you need to maintain (config maps/Secrets,pods,services etc). Helm manages all of this for you.

Helm greatly simplifies the process of creating,managing and deploying applications using helm charts.

In addition,helm also maintains a versioned history of every chart(Application) installation.If something goes wrong you can simply call “helm rollback”. Similarly if you need to upgrade a chart you can simply call “helm upgrade”.

What is a Helm Chart?

In helm a chart is basically just a collection of manifest files organized in a specific directory structure that describes a related Kubernetes resource.

There are two main components to chart:

Templates and Values.

These templates and values go through a template rendering engine,producing a manifest that is easily digestible by Kubernetes.

Helm uses charts to pack all required K8’s components(manifests) for an application to deploy , run and scale.

Charts are very similar to RPM and DEB packages for Linux,making it easy for developers to distribute and consume/install applications via different repositories.

How Do Helm Charts Work? Helm concepts/Charts

The three basic concepts of Helm charts are:

1. Chart — Pre-configured template of Kubernetes resources.

2. Release — A chart deployed to a Kubernetes cluster using Helm.

3. Repository — Publicly available charts.

The workflow is to search through repositories for charts and install them to Kubernetes clusters, creating releases.

Helm Chart Structure

The files and directories of a Helm chart each have a specific function

Helm packages are called charts.They consist of a few YAML configuration files and some templates that are rendered into kubernetes manifest files.

Chart.yaml #Metadata info about charts.

Charts #Define dependent helm chart names

Templates #Will maintain K’8S manifest files which is required for our applications

Values.yaml # Will define default values which will be referred in templates

These directories and files have the following functions:

• Charts/: Manually managed chart dependencies can be placed in this directory,though it is typically better to use requirements.yaml to dynamically link dependencies.
• templates/: This directory contains template files that are combined with configuration values(from values.yaml and the command line) and rendered into Kubernetes manifests.The templates use the Go programming languages template format.
• Chart.yaml: A YAML file with metadata about the chart,such as chart name and version,maintainer information,a relevant website and search keywords.
• Values.yaml: A YAML file of default configuration values for the chart.

The helm command can install a chart from a local directory , or from a .tar.gz packaged version of this directory structure.These packaged charts can also be automatically downloaded and installed from chart repositories or repos.

Helm concepts | Repository

Repositories are where helm charts are held and maintained .In essence,these are set of templates and configuration values stored as code (sometimes packed as a .tar.gz file).

An excellent example of using a Nginx ingress chart, which used to be maintained by the company in the Helm/Chart repo.

Nginx has decided to move their product to their Helm repo, and to get the latest official Chart you can now add their repo to Helm by:

$ helm rpo add nginx-stable https://helm.nginx.com/stable

$helm repo update

Followed by:

$helm install nginxingress nginx-stable/nginx-ingress

Helm concepts | Release

Think of release as 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 or update image tag to the nginx-ingress release,the revision would be incremented.Helm allows rolling back to a particular revision.

Challenges and Solutions

1. Security Concerns

• Challenge: Helm’s Tiller (in Helm v2) had security vulnerabilities, as it required cluster-wide permissions, potentially exposing sensitive data.
• Solution: Upgrade to Helm v3, which eliminates Tiller and uses client-side only architecture, enhancing security.

2. Enhancing Kubernetes YAML Flexibility with Helm Charts

• Challenge: Managing hard-coding values can lead to complex and hard-to-maintain Helm values files.
• Solution: To avoid hard-coding values in your Kubernetes manifests, use simple templates for YAML files such as Gateways and Virtual Services. This can be achieved by using Helm charts, making your configurations more manageable

HPAs (Horizontal Pod Auto-scaling): Instead of hard-coding minimum replicas or CPU requests, use variables in your values.yaml file for your Helm chart.

ConfigMaps: Use Helmify to easily convert hard-coded Config-maps to reusable Helm charts.

These templates use placeholders to avoid hard coding values.

Virtual Service Template

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: {{ .Values.virtualservice.name }} # Added virtual service name to values.yaml
spec:
 hosts:
{{- range .Values.virtualservice.hosts }}#Added host entries to values.yaml
   - {{ . }}
{{- end }}
 gateways:
   - {{ .Values.gateway.name }}#UPDATED GATEWAY NAME
#PATHS NEEDS TO BE UPDATED IN VALUES.YAML
 http:
   - match:
       {{- range .Values.virtualservice.httpPaths }}
       - uri:
           prefix: {{ . }}
       {{- end }}
     route:
       - destination:
           host: {{ include "app.fullname" . }}
           port:
             number: {{ .Values.service.port }}

ITS BEEN PASSED UNDER VALUES.YAML HAS BELOW

Gateway Template

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: {{ .Values.gateway.name }} #ADDED THE GATEWAY NAME IN VALUES.YAML
spec:
selector:
istio: ingressgateway
servers:
#PORT DETAILS NEEDS TO BE UPDATED IN VALUES.YAML
- port:
number: {{ .Values.gateway.port }}
name: {{ .Values.gateway.portname }}
protocol: {{ .Values.gateway.protocol}}
#HOST ENTRIES UPDATED IN VALUES.YAML
hosts:
{{- range .Values.virtualservice.hosts }}
- {{ . }}
{{- end }}

ITS BEEN PASSED UNDER VALUES.YAML HAS BELOW

These templates help ensure that configuration values are not hard-coded, making them easier to manage and update.

Conclusion

Helm greatly simplifies Kubernetes management by utilizing customizable charts, enabling consistent, secure, and versioned application deployments. It enhances efficiency, flexibility, and maintainability, making Kubernetes deployments more manageable and reliable for developers and organizations.