K8S Quickstart & Helm

Today, Kubernetes becomes a must for DevOps Engineers, SRE and others for orchestrating containers. Once you have a Docker image of your application, you have to code some YAML manifests to define Kubernetes workloads after which, you deploy them with the kubectl command.

This deployment way is when you’ve only one application. When you start to have many applications and multiple environments it becomes overwhelmed. Often you define the same YAML files 90% of the time.

Here, we are going to focus on how to manage applications smartly with Helm.

What Is Helm?

Helm is a package manager for Kubernetes. Helm is an open-source project originally created by DeisLabs and donated to the Cloud Native Foundation (CNCF). The CNCF now maintains and has graduated the project. This means that it is mature and not just a fad.

Package management is not a new concept in the software industry. On Linux distros, you manage software installation and removal with package managers such as YUM/RPM or APT. On Windows, you can use Chocolatey or Homebrew on Mac.

Helm lets you package and deploy complete applications in Kubernetes. A package is called a “Chart”. Helm uses a templating system based on Go template to render Kubernetes manifests from charts. A chart is a consistent structure separating templates and values.

As a package, a chart can also manage dependencies with other charts. For example, if your application needs a MySQL database to work you can include the chart as a dependency. When Helm runs at the top level of the chart directory it installs whole dependencies. You have just a single command to render and release your application to Kubernetes.

Helm charts use versions to track changes in your manifests — thus you can install a specific chart version for specific infrastructure configurations. Helm keeps a release history of all deployed charts in a dedicated workspace. This makes easier application updates and rollbacks if something wrong happens.

Helm allows you to compress charts. The result of that is an artifact comparable to a Docker image. Then, you can send it to a distant repository for reusability and sharing.

What Are the Benefits of Using Helm?

• Helm provides you the ability to install applications with a single command. A chart can contain other charts as dependencies. You can consequently deploy an entire stack with Helm. You can use Helm like docker-compose but for Kubernetes.

• A chart includes templates for various Kubernetes resources to form a complete application. This reduces the microservices complexity and simplifies their management in Kubernetes.

• Charts can be compressed and sent to a distant repository. This creates an application artifact for Kubernetes. You can also fetch and deploy existing Helm charts from repositories. This is a strong point for reusability and sharing.

• Helm maintains a history of deployed release versions in the Helm workspace. When something goes wrong, rolling back to a previous version is simply — canary release is facilitated with Helm for zero-downtime deployments.

• Helm makes the deployment highly configurable. Applications can be customized on the fly during the deployment. By changing parameters, you can use the same chart for multiple environments such as dev, staging, and production.

• Streamline CI/CD pipelines — Forward GitOps best practices.

Quick Look On The Problem Helm Solves

Basic Kubernetes practice is to write YAML manifests manually. We’ll create minimum YAML files to deploy NGINX in Kubernetes.

Here is the Deployment that will create Pods:

apiVersion: apps/v1  
kind: Deployment  
metadata:  
  name: nginx  
spec:  
  selector:  
    matchLabels:  
      app: nginx  
  replicas: 1  
  template:  
    metadata:  
      labels:  
        app: nginx  
    spec:  
      containers:  
      - name: nginx  
        image: nginx:1.21.6  
        ports:  
        - containerPort: 80

The Service exposes NGINX to the outside. The link with pod is done via the selector:

apiVersion: v1  
kind: Service  
metadata:  
  name: nginx  
spec:  
  selector:  
    app: nginx  
  ports:  
    - protocol: TCP  
      port: 80  
      targetPort: 8080

Kubernetes service for NGINX: service.yaml

Now we have to create the previous resources with the kubectl command:

$ kubectl create -f deployment.yaml  
$ kubectl create -f service.yaml

We check all resources are up and running:

$ kubectl get deployment -l app=nginx  
NAME    READY   UP-TO-DATE   AVAILABLE   AGE  
nginx   1/1     1            1           8m29s

$ kubectl get pods -l app=nginx                                                                                        
NAME                     READY   STATUS    RESTARTS   AGE  
nginx-65b89996ff-dcfs9   1/1     Running   0          2m26s

$ kubectl get svc -l app=nginx   
NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE  
nginx   ClusterIP   10.106.79.171   <none>        80/TCP    4m58s

Issues with this method

• Specific values in YAML manifests are hardcoded and not reusable.

• Redundant information to specify such as labels and selectors leads to potential errors.

• Kubectl does not handle potential errors after execution. You’ve to deploy each file one after the other.

• There’s no change traceability.

