Helm

helm

Often, when we build enterprise software solutions meant for independent deployment across different customer environments, we leverage a central image repository. This repository is exposed to the enterprise, who then installs it in their environment. These applications may require variables or files specific to the client's environment, which need to be injected into the image for it to run. As it's impractical to have a separate image for each customer, we use a single image that is customized and injected with required files or variables during deployment. This blog explores how to create a standardized image, inject necessary variables in the form of a file, and deploy it on a cluster. For this we will create a python app, dockerize it, build it and push it to a repository. Once pushed we will be creating standard k8 manifests and Helm charts where we will be injecting our file/variables into it. Kubernetes Application and Image Creation Let's create a simple Python program which retrieves the variables "DB_HOST" and "DB_PASSWORD", then uses them to print both of these variables to the console. import os
from dotenv import load_dotenv

# Load environment variables from .env file
load_dotenv()

db_host = os.getenv("DB_HOST")
db_password = os.getenv("DB_PASSWORD")

print(db_host)
print(db_password) Next, we'll create a Docker image that packages our application using python:3.9-slim and adds all the required packages to the image. The entry point for the image is the above Python file named . Once completed, we'll push our image to an image repository such as ECR or Docker Hub. main.py # Use an official Python runtime as the base image
FROM python:3.9-slim

# Set the working directory in the container
WORKDIR /app

# Copy the current directory contents into the container at /app
COPY . /app

# Install any needed dependencies
RUN pip install --no-cache-dir python-dotenv

# Run the Python script when the container launches
CMD ["python", "main.py"] Creating Deployment Files Once we have the image ready in our preferred image repository, we need to deploy these images on a server. Nowadays, most deployments have moved to Kubernetes, so we'll use it as our deployment platform. Deployment in Kubernetes can be achieved by creating Kubernetes manifests directly or creating HELM charts (or Kustomize), which act like package managers to deploy applications. Let's explore both options: Creating standard manifest files Below, we're creating a deployment of one replica, a service of type NodePort to expose the application, and a secret object that takes the content of our .env file and injects it into the pod when we deploy the application. apiVersion: apps/v1
kind: Deployment
metadata:
  name: python-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: python-app
  template:
    metadata:
      labels:
        app: python-app
    spec:
      containers:
      - name: your-container-name
        image: your-image-name:your-image-tag
        ports:
        - containerPort: 80
        volumeMounts:
        - name: env-volume
          mountPath: /app/.env
          subPath: .env
      volumes:
      - name: env-volume
        secret:
          secretName: python-app-env-secret
---

apiVersion: v1
kind: Service
metadata:
  name: python-app-service
spec:
  selector:
    app: python-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30001
  type: NodePort

---

apiVersion: v1
kind: Secret
metadata:
  name: python-app-env-secret
type: Opaque
data:
  .env: |
    DB_HOST=test
    DB_PASSWORD=password Creating HELM chart To create a helm chart, simply run . For our project here, we'll run . This should create a Python-app folder, which contains the standard HELM template that can be modified according to our requirements. The generated folder should have the following folder/file structure: helm create <app-name> helm create python-app my-chart/
