Monokle, Helm & Quality Kubernetes Deployments

Before the cloud native era, we built infrastructure from Digital Ocean tutorials. Developers and IT teams were responsible for provisioning individual servers with all the hardware, networking, OS configurations, and services necessary to run services or apps on the web. That meant installing and configuring an Nginx web server or MySQL database dozens or hundreds of times following pre-approved—and extremely tedious—steps.

Eventually, DevOps emerged and took hold among technology-savvy organizations, which also led to a progression away from raw Linux administration and toward provisioning/configuration management and automation tools like Ansible and Puppet. That was a major step in the right direction, but these teams quickly started to look for faster and more reliable ways to deploy their apps to the web than administering multiple nodes via configuration files.

But now, in the cloud native era, where infrastructure as code (IaC) is not only _best_ practice but also expected, Kubernetes developers shouldn’t have to recreate their infrastructure repeatedly, right?

Unfortunately, we’ve fallen into the same trap. As Kubernetes clusters ballooned in complexity, DevOps engineers found themselves recreating manifests for commonly-needed resources, like web servers or databases, more often than they would like. And as soon as they replicated those assets in multiple places, making minor tweaks here and there, their manifests were no longer reliable sources of truth. 

And to complicate matters more, most attempts to add version control—a necessary step in modern DevOps toolkits, were unsuccessful. In an era where the industry continues to trend toward automating deployments with GitOps, reliable version control has become a non-negotiable must-have.

What if the Kubernetes development community had a package manager—like Homebrew for macOS or apt for certain flavors of Linux—for discovering, editing, and maintaining Kubernetes manifests and deployments?

## How teams leverage Helm in Kubernetes deployments

