Get Started - Validate Kubernetes Resources

‍

Hello, world! Meet John, the newest developer on the team. John has been tasked with deploying a new application to our Kubernetes cluster. He’s got some experience with Kubernetes but he’s finding out very quickly that managing infrastructure and multiple configurations is a daunting task. Without proper validation checks and visibility of resources, John is struggling to configure his manifests resulting in numerous failed deployments. 

Like John, many developers are responsible for pre-deployment tasks. Adding to the learning curve of moving into cloud-native development, many developers are also faced with significant challenges in comprehending the Kubernetes deployment process. Developers like John know that proper validation of resources is important and that not validating Kubernetes resources can result in the deployment of vulnerabilities leaving the application open to attack. However, by being unable to test against live infrastructure, most of the time John and so many developers are left guessing if they have validated all resources correctly. 

The need for a tool to help overcome these challenges and prevent infrastructure from vulnerability is obvious and that’s where Monokle comes in. In this post, we’ll talk about how Monokle can help developers like John successfully and confidently validate Kubernetes resources to ensure quality deployments.

## What is Monokle?

[Monokle](https://github.com/kubeshop/monokle) is an open-source **Integrated Development Environment** for **Kubernetes**. This tool can be used to import existing infrastructure code or start configuring architecture from scratch.

Monokle comes in three formats allowing you to pick, choose, mix, and match which setup works best for you at any given time. The Monokle ecosystem consists of the following:

* Monokle Desktop: A standalone app that helps us to create, manage & validate resources along with Helm & Kustomize integration. Download [Monokle Desktop](https://github.com/kubeshop/monokle)
* Monokle CLI: It's a command-line version of Monokle with features that allow validating Kubernetes configurations, templated Helm chart, and Kustomize build. Get started with  [Monokle CLI](https://github.com/kubeshop/monokle-core/tree/main/packages/cli#usage)
* Monokle Cloud: A powerful browser-based offering that allows you to import Git repositories and streamline DevOps & GitOps workflows. Sign in to [Monokle Cloud](https://app.monokle.com/).

In this blog post, we will be focusing on getting started with Monokle Desktop. With the  Desktop app, there are three main ways to deploy to Kubernetes:

* YAML manifests
* Kustomize
* Helm

For this example, we’ll use a [Minikube](https://minikube.sigs.k8s.io/docs/start/) setup to provision a local cluster and deploy an application. Then, we’ll show each of the three ways to deploy successfully via Monokle.

## Working with Monokle

To see how Monokle Desktop makes it easy for us to deploy applications, we're going to use a simple web application that is comprised of an NGINX web server along with MariaDB.

We will first deploy the NGINX [application](https://github.com/cerebro1/kustomize-helm-monokle) using templates for YAML. We’ll continue with  Kustomize to see how Monokle gives an overview of Kustomize and allows us to compare overlays. Lastly, we’ll deploy the application using Helm and with the Helm preview feature which will allow us to easily preview our Helm charts before deploying.

Access all the required files used in this blog post from this [GitHub repo](https://github.com/cerebro1/kustomize-helm-monokle).

### Prerequisites

* [Monokle Desktop](https://kubeshop.github.io/monokle/getting-started/)
* Kubernetes cluster. We are using [minikube](https://minikube.sigs.k8s.io/docs/start/) for this post but any cluster can be used.
* [Kustomize](https://monokle.io/blog/a-faster-kustomize-workflow-in-kubernetes-with-monokle)
* [Helm](https://monokle.io/blog/monokle-helm-kubernetes-deployments)

### How to create Kubernetes YAML manifests using Monokle Templates

Let’s get started by deploying the NGINX web application using a resource template and validating the same.

* Launch Monokle Desktop -> In “New Project”, click on “New from template”.
* Enter “Project Name” and “Location” to save your project. Click on “Next: Select a Template”
* Since we need a deployment and a service, we’ll use the **Basic Service Deployment** template from the list.
* Provide the **Deployment Settings** details:
   * Name: Name to identify the service and deployment.
   * Namespace: Select the namespace you want to deploy the resource to or choose default.
   * Image: Enter the image name. Example: **cerebro31/monokle-helloworld:latest**
   * Service Port: 80
   * Target Port: 80
   * Service Type: LoadBalancer.

‍

‍

## Validate Kubernetes Resources

Once manifests have been successfully loaded,  Monokle shows the manifest list separated according to resource type in the Navigator along with any validation errors. The detailed list of all the errors is highlighted in the Editor with 🔴. Select the invalid resource and hover over the error to display the error message as shown below.

‍

We can see the error message **Image tag ”:latest” used(KSV013)** which has a [policy violation](https://kubeshop.github.io/monokle/resource-validation/#policy-rules) that denotes that the latest image tag is used. Let's fix that:

* Click on **View Images** in Toolbar.
* Select the image name from the images list. This feature of Monokle allows you to [explore](https://kubeshop.github.io/monokle/images/) the different versions available of the selected image and use them.
* Click on the specific tag to learn more about it from the official image website. It is a standard practice to use a **stable** version.
* Click on **Replace** button available next to the image:tag in the **IMAGES** panel.

‍

* Enter the **New Image Tag** in the prompt. Example: “stable” and click on **OK**.
* Now,  go ahead and check if the error still shows. Click on **File Explorer** in Toolbar. Select the deployment manifest.

‍

Congratulations! The error is fixed and there are no validation errors related to the image tag.

As you can see, Monokle helps identify errors and policy violations while providing an easy way to fix them. Learn more about [common Kubernetes manifest errors](https://monokle.io/blog/common-errors-found-in-kubernetes-manifests).

### How to deploy to Kubernetes

Having fixed the errors, let us now go ahead and deploy the application to our cluster:

* Select **deployment** and **service** manifest using the checkboxes. Click on “Save” to save your manifests in the working directory.
* Select all resource manifests and deploy them to the namespace by clicking the **Deploy** button.

The notification on the top right corner indicates that resources have been deployed successfully to the local cluster.

‍
## Deploy to Kubernetes with Kustomize

In this section, we are going to deploy NGINX using Kustomize which has two overlays - dev and prod. You can download these files from [here](https://github.com/cerebro1/kustomize-helm-monokle).

* Launch Monokle Desktop -> In “New Project”, click on “Open a local folder”. Browse and select the folder that has Kustomizations. \

* Monokle loads the selected local folder and identifies the Kustomizations available. Click on **View Kustomizations** in the Toolbar. \

* We have created two overlays in this use case: dev and prod. In the **KUSTOMIZE** panel, we can view the resources. Click on them to view their respective manifests in Editor. Monokle also provides a feature to preview individual Kustomizations before deployment.

### Compare Kustomize Overlays

Monokle allows you to compare overlays. This helps to validate before deploying them into production. Let us see how we can compare the two dev and prod overlays that we have for our application.

* Click on Compare & Sync in Navigator.
* Select the overlays from the list in the parallel view.
* Based on resources, click on the **diff** to view the comparison. You can also set a filter to set the match criteria or filter based on Namespace.

‍

### Kustomize Deployment

Now that we know what is the infrastructure setup and how development or production is configured, let us deploy our NGINX application.

* Click on **View Kustomizations** in Toolbar. Select the prod overlay from the Kustomizations list. This will view the resources in Navigator. Select the resources and click on **Deploy**.

‍

## Deploy to Kubernetes using Helm

In this section, we will deploy MariaDB to our local cluster using [Bitnami](https://github.com/bitnami/charts) MariaDB Helm Chart. You can download these files from [here](https://github.com/cerebro1/kustomize-helm-monokle).

* Load Monokle with files from the local folder. Monokle understands configurations and loads Helm Charts separately.
* Click on **View Helm Charts** and then on **Helm Charts** in the Helm panel to view the list of all the charts available.
* Scroll down to select **MariaDB**.

Before we get into deploying the database, let us understand what is going to be deployed by using Helm Preview. This is essential for new developers to avoid misconfigurations and understand the abstracted part.

### See Helm Preview

Helm is one of the most popular package managers for Kubernetes. Apart from all the features it provides, it allows users to do a dry run to view the resources before deployment. The output of which is lengthy and can be complex to understand.

The Helm preview feature of Monokle allows you to preview your Helm deployments in a much simpler way. Let us see that with our application: \

* Click on MariaDB.
* Select **values.yaml** and Click on **Preview**.

‍

In the Navigator, we can currently see StatefulSets, ConfigMaps, etc. resources that will be created. Against each resource, we can view relationships with the help of outgoing and incoming links to resources along with the line number to which the resource is mentioned.

This helps you get started with Kubernetes and Helm quickly and also ensures that you get all the right information regarding a particular resource.

### Helm Deployment

We have NGINX running on our local cluster using Kustomize and we have seen the preview of the resources that will be created when MariaDB will be installed. So let us deploy the application.

* Select **values.yaml** file.
* Click on the **Install** button on the right top corner of Monokle Desktop.

‍

So with Monokle, you can deploy an application that has single or multiple components like frontend, backend, database, etc. with the help of templates that create YAML for your application infrastructure, or through Kustomize configuration, or by using Helm charts. 

whatever method you choose, Monokle ensures that you get a better understanding of what is being deployed, why it is being deployed, and what is the impact of each resource on other resources with ease.

## Conclusion

For new developers who are unfamiliar with handling the environment where applications run, it can be challenging to manage YAML. Since there are no inherent validation checks available, even a robust application may face downtime or be released with vulnerabilities due to Kubernetes misconfigurations.

Monokle provides features to deploy your application using YAML, Kustomize, or Helm. Pre-deployment features like previewing Helm/Kustomize resources, comparing resources against multiple environments, and validation checks add to ease the deployment. In case of failed deployments, you get the benefit of a faster loopback with real-time updates.

We have highlighted in this post how to deploy applications easily to a local cluster using Monokle. Explore other features of Monokle like [CLI](https://monokle.io/blog/monokle-cli-flexible-kubernetes-yaml-validation) and [Cloud](https://thenewstack.io/the-quest-for-high-quality-kubernetes-deployments/) and follow our blog for more posts so you can take full advantage of our complete suite of tools.

Please reach out to Monokle Product Leader [Sergio](https://calendly.com/sergio-ocon/sergio-30) if you have feedback about how we can make Monokle work better for you or drop a mail to sergio@kubeshop.io for information/assistance. You can also join in conversation with other users via [Discord](https://discord.com/invite/6zupCZFQbe) as part of our growing community.