Create a Helm Chart From Scratch

Helm can create the chart structure in a single command line:

$ helm create nginx

Understand the Helm chart structure

• Chart.yaml: A YAML file containing information about the chart.

• charts: A directory containing any charts upon which this chart depends on.

• templates: this is where Helm finds the YAML definitions for your Services, Deployments, and other Kubernetes objects. You can add or replace the generated YAML files for your own.

• templates/NOTES.txt: This is a templated, plaintext file that gets printed out after the chart is successfully deployed. This is a useful place to briefly describe the next steps for using the chart.

• templates/_helpers.tpl: That file is the default location for template partials. Files whose name begins with an underscore are assumed to not have a manifest inside. These files are not rendered to Kubernetes object definitions but are available everywhere within other chart templates for use.

• templates/tests: tests that validate that your chart works as expected when it is installed

• values.yaml: The default configuration values for this chart

Customize the templates

The values.yaml is loaded automatically by default when deploying the chart. Here we set the image tag to 1.21.5 :

Please note that You can specify a specific values.yaml file to customize the deployment for environment-specific settings.

Install The Helm Chart

Good advice before deploying a Helm chart is to run the linter if you made an update:

$ helm lint nginx  
==> Linting nginx  
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed

Run Helm to install the chart in dry-run and debug mode to ensure all is ok:

$ helm install --debug --dry-run nginx nginx

Using helm linter and dry-run install with debug mode will save you precious time in your development.

To install the chart, remove the --dry-run flag:

You can see the templated content of the NOTES.txt explaining how to connect to the application.

Now, you can retrieve the release in the Helm workspace:

Upgrade The Helm Release

Imagine you want to upgrade the container image to 1.21.6 for testing purposes.

Instead of creating a new values.yaml, we'll change the setting from the command line.

The pod is using the new container image as well:

The upgrade is visible in the chart history:

Change is inspectable with helm diff:

$ helm diff revision nginx 1 2  
default, nginx, Deployment (apps) has changed:  
  # Source: nginx/templates/deployment.yaml  
  apiVersion: apps/v1  
  kind: Deployment  
  metadata:  
    name: nginx  
    labels:  
      helm.sh/chart: nginx-0.1.0  
      app.kubernetes.io/name: nginx  
      app.kubernetes.io/instance: nginx  
      app.kubernetes.io/version: "1.0.0"  
      app.kubernetes.io/managed-by: Helm  
  spec:  
    replicas: 1  
    selector:  
      matchLabels:  
        app.kubernetes.io/name: nginx  
        app.kubernetes.io/instance: nginx  
    template:  
      metadata:  
        labels:  
          app.kubernetes.io/name: nginx  
          app.kubernetes.io/instance: nginx  
      spec:  
        serviceAccountName: nginx  
        securityContext:  
          {}  
        containers:  
          - name: nginx  
            securityContext:  
              {}  
-           image: "nginx:1.21.5"  
+           image: "nginx:1.21.6"  
            imagePullPolicy: IfNotPresent  
            ports:  
              - name: http  
                containerPort: 80  
                protocol: TCP  
            livenessProbe:  
              httpGet:  
                path: /  
                port: http  
            readinessProbe:  
              httpGet:  
                path: /  
                port: http  
            resources:  
              {}

Rollback The Helm Release

The upgrade was not conclusive and you want to go back. As Helm keeps all the changes, rollback is very straightforward:

$ helm rollback nginx 1  
Rollback was a success! Happy Helming!

The pod is now back to 1.21.5 container image:

Uninstall The Helm Chart

Uninstalling a Helm chart is trivial as the installation:

$ helm uninstall nginx

Reuse Existing Helm Charts

A lot of famous projects provide Helm chart to make the integration more user-friendly. They provide the charts through a repository. You have just to add it on your side:

$ helm repo add bitnami [https://charts.bitnami.com/bitnami](https://charts.bitnami.com/bitnami)

Once added, update your local cache to synchronize info with remote repositories:

$ helm repo update

You can now install the chart on your Kubernetes cluster:

$ helm install nginx bitnami/nginx

Charts are deployed with default values. You can inspire and specify a custom values.yamlto match your needs!

$ helm install my-release bitnami/nginx -f values.yaml

That’s all folks. Today we have looked at how to use Helm.

Please stay tuned and subscribe for more articles and study materials on DevOps, Agile, DevSecOps and App Development.

If you’d like to learn more about Infrastructure as Code, or other modern technology approaches, Please read or other articles.