[Helm](https://github.com/helm/helm) is a tool for managing charts, which are packages of pre-configured Kubernetes resources. Charts contain a description of the package in the `Chart.yaml` file, plus one or more templates containing Kubernetes manifest files in YAML.

Kubernetes developers and DevOps teams are already using Helm for lots of robust use cases, pulled straight from the [Helm README on GitHub](https://github.com/helm/helm):

* Find and use popular software packaged as Helm Charts to run in Kubernetes

* Share your own applications as Helm Charts

* Create reproducible builds of your Kubernetes applications

* Intelligently manage your Kubernetes manifest files

* Manage releases of Helm packages

Overall, Helm provides great benefit for Kubernetes-based organizations eager to speed up their workflows around creating the resources needed for a functional and effective cluster. Instead of rewriting the same common resources repeatedly or mismanaging multiple versions of a manifest, they can use Helm to deploy standard templates with their customizations layered on top.

Unlike Kustomize, which utilizes a locally-stored base and patches YAML files, Helm is most commonly used to install Charts from a public repository like [Artifact Hub](https://artifacthub.io/packages/search?kind=0). For example, Helm simplifies the process of installing the [kube-prometheus-stack](https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack), which deploys end-to-end Kubernetes cluster monitoring with Prometheus, into just three commands:

`helm repo add prometheus-community https://prometheus-community.github.io/helm-charts`

`helm repo update`

`helm install [RELEASE_NAME] prometheus-community/kube-prometheus-stack`

## What are the challenges of working with Helm charts?

Three commands to install three thousand lines of Kubernetes manifest YAML. For all the advantages Helm creates in terms of “time to deployment,” there are a few headaches that may be experienced in abstraction, visibility, and debugging.

**Abstraction**: Helm charts are complex groups of rules, configurations, and resources, but the CLI tooling and public repositories make it remarkably easy to deploy to your production environment—for better or worse. In its default settings, [kube-prometheus-stack](https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack) has nearly 3,000 lines of YAML code—how’s that for 1000X abstraction?

**Visibility**: Most developers and DevOps engineers using Helm will deploy resources and services without ever reading a single line of YAML—which can be extremely freeing or monstrously frustrating, depending on how the deployment goes. And Helm doesn’t make it particularly easy to view and analyze the manifests and templates it deploys by default. Your best option is to manually run `helm show values`, which only gives you the default part of the picture.

**Debugging**: For most workflows, the only way to understand what kind of manifests and resources you’re dealing with is by running Helm with `helm install --dry-run --debug` and hoping you get some meaningful information from the resulting manifest file. Just one extra (and often unnecessary) step that gets in the way of development velocity.

**Customization**:  Helm charts include a `values.yaml` file that includes the parameters available for customization. The `values.yaml` file can be quite complicated if the developer wants to add flexibility, but it is not totally flexible: anything not included in the file won’t be parameterizable. Do you want to add a label to the pods for cost management? Bad luck unless the chart already includes it.

## How does Monokle Desktop help with deploying to Kubernetes via Helm?

Monokle Desktop is a cross-platform desktop app that helps DevOps teams and developers define, compare, and audit the desired and actual states of their Kubernetes cluster. By layering Kubernetes configuration management and version control into your existing processes around building, optimizing, and troubleshooting complex Kubernetes manifests, Monokle helps you deploy faster and error-free.

And we’ve built Monokle Desktop to be the perfect accompaniment to Helm charts—its configuration management and rich diffs on current vs. future cluster state solves all your core problems around using Helm while retaining the streamlining and simplification you need to work effectively. That starts with [native support](https://kubeshop.github.io/monokle/helm/) for creating, analyzing, debugging, and deploying Helm charts.

## Navigate your Helm charts

When you add a folder with Helm charts to Monokle, it immediately organizes your `Chart.yaml`, `values.yaml`, and template files as shown in the screenshot above. You can see and edit the source code for any selected resource, file or template in the **Editor**. 

Since Monokle understands your Helm templates and their usage of properties provided in your values files, you can interactively identify where properties referenced in your templates are defined:

And correspondingly hovering a property in a values file will show you which template(s) that use it:

Monokle will also help you identify any property references that might be invalid - and since all validation is in real-time you can edit your templates and get corresponding feedback that your errors are fixed accordingly.

## Preview and debug Helm charts

Click the **Preview** button next to any `values.yaml` file to run Helm on the selected file and show the generated resources in the **Navigator**. Select a resource to show its generated YAML in the **Editor**, and use the popups next to each resource to explore how it interacts with others on either side of an incoming/outgoing link.

Through the incoming/outgoing links icons that appear before or after your generated resources, you can quickly understand how the deployments, jobs, pods, and more are interconnected.

You can of course edit any file or template in your Helm Chart and re-run the preview, which helps you immediately understand how your changes impact the generated YAML manifest and, ultimately, your Kubernetes cluster.

It’s a perfect way to make meaningful changes or perform debugging in a controlled, highly-visible environment. Catch bugs before deploying to production or share your Helm chart with others.

Monokle’s Helm preview feature is also customizable—you can even have multiple preview configurations based on your needs. You can select which files to use (and in what order), choose between `helm template` and `helm install`, and set other environment variables. Monokle then shows you the complete command it’ll run to create the preview for full visibility.

## Example: Defining releases with Helm

A few months ago, you deployed v1.0 of your web application, which consisted of 20 Kubernetes resources. You defined everything in a Helm chart, including a few manifests that serve as templates for multiple resources that require a few small tweaks depending on whether you’re deploying to staging or production.

After the v1.0 release, you immediately got started on v2.0. Along the way, Monokle Desktop’s IDE features, like [resource validation](https://kubeshop.github.io/monokle/resource-validation/) and the [resource form editor](https://kubeshop.github.io/monokle/form-editor/), helped you quickly write new code and prevent any basic YAML syntax errors.

But now that you think you’re ready to launch v2.0, it’s the perfect time to put Monokle into Preview mode to explore the changing relationships and the generated manifest files visually. 

Why is this an important step? Because of some new efficiencies, you added to your chart, your web app now only needs 15 Kubernetes resources.

You’re confident that it works, but it’s a dramatic change. With Monokle’s Helm preview and resource navigation tools, you have full visibility into your chart’s inner workings, but you don’t have to scan multiple YAML files or do dry runs on the CLI to debug the output.

You can even click the **Diff** button to visualize changes in how specific resources will get deployed to your cluster.

It’s the confidence you need to push v2.0 into your version control and prove, through your CI/CD pipeline, that you can deliver a powerfully functional Kubernetes cluster the first time.

## Next steps for Monokle

[Monokle Desktop roadmap](https://github.com/orgs/kubeshop/projects/29/views/8) is full of additions to our functional support for Helm. We are adding support for templates, repo management, and many other features that will help you create your own Helm charts easily, fast, and with confidence.
Join the conversation and help us by suggesting functions that will make your job easier.

## Take the Helm with Monokle

To get started, hop over to our [downloads page](https://monokle.kubeshop.io/download) to get Monokle for macOS, Windows, or Linux. If you don’t already have [Helm installed](https://helm.sh/docs/intro/install/), you should start there as well.

Whether you’re developing new Helm charts to share with the Kubernetes community or modifying the charts you get from Artifact Hub, we’d love to hear about your experiences with our Manifest IDE. Join us on [Discord](https://discord.gg/6zupCZFQbe) to share details about your workflows and chat with other Kubernetes developers who are eager to help their Helm-loving comrades better manage manifests at scale.