├── charts/
├── templates/
│   ├── deployment.yaml
│   ├── hpa.yaml
│   ├── ingress.yaml
│   ├── NOTES.txt
│   ├── service.yaml
│   └── serviceaccount.yaml
│   ├── hpa.yaml
│   ├── _helpers.tpl
├── values.yaml
└── Chart.yaml We need to create a configmap.yaml file in the templates folder and add the following content to it: # templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  .env: |
    DB_HOST={{ .Values.env.DB_HOST }}
    DB_PASSWORD={{ .Values.env.DB_PASSWORD }} The deployments.yaml should look something like this: # templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "python-app.name" . }}
  labels:
    app: {{ include "python-app.name" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "python-app.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "python-app.name" . }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: 80
        volumeMounts:
        - name: cm-volume
          mountPath: /app/.env
          subPath: .env
      volumes:
      - name: cm-volume
        configMap:
          name: {{ include "python-app.name" . }} The service.yaml: # templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "python-app.name" . }}
spec:
  selector:
    app: {{ include "python-app.name" . }}
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30001
  type: NodePort The _helpers.tpl should have the following content: # templates/_helpers.tpl.yaml
{{- define "python-app.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name }}
{{- end }}{{- define "python-app.name" -}}
{{- printf "%s" .Chart.Name }}
{{- end }} In values.yaml, pass your secrets and image repository and tag: # values.yaml
image:
  repository: krishnadutt/my-python-app
  tag: latest
replicaCount: 1
env:
  DB_HOST: test
  DB_PASSWORD: your_database_password For this project, delete the rest of the files in the templates folder. Once done, apply all the manifest files or simply add the helm repository and install it in your k8s. Once deployed, if we execute into the image in Kubernetes, we should see the file and if we search the logs, we should find that .env values are used and those values are printed out by the program. Like my content? Feel free to reach out to my for interesting content and productive discussions. LinkedIn

Enhancing Dockerized Application Deployment: File Passing Strategies with Helm Charts

Overview Helm is the package manager for Kubernetes, like apt, yum, or Homebrew for traditional operating systems. It simplifies the deployment and management of applications on Kubernetes clusters by packaging all necessary components into a single, manageable unit. Why Helm? : Helm packages, known as charts, bundle together all the Kubernetes manifests (like deployments, services, etc.) needed to deploy an application, making the deployment process straightforward and repeatable. Simplifies Kubernetes Deployments : Helm charts can include other charts, allowing complex applications to manage their dependencies effectively. Manages Dependencies : Helm tracks versions of deployments, enabling rollbacks to previous states if needed. Version Control for Deployments What Is It Made of? : A Helm chart is a bundle containing all information necessary to create an instance of a Kubernetes application. It includes resource definitions and configuration files. Chart : The configuration contains customizable parameters that merge with a chart to create a release. These parameters allow the same chart to be used in different environments or configurations. Config : A release is an instance of a chart running in a Kubernetes cluster combined with a specific configuration. Release Helm Architecture Diagram : Helm Client : Local chart development and managing repositories. Chart Development : Manages releases/repos and requests chart installation or release upgrade/uninstallation through Helm Library. Release Management : Helm Library : Handles combining charts and configurations to create releases and installing/upgrading/uninstalling charts. Chart Management : Interfaces with the Kubernetes API server. Interacts with Kubernetes Creating a Chart Creating a Helm chart involves setting up a predefined directory structure with at least two files: for metadata about the chart and for default configuration values. Chart.yaml values.yaml : A basic chart directory will have the following layout: Structure : Contains metadata about the chart such as name, version, and description. Chart.yaml : Specifies default configuration values for the chart. values.yaml : This directory contains template files that generate Kubernetes manifest files based on the values provided. templates/ : Helm uses a templating engine to substitute values in the chart templates, creating Kubernetes manifests tailored to specific deployments. This allows for dynamic adjustment of resources, labels, and configurations without altering the original chart files. Templating Practice : Scenario A startup, "DevOps Solutions" adopts Helm to streamline their Kubernetes deployments. You're a consultant tasked with creating a basic Helm Chart for . It should be customizable for different environments using values. n8n Clone the repo. git clone https://github.com/perplexedyawdie/helm-learn.git Change directory to creating-charts cd helm-learn/creating-charts Spin up the environment using docker-compose. docker compose up -d --build SSH into the container. ubuntu ssh -o StrictHostKeyChecking=no -o NoHostAuthenticationForLocalhost=yes root@localhost -p 2222
# password: test123 Generate a chart directory along with sample files. helm create my-n8n View the structure of the generated directory. tree .

# Output should look similar to this
#`-- my-n8n
#    |-- Chart.yaml
#    |-- charts
#    |-- templates
#    |   |-- NOTES.txt
#    |   |-- _helpers.tpl
#    |   |-- deployment.yaml
#    |   |-- hpa.yaml
#    |   |-- ingress.yaml
#    |   |-- service.yaml
#    |   |-- serviceaccount.yaml
#    |   `-- tests
#    |       `-- test-connection.yaml
#    `-- values.yaml We'll only be using , , and so we can remove the rest since we'll be adding our own manifest files. Chart.yaml values.yaml my-n8n/templates/NOTES.txt my-n8n/templates/_helpers.tpl rm -rf my-n8n/templates/*.yaml my-n8n/templates/tests Update the appVersion in Chart.yaml to "1.27.2" & clear the contents of my-n8n/templates/NOTES.txt file then update with the following. nano my-n8n/Chart.yaml
# appVersion: "1.27.2"

nano my-n8n/templates/NOTES.txt
# Welcome to n8n.
# Wait a few minutes until the status changes to RUNNING.
# After it is ready, access it from: http://localhost:2223 Update the file with the following data. values.yaml # Default values for my-n8n.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

image:
  repository: n8nio/n8n
  pullPolicy: IfNotPresent
  # Overrides the image tag whose default is the chart appVersion.
  tag: "1.27.2"

containerPorts:
 - name: http
   port: 5678

service:
  type: NodePort
  port: 30200

livenessProbe:
  httpGet:
    path: /
    port: http
readinessProbe:
  httpGet:
    path: /
    port: http

autoscaling:
  enabled: false
  minReplicas: 1
  maxReplicas: 100
  targetCPUUtilizationPercentage: 80
  # targetMemoryUtilizationPercentage: 80

# Additional volumes on the output Deployment definition.
volumes:
- name: n8n-data

persistence:
   claimName: n8n-data

# Additional volumeMounts on the output Deployment definition.
volumeMounts:
 - name: n8n-data
   mountPath: "/home/node/.n8n" Create the , and, files inside the folder. deployment.yaml service.yaml pvc.yaml my-n8n/templates # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: n8n-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: n8nio/n8n
        ports:
        - name: http        
        - containerPort: 5678
        volumeMounts:
        - name: n8n-data
          mountPath: /home/node/.n8n
      volumes:
      - name: n8n-data
        persistentVolumeClaim:
          claimName: n8n-data # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: n8n
spec:
  type: NodePort
  ports:
  - port: 5678
    targetPort: 30200
    protocol: TCP
  selector:
    app: n8n Now, let's parameterize these using the go-template language to convert them to templates. Helm will fetch the appropriate values from the file to generate the manifest that will be deployed on K8S. values.yaml # my-n8n/templates/pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Values.persistence.claimName }}
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi # Adjust the size as per your requirement # my-n8n/templates/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
      - name: n8n
        image: {{ printf "%s:%s" .Values.image.repository .Values.image.tag  }}
        ports:
        {{- range .Values.containerPorts }}        
        - name: {{ .name }}
          containerPort: {{ .port }}
        {{- end }}        
        volumeMounts:
        {{- range .Values.volumeMounts }}
        - name: {{ .name }}
          mountPath: {{ .mountPath }}
        {{- end }}
      volumes:
      {{- range .Values.volumes }}      
      - name: {{ .name }}
        persistentVolumeClaim:
          claimName: {{ $.Values.persistence.claimName }}
      {{- end }} # my-n8n/templates/service.yaml

apiVersion: v1
kind: Service
metadata:
  name: {{ printf "%s-%s" .Release.Name .Chart.Name  }}
spec:
  type: {{ .Values.service.type }}
  ports:
  - port: 5678
    targetPort: 5678
    nodePort: {{ .Values.service.port }}    
    protocol: TCP
  selector:
    app: n8n Ensure that you're in the directory that contains the chart then run the linter. my-n8n helm lint my-n8n Install the chart. helm install my-n8n ./my-n8n Wait until the deployment is complete, you can continually check using the following command. kubectl get all After the status has changed to running, you should be able to access it in your browser from: http://localhost:2223 Recap Great effort! You just learned how to create and configure a Helm chart and then deploy it to a Kubernetes cluster!

Helm 101: How to Create Helm Charts

When deploying multiple resources to Kubernetes, it is often challenging to keep track of all the resources, image tags, and environment variables distributed across multiple manifest files. To address this issue, manifest templating tools such as Kustomize and Helm exist, simplifying large, complex manifest files to templates with customization available through values.yaml. This provides flexibility with a single template across multiple environments (e.g., QA, staging, production), with changes configured via the values.yaml file. Additionally, it offers ease-of-use for end-users to deploy into any new environment with just a single command. However, solving one set of problems often introduces new challenges. Creating individual Helm charts can become difficult to manage as applications increase. It becomes essential to track changes across all Helm charts used by an organization, consuming significant engineering hours. Using community charts poses the challenge of pulling and customizing new charts, maintaining separate copies in the Helm repository, and consuming considerable time to pull and run these charts. Just as we've created a Helm chart for each application, bundling all required resources into a single chart, it would be advantageous to bundle all these micro-services into a single chart. Kubernetes Introducing Helm Sub-charts: Helm sub-charts are like mini-charts residing inside a larger Helm chart, akin to different players in your favorite video game. It's Helm's way of implementing inheritance. Charts can have dependencies, called , each with its values and templates. subcharts Why Do We Need Sub-charts? Sub-charts help break down large applications into more manageable parts, akin to splitting your favorite game into different levels. Breaking Down Big Stuff: Sub-charts can be reused in different projects, similar to using a favorite weapon or skill in various game levels. Reuse the Good Stuff: Sub-charts enable working on different parts of an app without accidentally affecting other parts, similar to cooking different dishes in separate pots. Keeping Things Separate: Things to Consider When Creating Helm Sub-charts: Before creating sub-charts, consider the following: A sub-chart is considered "stand-alone," meaning it can never explicitly depend on its parent chart. Consequently, a sub-chart cannot access the values of its parent, but a parent chart can override values for sub-charts. Helm sub-charts work well when the charts you want to deploy are used in combination with each other but are not directly dependent on each other's resources. Helm sub-charts work well when the charts you want to deploy are used in combination with each other but are not directly dependent on each other's resources. When a Helm chart has multiple Helm sub-charts, specifying the specific order can be challenging. Let's Build Some Helm Sub-charts: To create a master Helm with sub-charts, consider a master Helm chart example deploying Nginx and PostgreSQL. The folder structure is as follows: To create Helm sub-charts within the master Helm chart, add the following to the values.yaml file, describing the name of the Helm charts along with their versions and repositories. apiVersion: v2
name: my-master-chart
description: A Helm chart to deploy Nginx and PostgreSQL
version: 0.1.0
dependencies:
  - name: nginx
    version: 15.4.3
    repository: https://charts.bitnami.com/bitnami
  - name: postgresql
    version: 13.2.16
    repository: https://charts.bitnami.com/bitnami After adding the above to the values, run the following command to pull and add these dependencies to the charts folder. helm dependency update Once pulled, the folder structure should have .tgz files in the charts folder. To untar the .tgz file, use the command: tar -zxvf nginx-15.4.3.tgz After extraction, your file structure would resemble the one below: Just as we can manipulate inputs from the values file in individual Helm charts, we can use the global values.yaml file to manipulate the values of each of these Helm charts. By doing so, we can use the base Helm charts as templates and make all modifications from the global values.yaml file. This reduces complexity and simplifies the management of different input values in various Helm charts. Consider the following example to illustrate the use case. The values for Nginx mention the image tag, and PostgreSQL mentions the image tag along with the port number at which the PostgreSQL deployment runs. Here are the default values passed in the Nginx and PostgreSQL values.yaml files: Now, change the values in the master values.yaml file at the top level. Change the Nginx image from to and the PostgreSQL image from to . Also, change the PostgreSQL default port from to . 1.25.3-debian-11-r1 1.24.0-debian-11-r153 16.1.0-debian-11-r9 15.5.0-debian-11-r9 5432 5111 The values for both Nginx and images have changed, and the PostgreSQL port has been updated. PostgreSQL Liked my content? Feel free to reach out to my for interesting content and productive discussions. LinkedIn

Helm Sub-Charts Demystified: A Guide to Efficient Deployments

DevOps has generated so many opportunities for software organizations to improve their operations. Software development best practices have given rise to many platforms and tools that make it easier to deploy software quickly. Kubernetes and Helm can do so much together to help developers deploy software with less effort. Kubernetes is the most popular open-source platform for running container-based apps in the enterprise. In fact, many organizations aim to run all their production deployments on Kubernetes. These are exciting times for those in the Kubernetes community because we’re seeing more and more users leverage its extended capabilities for even deeper operational insight and control. One such capability is the use of Helm to package and deploy individual Kubernetes applications. What is Helm? Image credit: IBM Developer Helm is a popular open-source tool for managing Kubernetes clusters. It simplifies the process of installing, updating, and removing applications on your cluster by packaging them as “charts.” These charts are then installed on your cluster with one command. Helm relies on the concept of charts. A chart is an archive of all the resource definitions that are needed to deploy an application to Kubernetes, including the configuration files and scripts needed for deployment. To get started with Helm, you need to create a chart for your application or find one online that suits your needs. Below, we will go through a brief tutorial on how to create a simple Helm chart. You can quickly install software onto your Kubernetes cluster, and the public Helm charts are readily available in ArtifactHub. Prerequisites for this tutorial: Install Helm from the official Helm website Install or (with Kubernetes enabled) Rancher Desktop Docker Desktop Sign up for the to deploy to any Kubernetes environment Harness Software Delivery Platform Tutorial: Create a Simple Helm Chart Use your terminal to create a new directory to store our code: mkdir helm-exampl   ecd helm-example Create a new chart and give it an appropriate name: This creates a simple chart that will deploy an Nginx pod. helm create new-chart You should see the following output on your terminal: Creating new-chart Change the directory into the folder of the new chart that we just created: cd new-chart With command, you can see the contents of the new chart folder: ls Chart.yaml   charts   templates   values.yaml Keeping everything as it is, we will deploy our first chart: helm install new-chart ./helm-example/new-chart Note: Use this command outside of your directory to set the path correctly as shown. ‍With the command , you can see your deployed helm chart: helm ls ‍ You can also confirm that the pods are up and running with the command : kubectl get pods In this example, we are using Rancher Desktop so it is easy to access the deployed chart. You can download from the official website. Rancher Desktop And when I check my localhost:56253, I can see the Nginx container running. As stated previously, if you are using Rancher Desktop, it’s very easy to access your newly deployed app. ‍ Next, you can package this chart to share it with anyone with the command: helm package ./new-chart Deploying with Harness CD It is very easy to use Helm charts and do deployments with Harness CD. Further in this tutorial, you’ll see how to deploy a publicly available Docker image to your Kubernetes cluster using Helm charts and a rolling deployment strategy through Harness CD. Assuming you have a Kubernetes cluster set up with 3 nodes, 4vCPU machine type, 16GB memory, and 100GB disk. Head to and sign up if this is your first time using the Harness platform. Once you log in, switch to the NextGen mode, which is the newest, most advanced version. Harness Create a project with any name you want, select continuous delivery and start creating the pipeline to deploy a MongoDB chart. Every stage is self-explanatory:  Add the required fields. Then specify the service, select deployment type as Kubernetes, add the manifest details as Helm chart, and then create a new HTTP Helm repo connector. Note that I have already created the HTTP Helm Repo Connector in this example. You have to create a new one if you are new to this process. Once you click on + HTTP Helm Repo Connector, it will ask for a few details and you need to provide them. Provide Helm Repository URL as as we are using the official chart. https://charts.bitnami.com/bitnami In the infrastructure setup, give cluster details: In the execution step, select the Rolling deployment strategy: Once everything is set up, save the pipeline and run it. ‍ You should see a successful deployment of the MongoDB image. Confirm the deployment by going to your cluster setup. I have my cluster created on GCP and I can confirm that the MongoDB image has been successfully deployed through the Helm chart. You have successfully learned how to create a Helm chart and deploy it with the help of Congratulations! Harness. Also published here.

Creating and Deploying a Simple Helm Chart

If you are new to Helm, you should absolutely go through the first part of this tutorial, “ .” In Part I, we introduced Helm, and we went through its installation steps. Everything you need to know about Helm – Part I In this second part, we are going to learn about Helm versions (v2 vs. v3), most common commands, and most importantly, we are going to see a practical example of how to use it. Helm Versions The current version of Helm is Helm3. This was not simply a run-of-the-mill version upgrade – Helm3 introduced major internal differences regarding Helm’s internal workings and how Kubernetes packages were managed. The biggest change from the previous version (Helm2) was the removal of Tiller, the server component. The reasons for this are explained in the Helm FAQ docs, in the section named ‘Removal of Tiller.’ Some other significant changes in Helm3 are below. Again, they are explained in detail in the FAQ documentation: Improved upgrade strategy Release names now restricted to the namespace ‘Secrets’ used as the default storage driver Ability to validate chart values with JSON Consolidation of requirements.yaml into chart.yaml Automatic creation of namespaces Helm Commands Let’s now take a look at the most common Helm commands and their usage. The is too long to list here, but you can and should go through it: : this is the most common command used for installing new charts. The basic syntax to install a chart from a repo is: full Helm command list Helm install helm install <name> <chart> [flags] For example, to install nginx v1.16: helm install mynginx-116 /myrepos/nginx-v116 When you use this chart reference with a repo prefix (./myrepos/nginx/v116’), Helm will look in the local configuration for a chart repo named “myrepos’, and then look for a chart named ‘nginx’ in that repository. You can also download directly from an absolute URL: helm install mynginx-116
https://nginx.org/download/nginx-1.16.1.tar.gz You may also need to check your to make sure the repo you want to install from is part of your list. Use this command: list of repos helm repo list [flags] And if the repo you want is not in your list, you can with: add it helm repo add [repo-name] [URL] [flags] Example: helm repo add nginx-v116 https://nginx.org/download/nginx-1.16.1.tar.gz If you need to your repos: update helm repo update [flags] You should also familiarize yourself with the command. This creates a new chart structure (the directories and files we listed above) with the given name. The basic syntax is: Helm create helm create NAME [flags] And if you want to a chart’s contents: display helm show all chart [chart-name] If you need to to a previous release: roll back helm rollback <RELEASE> [REVISION] [flags] To a specific release: uninstall helm uninstall RELEASE_NAME [flags] Note: You can use the ‘–dry-run’ flag to see which releases will be uninstalled without actually uninstalling them. Sample Installation Using Helm Let’s now go through a sample installation and deployment of Nginx using Helm, so you can get an idea of how all these commands are used. We will use Ubuntu for this exercise and assume you already have Kubernetes. If not, first read . this article Navigate to the directory where you installed Helm: cd/path/to/helm First, we want to confirm if our repo list contains ‘nginx’: helm search repo nginx Depending on the results (check against the nginx source), you may want to add the latest repo: helm repo add nginx-stable https://helm.nginx.com/stable And then it’s always a good idea to update your repo list after adding or deleting repos: helm repo update Next, install the nginx chart (package): helm install my-release nginx-stable/nginx-ingress Or if nginx is already installed and you only need to upgrade the version: helm upgrade my-release nginx-stable/nginx-ingress And finally, if you ever need to uninstall this nginx version: helm uninstall my-release Useful Resources to Learn Helm Probably the most important resource to start Helm is the official documentation. As it’s described by the creators and maintainers of Helm, Helm has a lot of documentation. A high-level overview of how it’s organized will help you know where to look for certain things: take you by the hand through a series of steps to create your first Helm chart. Start here if you’re new to Helm. Tutorials discuss key topics and concepts at a fairly high level and provide useful background information and explanation. Topic guides discuss topics centered around Helm’s community. Start here if you want to learn more about the development process of Helm itself and how you can contribute. Community Guides are recipes. They guide you through the steps involved in addressing key problems and use-cases. They are more advanced than tutorials and assume some knowledge of how Helm works. s How-to guide Conclusion You hopefully now have a pretty good idea of Helm – what it does, why we use it, and where it fits into the Kubernetes ecosystem (think of Helm as the ‘apt’ or ‘rpm’ equivalent for Kubernetes). And you also have a good idea of some Helm sample commands and how to install and deploy a simple app using Helm. Also Published At: https://cloudplex.io/tutorial/everything-you-need-to-know-about-helm-part-ii/ Asad Faizi Founder CEO , Inc CloudPlex.io asad@cloudplex.io

Helm — Everything You Need to Know Part II

As we have seen, Kubernetes is a powerful and popular container-orchestration system. But as we’ve also seen, migrating to and setting up your applications on Kubernetes can be a complex, daunting task. Setting up a single application can involve creating multiple interdependent Kubernetes components – pods, services, deployments, and replica sets, and each component requires you to write a detailed YAML manifest file. Enter Helm. Just like for Ubuntu or and for Red Hat, Helm is a package manager for Kubernetes that allows you as a developer or an admin to more easily package, configure, and deploy applications and services into your Kubernetes clusters. apt yum rpm Helm is now an official Kubernetes project and is part of the Cloud Native Computing Foundation, a non-profit, open-source software foundation that promotes the adoption of cloud-native computing. Helm Tasks and Components Like any good package manager, Helm does all the following tasks: Fetches applications and software packages from repositories Installs apps and packages in the Kubernetes cluster Automatically installs those apps’ dependencies Upgrades the apps and their dependencies Helm does all these using the following components: a command line tool that offers a user interface to all Helm functionality. Helm: (only in the previous version Helm2, now deprecated in Helm3): the server component that ran on the Kubernetes cluster. Tiller Tiller listened for commands from Helm then executed the configuration/ upgrade/ deployment tasks on the cluster. But from Helm3, all this functionality is now handled directly by the tool. Helm the Helm packaging format. We will dig into Charts in more detail in the next section Charts: the official repo for Helm charts. It is located in Charts Repo: https://github.com/helm/charts Helm Charts Packages in Helm are called . A chart consists of a few YAML configuration files and some templates that are then changed into Kubernetes manifest files. The basic directory structure of a Helm chart is below, and you are advised to stick to this structure unless you are a pro and have good reasons for deviating from it: charts chart-name/
  charts/
  crds/
  templates/
  chart.yaml
  LICENSE
  README.md
  requirements.yaml
  values.yaml These files and directories are explained below: this is the ‘root’ directory of the chart/ package within Helm (not within the OS). All the other directories and files are located inside this root. It’s name is usually simply the name of the software or application to be installed, e.g. ‘wordpress/’ or ‘nginx/’ or ‘postgres/’ chart-name/: this directory is typically used to store chart dependencies that are managed manually. However, it is advisable to rely more on the requirements.yaml to define and dynamically link dependencies. charts/: this directory contains any Custom Resource Definitions crds/: this directory contains template files that can be combined with configuration values taken from values.yaml and/ or the Helm command line. When Helm evaluates a chart, it will send all of the files in the templates/ directory to the template rendering engine. It then collects the results of those templates and sends them on to Kubernetes to create manifest files. templates/: a YAML file with metadata about the chart – chart name and version, maintainer information, the originating website, search keywords, etc. Read more about the chart.yaml’s contents and structure in the official documentation. chart.yaml: (optional) a plain-text license file for the chart. LICENSE: (optional) a readme file with useful information for users README.md a YAML file that lists the chart’s dependencies. requirements.yaml: : a YAML file containing the chart’s default configuration values values.yaml Note that ‘charts/’, ‘crds/’ and ‘templates/’ are reserved keywords within Helm. You cannot give these names to your objects. Another important concept in Helm is release. A release is a single instance of a chart running in a Kubernetes cluster. You see, one chart (package) can be installed multiple times in the same cluster. And each time it is installed, a new release is created. So why would you install the same chart multiple times? The most common reason and use case is because you need to utilize different versions of the same software or application, for example, if you need to test your webserver on two nginx versions – 1.16 and 1.17. Helm Installation Helm is available for the 3 major OS’s – Linux, Windows and MacOS. There are 2 different ways to install Helm. We will only list these 2 ways here, since they are explained in detail in the official documentation guide: From the Helm Project, either as a binary release or as a script. Using package managers such as apt for Ubuntu, Chocolatey for Windows, or Homebrew for MacOS That said, the most common installation method is via a package manager. The quick steps for installation on Ubuntu using apt are given below. The apt package for Helm can be found here, and the commands for installation are: curl https://baltocdn.com/helm/signing.asc | sudo apt-key add -
sudo apt-get install apt-transport-https --yes
echo "deb https://baltocdn.com/helm/stable/debian/ all main" | 
sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm Conclusion If you are using Kubernetes, you will certainly need the power of Helm when your project grows and when you’ll need to manage different configurations with rules and advanced features. This first part is the introduction to using Helm, as we introduced the tool and how to install it.
In the second part ( ), we are going to dive deep into more concepts like Helm versions and commands. We will also go through a sample installation and deployment of Nginx using Helm, so you can get an idea of how all these commands are used. We will use Ubuntu for this exercise and assume you already have Kubernetes and Helm3 installed. Everything you need to know about Helm – Part II Asad Faizi Founder CEO , Inc CloudPlex.io asad@cloudplex.io

Everything you need to know about Helm – Part I

Whether you love it or hate it, Helm is a ubiquitous tool for managing Kubernetes applications. You can use it in many different ways which is great, but can also be overwhelming. We’ve noticed that a couple of questions keep popping up: Do you keep them with the app files or use a chart repository? Where do you put your Helm charts? Do you use one shared chart or maintain a chart for each service? How do you divide up your Helm charts? I’m going to try and address these questions based on our experience with the startups in our portfolio but I also draw on the perspectives of larger organizations too. Here are the options that I’ll be outlining: Using a to store one big chart repository shared chart Using a to store many charts. chart repository service-specific Using which are stored in the same repository as the (spoiler alert: we prefer this one). service-specific charts service itself I’ll then cover factors such as dependency variance and team structure that you should consider when deciding on one of these options. Option 1: Maintain one big shared chart in a chart repository In one of our projects, we started out with a large chart that was used to deploy multiple services. It was stored in and maintained by the person responsible for the deployment infrastructure. ChartMuseum A shared chart can save a lot of hassle if your services are very similar in nature. For example, take this scenario that Helm maintainer Josh Dolitsky described at KubeCon 2019: I was recently working on a project and there [were] nine microservices … at about number two or three, I realized like they were all pretty much the same HTTP listening service. So instead I .. decided let’s build a single helm chart that works exactly the same for every service and so we use a single helm chart to deploy nine different services doing a different configuration for each — just setting a new docker tag for that specific service. In this case, it makes sense to store the Helm chart in a chart repository such as ChartMuseum. Only the values would need to be kept in these service-specific repositories. Option 2: Maintain several service-specific charts in a chart repository Service-specific charts have the advantage that you can make a change to one service without worrying about breaking something for another service. But they can cause duplicated work. If you’re updating a common configuration, you’ll have to make the same change in each of your charts. Whether you need to keep them in a chart repository is another question. If the charts are service-specific anyway, then there’s no strong architectural argument for storing them together. However, often this is easier if you have a dedicated person or team maintaining all the charts. For example, I worked with one DevOps engineer who maintained charts for 15 different microservices in a central chart repository. It was easier for him to update them all in one place rather than submitting pull requests to 15 different repositories. The developers themselves knew how to update the charts and sometimes did so, but he preferred to handle the resource-related settings such as pod disruption budgets. Option 3: Maintain service-specific charts in the same repositories as the services themselves Service-specific charts are a good choice for microservice-based applications where the services have significant differences. This pattern works better when you keep each chart in the same repository as the service code. If you store the Helm chart in the service repository, it’s easier to continuously deploy the service independently from other projects. And you can commit your chart updates (such as adding a new variable) together with your changes to the application logic — making it simpler to identify and revert breaking changes. However, the advantages of this option depend on how many microservices you maintain. If you‘re getting into double digits (like the scenario I described in the previous section) this option might be more of a hindrance than a help. This is especially true if you’re dealing with very homogenous services like in Josh Dolitsky’s example. What to take into account when deciding on an option There are generally two general dimensions to take into account: How different are the dependencies for each service? What is the risk that a change to one service will break another? How do you reproduce the conditions of a specific development? Dependencies and reproducibility: : do you have small autonomous teams that are responsible for each service? Do you have developers who have some knowledge of DevOps? How prevalent is “DevOps Culture” in your team? Team structure Dependencies and Reproducibility If you maintain your charts separately from your application, they will be versioned distinctly from one another. If you have a problem with a deployment and need to reproduce the conditions that caused it, you will need to identify: a) the service version, and b) chart version used to deploy it. One might be tempted to take a shortcut and always test service x.x.x with chart “latest”, but this is a terrible idea. You will never reproduce the exact conditions that caused an issue. So what if you often have releases that require a change to the chart? Shouldn’t you test those changes together? Consider this illustrated scenario where many developers need to create branched versions of the same shared chart: Each service branch needs to use the correct chart branch The developers (Edeltraud and Eberhardt) are both working on different feature branches and want to test their changes in a dev environment along with the chart changes — so they need to branch the charts too. In the meantime, the DevOps engineer, Duane, is updating some common components in his own branch of the shared chart. If no one branches their chart changes, they risk breaking the deployment of another service. We encountered exactly this problem not so long ago. The chart maintainer updated the shared chart with a new conditional block. The statement checked to see if a new variable “foo” was set to “enabled”. However, the variable “foo” wasn’t yet defined in the values files for all services. The deployment broke for the services that were missing the variable — unfortunately, there was no default fallback behaviour defined in the chart at the time. It’s much easier to test for these kinds of issues if the chart and the code are in the same repo and can be tested in the same branch. We do this even when it seems like overkill at the beginning. We’ve worked on services that have few dependencies: For each service, the Helm chart just deploys one main container with a specific Docker tag. The image name and docker tag are passed in through variables. Despite this, we still avoided using a shared chart — instead opting to put separate charts in each service repository. Primarily this was because we were only dealing with four services. But our developers also prefer to own all configurations that affect CI/CD. This is not always the case however, so it’s a good time to examine the other dimension: Team structure The issue of chart maintenance also depends on who owns the deployment process. There’s a great article from another Helm maintainer, Matt Farina, where he talks about . He elucidates the three main roles who have to deal with complexity in Kubernetes. For the sake of clarity, I’m going to paraphrase him and describe the roles as follows: the complexity that Helm is trying to solve these people build the service, add features, and fix bugs. App Developers — these people are in charge of pushing the application put into the world. Hopefully, there’s decent automation that deploys the app for them, but they know how it works and can change it if they need to. Deployers — these people maintain the Kubernetes environment that the deployers deploy . They’re specialists in managing computational resources and try to minimize any service downtime. System Engineers — into The first and third roles match up to normal job titles that you might find in the wild. The “deployer” role is a little more ambiguous. This role is often taken over by someone who is also one of the other two roles — and this influences how you’ll manage your Helm charts. We’ve learned this through experience. DevOps in early-stage startups As mentioned, we’re in the business of providing operational support to startups that often have to scale up at a rapid pace. We’ve seen a lot of “unconventional” setups and divisions of labour. In the early stages, app developers might wear different hats and some even help out with sysadmin tasks such as setting up the printer or configuring the office VPN. They’ll try their best to get their heads around the other two roles because there isn’t anyone else to help them (until we get involved). Once they’ve figured out Helm, most app developers will put their charts in the easiest place for them to deal with — i.e. the same repo that they maintain. DevOps in large organizations You might work in a larger, structured team, you might have read the previous section with varying degrees of horror. In this case, you probably have your own DevOps engineer or even an entire DevOps department. And that person or team often feels responsible for the “Deployer” role too. Chances are, they’ll favour a more centralized approach such as storing all charts in a chart repository like ChartMuseum. There is less willingness to let app developers get too involved with Helm charts (often for good reason). For example, I recently watched an old tech talk called “ ” by VMWare systems engineer Amy Chen. In her intro statement, she said: Building Helm Charts From the Ground Up “In infrastructure, your main goal is to always prepare for failure right? there is no trust — in the sense of like I don’t really want to trust my app developers and I don’t really need to trust my app developers” This is understandable. You don’t want app developers messing with settings like CPU and memory limits, or pod disruption budgets. But the whole concept of “DevOps culture” evolved specifically to improve the sometimes distant relationship between infrastructure maintainers and developers. Applying DevOps culture Atlassian (owner of JIRA and Trello) published a “ ” which defines DevOps culture like this: Team Playbook ‘DevOps culture is all about a shared understanding between developers and operations, and sharing responsibility for the software they build. That means increasing transparency, communication, and collaboration across development, IT/operations, and “the business”.’ If you apply this practically to Helm chart maintenance and infrastructure configuration in general, you would put much of the responsibility in the hands of application developers. They also assume the role of “Deployer” and change the configuration in repositories that they own. System engineers can still centralize the settings that they maintain exclusively. For example, some teams also maintain a central infrastructure repo that holds common resources such Terraform configurations or Helm files that are needed to bootstrap new projects (e.g. for setting up the ingress controller and cert manager). Helm 3 also supports so-called “ ” which only be deployed as part of another chart. This makes it easier to separate responsibility for common and service-specific changes. library charts Even when charts live in the service repos, system engineers can still act as gatekeepers for important changes. For example, you can use a GitHub to ensure that system engineers are added as reviewers for any changes to the chart directory if your repo. CODEOWNERS file If system engineers need to proactively make changes that aren’t related to the application development, they can direct developers to make changes for them and explain why the changes are essential. Consider the previous illustration updated to reflect this scenario: The developers get to learn more about the infrastructure and how those changes affect their services. The Guidelines If there’s a simple rule of thumb to go by it’s this: . look at option #3 first Try to maintain a Helm chart for each service in the service repository. Or at least consider the hybrid approach that I’ve described previously. If you have tens of services that are all very similar, then a shared chart is the better bet. Just bear in mind that you’ll have to maintain it in a central repo. This increases the risk of an accidental coupling which could break a service deployment. Heightened risk means you’ll be more cautious about deploying, which in turn, means that you’ll deploy less often. Even if you do have service-specific charts, you might need to store them centrally because you don’t have the people or expertise to look after them in a distributed way. Or perhaps your organization requires a clear separation of responsibility between “deployer” and “application developer”. Regardless of what you decide to do — I hope I’ve clarified what you need to take into account when making your final call. Being a “deployer” ain't easy, especially when it’s not your day job. A Disclosure Note On The Author and Project A Merlin blogs about developer innovation and new technologies at Project A — a venture capital investor focusing on early-stage startups. Project A provides operational support to its portfolio companies, including developer expertise. As part of the IT team, he covers the highlights of Project A’s work helping startups to evolve into thriving success stories.

How Do You Manage Helm Charts?

So Helm3 finally has been released. Everybody saying goodbye to Tiller but, that’s not the only change in Helm3. Let’s discuss what else has changed. Adios Tiller Yes, Tiller has been removed and that’s a good thing but to understand why we need to get a bit of background. Tiller was a server-side (running on Kubernetes cluster) component of Helm and its main purpose was to make possible for multiple different operators to work with the same set of releases. When Helm 2 was developed, Kubernetes did not yet have role-based access control (RBAC) therefore to achieve mentioned goal, Helm had to take care of that itself. It had to keep track of who and where is allowed to installs what. This complexity isn’t needed anymore as from Kubernetes 1.6 RBAC is enabled by default, so there is no need for Helm to do the same job which can be done natively by Kubernetes and that’s why in Helm 3 tiller was removed completely. Tiller was also used as a central hub for Helm release information and for maintaining the Helm state. In Helm 3 the same information are fetched directly from Kubernetes API Server and Charts are rendered client-side which makes Helm 3 more “native” and simpler for Kubernetes. With Tiller gone, also the security model for Helm has been simplified (with RBAC enabled locking down Tiller for use in a production scenario was quite difficult to manage). Helm permissions are now simply evaluated using kubeconfig file. Cluster administrators can, therefore, restrict user permissions at whatever level they want while releases are still recorded in-cluster, and the rest of Helm functionality remains the same. Ok, let’s forget Tiller. What else has changed? As I mentioned at the beginning — removal of Tiller was a big thing, but not the only major change. Let’s take a look at other: Three-way strategic merge patch Helm 2 used a two-way strategic merge patch. It means that when you wanted to perform any operation, it compared the most recent manifest chart against the proposed chart manifest. It checked for the differences between these two charts to determine what changes needed to be applied to the resources in Kubernetes. helm Sounds pretty smart, right? The problem is that if changes were applied to the cluster “manually” (for example via ), they were not considered. This resulted in resources being unable to roll back to its previous state because Helm2 only checked the last applied chart’s manifest as its current state, and since there were no changes in the chart’s state (we only changed live state on the cluster) Helm simply did not see the need for performing a rollback. kubectl edit And that’s were three-way strategic merge patch comes to the rescue. How does Helm3 do that? It simply takes the live state into consideration too (thus 3-way instead of 2-way since now we have the old manifest, its live state, and the new manifest). For example, let’s say you deployed an application with: helm install very_important_app ./very_important_app and for example, this application Chart was set to have 3 replica sets. Now, if someone by mistake will perform or: kubectl edit kubectl scale -replicas=0 deployment/very_important_app and then someone from your team will realise that for some mysterious reason is down and will try to execute: very_important_app helm rollback very_important_app In Helm 2, it would generate a patch, comparing the old manifest against the new manifest. Because this is a rollback and someone only changed live state(so the manifest did not change) Helm would determine that there is nothing to rollback because there is no difference between the old manifest and the new manifest (both expect to have 3 replicas). Rollback is not performed then and the replica count continues to stay at zero. You start panicking now… In Helm 3 on the other hand, the patch is generated using the old manifest, the live state, and the new manifest. Helm recognizes that the old state was at three, the live state is at zero and so it determines that the new manifest wishes change it back to three, so it generates a patch to fix that. You stop panicking now… A similar process happens with Helm 3 when performing upgrades. Since it takes the live state into account now, then for example if some controller-based application (or something like a service-mesh) inject anything into kubernetes object which was deployed via Helm — it will get removed during process using Helm2. helm upgrade Helm 3 doesn’t do that —again, it takes the live state into consideration. Let’s assume that we want to install for example Istio on our cluster. Istio will start injecting sidecar containers into any deployment, so assuming you deployed something with Helm and your deployment consist of: containers: - name: server image: my_app:2.0.0 Then you installed Istio so your container definition looks like this now instead: containers: - name: server image: my_app:2.0.0 - name: istio-sidecar image: istio-sidecar-proxy:1.0.0 And if you now execute upgrade process with Helm2, you’ll end up with this: containers: - name: server image: my_app:2.1.0 Istio sidecar gets removed since it wasn’t in the Chart. Helm 3 however, generates a patch of the containers object between the old manifest, the live state, and the new manifest. It notices that the new manifest changes the image tag to 2.1.0, but live state contains something extra. So upgrade with Helm 3 will work as you would expect: containers: - name: server image: my_app:2.1.0 - name: istio-sidecar image: istio-sidecar-proxy:1.0.0 Three-way strategic merge patch makes Helming way more predictable and safer. You don’t have to worry anymore if something gets bananas. Secrets as the default storage driver Helm 2 used ConfigMaps to store release information. In Helm 3, Secrets are used instead (with a secret type of ) as the default storage driver. This brings a few advantages and has greatly simplified the functionality of Helm. To get (and apply) the config, Helm2 had to perform quite some operations as config itself was stored encrypted and archived in one of the keys or ConfigMap. helm.sh/release Helm3 stores the config directly in Secret so instead of performing multiple operations to get it, it can simply pull out the secret, decrypt and apply. Another advantage is that release name does not have to be unique across the cluster anymore. Secrets containing releases are stored in the namespaces where the release was installed. So you can have multiple releases with the same name as soon as they are in different namespaces. JSON Schema Chart Validation A JSON Schema validation can now be forced upon chart values. With that functionality, you can ensure that values provided by the user follow the schema created by the chart maintainer. This creates more possibilities for OPS vs DEV cooperation (OPS team can give more freedom to DEVs) and provides better error reporting when the user tries to use an incorrect set of values for a chart. Release name is now required In Helm 2, if no name was provided, a random name would be generated. Helm 3 will throw an error if no name is provided with helm install (eventually you can use flag if you want to still use random names) — generate-name Helm serve removed Not many people used which was used to run a local Chart Repository on your machine for development purposes but for those who did — it’s removed now. Although you can still use it as a plugin instead. helm serve ( ) Namespaces are not created automatically anymore When creating a release in a namespace that does not exist, Helm 2 would create it automatically. Helm 3 follows the behaviour of other Kubernetes tooling and returns an error if the namespace does not exist. That’s the most important changes in Helm, there are still a few more. If you are interested check official Helm . In Part 2 I will show you how to migrate from Helm2 to Helm3. docs

Helm2 vs Helm3: Part 1

If Kubernetes is the pilot that steers the ship, then Helm Charts are the navigational maps that guide the journey correctly. We have seen this happening over the years in the world of software development, one tool comes with an idea, serves the purpose, and becomes obsolete in some years, and then one more tool gets introduced that replaces the old approach, and this journey continues. Similarly, today is the era where Kubernetes is looked upon as the king of container orchestration. Backed by Google, Kubernetes has grown leaps and bounds by increasing its reach and community to every part of the world. But, as we all know, with high power and popularity, Kubernetes comes with some complexity. To mitigate this complexity that Kubernetes poses, we have Helm. What is Helm? How does it work with Kubernetes? We will discuss all this further in the article. What is Kubernetes & how it works? is an open-source container orchestration tool that is backed by Google and is becoming too popular in the software industry because of the benefits that it provides. Kubernetes Think, for example, you are building an application using containers, you go ahead and deploy the application, the application becomes too popular and to keep up with the increased popularity, you need to scale the resources and now, instead of a few containers, you have to deal with hundreds of containers. That becomes a mess, you need a simple way to automate the process, and this is where Kubernetes comes to the rescue. Image credits: Knoldus .Inc In Kubernetes, there is a master node and multiple worker nodes, each worker node can handle multiple pods. Pods are just a bunch of containers clustered together as a working unit. You can start designing your applications using pods. Once your pods are ready, you can specify pod definitions to the master node, and how many you want to deploy. From this point, Kubernetes is in control. It takes the pods and deploys them to the worker nods. If a worker node goes down, Kubernetes starts new pods on a functioning worker node. This makes the process of managing the containers easy and simple. It makes it easy to build and add more features and improving the application to attain greater customer satisfaction. Know more in this video in detail: What is Kubernetes Kubernetes was originally designed by Google and then it was later donated to the (CNCF). Cloud Native Computing Foundation Why is Kubernetes so powerful? Horizontal scaling Self-healing Load balancing and service discovery Automated rollouts and rollbacks Storage orchestration Batch execution Configuration management What is Helm & how it works? is a tool for Kubernetes that helps you install and manage applications. In terms of architecture, Helm has two sides, there is a client-side, which is the Helm command-line tool (helm CLI), and there is also a service side, which is called Tiller. Helm Image credits: On Slideshare by Codefresh The helm CLI is what you execute and run in your local command-line environment. It uses a templating engine to generate Kubernetes YAML from some source templates that you set up in Helm. Once the YAML has been generated, it then sends those requests to the Tiller that’s running on your Kubernetes cluster. Tiller then executes updates inside your Kubernetes cluster to make sure it is up to date with what you needed based on the chart, and the tiller will make sure that gets released and will be added to the helm history so that you can rollback to it in the future. Helm terminologies: Image credits: DigitalOcean Packaged Kubernetes (k8s) resources (metadata) Chart: Parametrize and support multiple environments Values: Registry of consumable charts, enables to share and reuse configurations Chart Repository: A deployed instance of a chart Release: Templates are Kubernetes manifest files that describe the resources you want to have on the cluster. They help us control operations during deployment. To deploy your applications using helm, you need to package your applications into a chart (directory with some files in a specific structure) Templates: The top-level directory is the name of your chart and, below that, you have chart.yaml, which stores metadata and version information for your chart. There is values.yaml to store default configuration values. requirements.yaml lets you specify dependencies like MongoDB or Postgres, and then there is Charts subdirectory where dependencies and packages are stored. Finally, there is templates directory, this is where we store source templates that are fed into the helm templating engine. Let’s not get into the technical details so we can stick to our topic. Helm and Kubernetes to help you deploy with ease The software firms are moving away from a monolithic architectural pattern to the microservices pattern, where simple software units work individually to perform a specific function. Different pieces are loosely copulated and are made to communicate with each other without breaking anything. Adopting to microservices boosts knowledge across different teams to work on a single piece of application with full responsibility. The microservices are essential; they create ease to manage, update, and scale-up applications individually, unlike monolithic applications. Helm is a game-changer here, it has altered the way developers define, store, and manage the server-side applications. Helm, the package manager, simplifies the management of applications, and the implementation of microservices. Helm wraps the microservices and all the dependencies together. Helm with Kubernetes is the most popular choice for managing containers on the cloud. The automatic deployment, ease of use, stability, and portability are Kubernetes key features. It includes multiple storage APIs, health check of container, systematic upgrades, and manual or automatic scaling. Kubernetes solves a lot of problems, Makes sure all your containers are up and running Helps in service discovery Resource isolation and utilization efficiencies Prevent’s vendor lock-in problems Since everything is declarative in YALM, Devs can do Ops as well Kubernetes has big support from the community to help you solve your tech problems …..it comes with its own complex problems. Kubernetes is powerful but Kubernetes can be highly overwhelming and might become complex with all the objects that you need to handle - objects, config maps, services, pods, persistent volumes, and the list goes on. All this becomes too complex when you multiply all these objects with the number of releases that you need to manage. How do you manage all these complex activities? There comes Helm to the rescue. Helm helps you package all of that complexity into one simple application and what you can configure. Functions of Helm: Install software Automatically install software dependencies Upgrade software Configure software deployment Fetch packages from repositories Helm makes it easy to start using Kubernetes with real applications. has become the basic toolset for any DevOps specialist. This guide about offers some best practices to structure and specify your Helm charts that will help K8s deliver your container applications smoothly. Helm provides several CI/CD pipeline integration hooks, we can configure actions to occur; for example, before installation begins, or after an upgrade has finished. You can even set health checks for Helm to run and verify a deployment has completed successfully. Kubernetes + Helm duo Helm charts best practices Let’s look this example, Buffer chose Helm for its deployments For more than six years, Buffer, a social media management platform, had a monolithic architecture. In 2016, they decided to move to service-oriented architecture. They started using Docker for their development environments, and they needed a solution that can work well with containers. After assessing several tools in the market like Mesosphere and Amazon ECS, the Buffer crew settled on Kubernetes. They liked Kubernetes because of the problems that it solves with containers, by its relative maturity, large community, and cloud-provider-agnosticism. The Buffer engineering team began the migration process by rebuilding a piece of the monolith's functionality into its own, self-contained service. The project intended to set a remarkable example for other microservices at Buffer moving forward. After the success of this project, they looked towards breaking out different pieces of the monolith & making them separate microservices units. Two years later, Buffer is running three k8s clusters with over 140 services. They faced several along the way, but then they're solving by them moving onto Helm package manager that allows developers to define Charts to describe k8s configuration making deployments easy. challenges with Kubernetes deployments [Source credits for above Buffer's story: ] Stackshare , a cloud-native data science lab, had a challenge handling infrastructure as most of the folks were data scientists or mathematicians, they wanted to make these folks work painlessly. One more good example is Neptune After going through several alternatives, the team decided to use Kubernetes as a layer of abstraction that separates data scientists from the low-level infrastructure problems. Kubernetes started smoothly handling the fluctuating amount of resources. Along with Kubernetes, the team started embracing Helm templates to reduce the time needed to run new machines and start an experiment. [Source credits for above Neptune's story: ] CodiLime No doubt, Kubernetes has become a go-to solution for managing and running your application in Docker containers. Like we discussed in the article, with high power & popularity comes greater complexity. The Kubernetes YAML files & working with Kubernetes as a whole can be a bit hard. Helm is a tool that manages these deployments for you. It makes it easy to do versioning and templating of Kubernetes file. It allows you to define dependencies between deployable components to make the deployments and releases smooth as silk. Rimas Mocevicius, one of the co-founders of Helm recently wrote an article in which he talks about the and some major changes introduced in Helm v3. Helm v3 Beta Features Rimas, in his own words, these are the changes and enhancements in the Helm v3 beta features, Tiller has been removed. Release information is now stored in the Namespace. helm init command has been removed. The Helm home directory has been located off user's home directory. The stable repository is no longer added by default. The helm search command has been refactored to have sub-commands that can search the local repositories and the . Source credits: (I have taken Rimas Mocevicius’s permission to talk about it here) Helm Hub Rimusz Blog Removal of Tiller has been the most significant part in the Helm v3 and for the people who hated it and it has become a part of the history. Migration from v2 to v3 website should help you see how to migrate Helm v2 to v3 with use cases - when you have Helm v2 and v3 managing the same cluster, this case is when you want to move out of Helm v2 gradually and do not require v3 to manage any releases deployed by v2. In other case, migrating Helm v2 to Helm v3 where you want Helm v3 to manage existing Helm v2 releases. If you have any questions related to migration from v2 to v3, take a look at the official . This official guide from Helm Helm FAQ page Helm helps to optimize Kubernetes deployments with ease. Helm has become a popular tool in the Kubernetes ecosystem, gives all developers a way of building packages (known as charts) of related Kubernetes objects that can be deployed in a cohesive way to a cluster. It also enables parameterizing these packages, so they can be reused in different contexts and deployed to the different environments that the services they provide might be needed in.

Kubernetes and Helm: A Deadly Combo to Help You Deploy with Ease

Simplify your Kubernetes deployments If you know what the title means, you’re likely looking to get right into the meat of this tutorial. I’ll keep the introduction brief. What is Helm? Helm is a tool for templating and applying Kubernetes resources into a Kubernetes cluster. It advertises itself as the “npm of k8s”, which is a description I have found thoroughly unhelpful. Instead, — it explains it beautifully. read this article Why do you want your own Helm Repository? From this point onwards, I’m going to assume you’re familiar with what a “helm chart” is. If you’re not, read the linked article. You’ve got some options when you want to deploy your applications into Helm. You either have a helm chart per application or a helm chart for a group of applications. For example, you either have your or you have your . What are the pros and cons of either? auth-service-helm-chart java-applications-helm-chart A chart per application You can implement logic specific to an app or service within your chart. Pros : If you’ve got Microservices (and chances are in k8s you do), you’re going to end up with a lot of disparate charts all over the place. Lots of repetition and difficult to manage at scale. Creating new applications also requires more effort, you’ve got to wire up a chart correctly. Cons : A chart for many applications One chart is easier to manage. Your charts are all in one place (a chart repo). Pros: You’re going to need to be very careful that specific applications don’t bleed into the shared chart’s logic. Everything needs to be generic. Cons: I don’t like repetition As such, I opted for the shared chart approach. This created a new problem — where the hell do we host a chart? Enter the . helm s3 plugin Install the Plugin To configure a local helm CLI to use this plugin, the following commands need to be invoked: helm plugin install https://github.com/hypnoglow/helm-s3.git Wire up the S3 Bucket A Helm Repository needs to have an at its root. You can use the helm CLI to initialise it, but it’s easier just to wire this up with a spot of terraform. Instead of running two commands or depending on the CLI being correctly configured, run one command and rely exclusively on terraform. index.yaml helm resource "aws_s3_bucket" "helm_central" { bucket = "my-helm-central-bucket" acl    = "private" } resource "aws_s3_bucket_object" "object" { bucket = "${aws_s3_bucket.helm_central.bucket}" key    = "charts/index.yaml" source = "/path/to/my/files/index.yaml" } This terraform requires a file called in a local directory. The file I used looks like this: index.yaml apiVersion: v1 entries: {} , this will create a key “charts” where your bundled charts will go. Also, your S3 bucket will not be accessible from the internet and you’ll need to regulate access through IAM roles. Note Tell Helm about your new Bucket Now you’ve got a bucket, you need to inform your local Helm CLI that the s3 bucket exists and it is a usable Helm repository. To do this, you make use of the s3 plugin: helm repo add my-charts s3://my-helm-central-bucket/charts Wherever you’re running the helm command from will need appropriate IAM access to this S3 bucket. Either to read, write or both. Note: Test it out! Pull down an existing chart, package it up and push it to your new repository. # This will download the tar.gz from your stable central repository.helm fetch stable/rabbitmq # This will push that new tar.gz into your private repository.helm s3 push rabbitmq-<version>.tgz my-charts If that is successful, congratulations! You’ve just wired up your very own chart repository. For more articles and general rambling about technology, ! follow me on twitter

Stories, News & Mentions about HELM

Helm’s Stories on HackerNoon