Faster Kustomize workflow in K8s with Monokle

Jun 28, 2022
5 min
read
Wito Delnat
Software Engineer
monokle

Wito walks through how to introduce variations and adjust Kustomize packages in Kubernetes using Monokle.

Share on Twitter
Share on LinkedIn
Share on Reddit
Share on HackerNews
Copy URL

Table of Contents

Get started with Monokle today

Vanilla Kubernetes manifests work great up to the point where you want to introduce slight variations depending on, for example, the target environment. A classic example is increasing the number of replicas between development and production environments to become highly available. There are many tools available to solve this problem, but today we’ll be looking at my favorite: [Kustomize](https://github.com/kubernetes-sigs/kustomize).

## Kustomize

For those unfamiliar with Kustomize, it has a low entrance barrier since there is no domain-specific language. Unlike Helm, Kustomize uses YAML just like vanilla Kubernetes manifests. When adopting Kustomize for a project, you would first add a base directory that contains the common resource manifests, and then use overlay directories to add new resources or patches to common resources.

A basic workflow to apply a Kustomize package follows:

  • Execute `kubectl kustomize $directory` to inspect the output of a specific overlay using the tool(s) of your choice
  • Tweak resources and Kustomizations as needed
  • Once satisfied with the result, apply it to the cluster with `kubectl apply -k $directory`

This workflow could be better! Let’s take a look at how you can work faster with [Monokle](http://monokle.io).

## Monokle, Our Open-Source Desktop Kubernetes YAML Editor

[Monokle](http://monokle.io) is an open-source desktop Kubernetes yaml editor tool that allows you to manage, edit, and debug Kubernetes configuration files easily and at scale.

Within Monokle, you’re be able to interactively preview and validate Kustomize and Helm chart outputs *before* you deploy them to your Kubernetes cluster - saving you the headache and lost time it takes to identify and fix errors that come up.

When you open a project using Kustomize package in Monokle, you’ll want to take a look at the available Kustomize overlays and build one to see what resources are included in the box; Monokle provides a dedicated “Kustomizations” tab to the left that lists all Kustomize overlays and patches found in your project - allowing you to easily navigate them and inspect/edit their contents.

## Preview and Compare Overlays

Monokle provides a dedicated “Kustomizations” tab to the left that lists all Kustomize overlays and patches found in your project allowing you to easily navigate them and inspect/edit their contents.

Similarly to `kubectl kustomize`, Monokle allows you to preview the output of a Kustomization with the benefit of having a powerful navigator and validation tools at your disposal for the generated resources. Select the “Preview” action next to a Kustomization in the list of Kustomizations and Monokle will show the resources generated by Kustomize in the Navigator in the middle:

Kustomize web gui

Monokle automatically validates the generated resources for you by showing both schema and reference errors directly in the navigator allowing you to quickly ensure that the resources generated by Kustomize:

  • Adhere to the target Kubernetes objects schemas (property names, values, etc)
  • Contain valid references to other resources
  • Adhere to any OPA validation rules that you might want to apply (more on OPA validation below!)

More difficult is understanding the differences between overlays: do they simply tweak a minor value or add completely different resources?

With Monokle you can answer this question by comparing two previews. Select the “Compare Anything” button on the top of the navigator to access this functionality.

Comparing kustomize resources

In this example, we are comparing the output of the local and production Kustomize overlays. Immediately, you can see that the local overlay on the left adds a database and that the deployment and ingress are different.

You can also inspect the difference of a specific resource by clicking the diff button (see below). In this example, you’ll notice how the production deployment has a sidecar to connect securely with a Cloud SQL database on Google Cloud Platform.

yaml file correction suggestions

## Last-mile edits through validators and forms

Most often, you would not directly apply a Kustomize package downloaded from the internet since it’s true that applying a package without inspection can expose your cluster to severe security vulnerabilities. Monokle has integrated support for the open policy agent (OPA) to analyze your resources in real time to prevent this from happening:

The example above shows two security concerns found in the “demo” Deployment resource and how you should mitigate them. Our OPA validator has 25 fine-grained rules so you are in full-control of how strictly secured you want your resources to be (read more about OPA validation in our documentation).

Besides security patches, you might simply want to tweak some environment variables or scale the amount of replicas of your deployment. You can either change this within the YAML editor or use Monokles’ built-in forms to avoid having to work directly with YAML:

yaml file security dashboard

## Deploy to cluster

Deploying a Kustomize project to the cluster feels less intimidating once you have a deep understanding of its overlays and have tweaked them to be custom tailored to your environment.

Let’s go ahead and apply the local overlay to a Minikube cluster running on your development machine.

To do this you can compare the overlay with your cluster using the “Compare Anything” feature outlined above:

k8s cluster settings toggle

I always prefer to compare with a *view left join* when I’m ready to deploy a package to a cluster. It only compares resources that are present in the overlay and filters all the other cluster resources that are irrelevant. The result is a compact view which shows that no similar resources have previously been applied.

You can also inspect the resources by clicking on their name. I tend to do a final sanity check on the resources I’ve last edited to make sure that there are no typos. These two benefits of Monokle make me confident that everything will work when I press the deploy to cluster button.

## Closing Thoughts

Monokle provides a wealth of functionality that makes working with Kustomize so much easier:

  • Monokle’s preview and compare features let you swiftly understand a Kustomize package and the resources it generates 
  • Monokles integrated validation functionality notifies you of schema, reference, and policy errors that you can fix interactively before deploying them to your clusters
  • Monokles editors make it easy to make changes to contained Kustomizations and manifests - even if you’re not an expert on the target Kubernetes resource schemas

Monokle provides a wealth of functionality that makes working with Kustomize so much easier.

You can safely deploy to your cluster knowing how the current resources will be affected.

While editing resources in an IDE like Visual Studio Code and later deploying them through `kubect` works perfectly fine, a dedicated Kubernetes resources tool like Monokle gives you the power and flexibility to get your tasks done faster and with more confidence.

This allows you to spend your time and energy on what really matters - making a product that your customers love to use!

If you have questions or feedback about Monokle, please reach out to us on [Discord](http://bit.ly/kubeshop-discord). We’re keen on making Monokle a better tool for our users and eager to hear your feedback.

Related Content