Error-proof Kubernetes deployments with Monokle

In a previous [post](https://monokle.io/blog/get-started-validate-kubernetes-resources), we showed how you can quickly deploy applications using some cool [Monokle](https://monokle.io/) features but that is just the beginning. Now the task involves a modern application that is highly available, scalable, and reliable whilst being secured. One member of our team, John, is responsible for deploying an e-commerce application with multiple Kubernetes components to support a website, storage, payment gateway, etc.

Such applications are hungry for resources to handle high traffic. The traffic is not stable, so it is possible to reduce the cost through scaling, adjusting the number of resources, or increasing it to avoid overutilization. At the same, the application needs to be secured. We know that new applications are attacked within minutes of being available online. All this adds to the complexity and maintainability of the application.

Many tools offer Kubernetes observability to help with debugging and troubleshooting after deployment. Wouldn’t it be helpful to error-proof the application pre-deployment and not have to use multiple tools? The shifting left will reduce the time it takes to deploy a new application and will make sure that the results are as good as needed with many fewer tries.

## Pre-deployment error-proofing with Monokle

Monokle is a complete lifecycle manager of Kubernetes manifests. Cloud-native developers like John can create, inspect, validate, version control, preview, and understand the application's behavior and its infrastructure before deployment. Monokle takes away the pain of using multiple tools.

Monokle lies between traditional developer IDEs and operational cluster dashboards. Monokle not only helps in managing YAML but also understands it to provide a holistic view of the cluster. Built-in validation support helps developers ensure that the application is the least vulnerable. If your application is deployed using Helm or Kustomize, you can preview the resources pre-deployment thus reducing the chances of issues post-deployment. 

You can also ensure that the desired state of your application is maintained at all times. Post-deployment, Monokle provides real-time visibility of resource utilization thus helping you optimize costs and troubleshoot. Let us look into the Monokle features that will help you get one step closer to error-proofing.

## Monokle Features

Monokle helps in many steps of the process of managing the application configuration and thus has a lot of features. We have designed them to improve productivity & ease of working with Kubernetes. We will provide an overview of these features along with how developers can use them to error-proof Kubernetes deployments. All the YAML files and charts used in this blog post can be found in this [repository](https://github.com/cerebro1/kustomize-helm-monokle).

## Validation: Standardised codebase

The first step to error-proof a Kubernetes application before deployment is to validate your resources. Traditionally, that would imply separate plugins and integrations into an IDE. However, the restrictions included in the IDE limit what is available in many cases, and the workflow is far from perfect.

YAML uses indentation with white spaces for the structuring and nesting. A single syntax issue will fail YAML parsing. Spotting these errors can be a painful activity when your codebase grows in size. Monokle helps with highlighting these syntax errors before deployment. 

Let’s see how you can validate YAML:

- **YAML syntax validation**: A detailed view of validation errors corresponding to YAML syntax for each resource is displayed in the navigator. Hover over to the error sign to view the list. Select a resource from the list to view the complete error message. Make use of the form editor to apply a fix.

Developers are aware that the manifests need to adhere to the Kubernetes schema. Using the kubectl dry-run flag developers can validate resources but it is complex to understand. Any misconfiguration causes vulnerability leading to the application being open for attacks. Monokle helps identify Kubernetes schema errors before deployment as shown below.

- **Kubernetes schema validation**: A warning sign includes [Kubernetes schema errors](https://kubeshop.github.io/monokle/resource-validation/) and broken links. It validates that your manifests have the correct properties/value defined in the schema for their resource type.

To ensure security and standard infrastructure development, developers enforce policies. This helps in defining the behavior of the application. Instead of hard-coding these policies in the code, it is preferred to query Open Policy Agent(OPA) and verify the adherence.

To do that, traditionally you would need to use a separate tool but with Monokle’s built-in support to enable OPA policies, you can validate resources during development.

- **OPA**: Monokle displays the list of pre-defined, standardized OPA policies that can be enabled. This ensures that your infrastructure code follows standard practices to secure from **vulnerabilities**. [Leverage OPA](https://monokle.io/blog/leverage-opa-security-practices-with-monokle) security practices with Monokle.

In case you require custom rules to be enforced, Monokle has extremely powerful functionality to write custom rules in Monokle CLI and Monokle Cloud ecosystem. It supports typescript and allows you to create/debug and share [custom validators](https://monokle.io/blog/monokle-cli-flexible-kubernetes-yaml-validation).

Monokle’s built-in validation support helps in checking YAML syntax, adhering to Kubernetes schema, and applying Open Policy Agent(OPA) policies in real-time. In this way, developers can validate the complete infrastructure, get rid of vulnerabilities, and follow Kubernetes' best practices. The chances of a failed deployment due to misconfiguration will be reduced drastically.

## Kustomize preview: Understand resource relationships

Developers prefer configuration management tools like Kustomize to customize their deployments to different environments. Using Kustomize CLI, you can preview the overlay using the build command before deployment. 

```
sh
$ kustomize build overlay/dev
apiVersion: v1
kind: Service
metadata:
  labels:
    env: dev
    run: nginx
  name: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    env: dev
    run: nginx
  type: NodePort
…

```

The above output does not help much in understanding resource relationships or knowing if the overlay is as per desired deployment state. This complicates the refactoring before deployment. Select the dev **kustomization.yaml** and click on the preview to load the Kustomization preview.

Monokle helps you understand the resources that would be created when the Kustomize renders by faking it in preview mode. It shows the outgoing and incoming links to understand how resources are related. You can also view the errors and fix them using the form editor thus ensuring that your application is error-free.

## Cluster Mode: Real-time insight into the Cluster

For large-scale applications like e-commerce websites, Kubernetes has too many moving parts. The challenge increases when multiple clusters are involved. Troubleshooting, debugging, and making changes are difficult and might also introduce vulnerabilities.

Monokle allows users to configure multiple local/remote clusters. After the cluster is configured, you can get [real-time insight](https://monokle.io/blog/kubernetes-cluster-management-with-monokle) into the cluster. You can manage, validate and redeploy your manifest. Using the drop-down menu, you can select which cluster to view. It will automatically detect the default kubeconfig file or it can be declared in Settings -> KUBECONFIG. 

Monokle enters **cluster mode** when the connect button is clicked. To get a holistic view of the cluster, navigate to the Dashboard. It lists all the resources that are deployed in the cluster. You can choose any resource to view further details. Monokle maintains the count of resource running of each type along with its status, logs, and shell access if applicable. For the resources deployed to the cluster, Monokle shows the error count and resource relationships. 

Once you have viewed resource details and in case you want to make changes to YAML, Monokle provides an option to update resources using key-based input. Any changes you make are directly updated in your manifest using the form editor as shown below.

For the resources that have replicas maintained, cluster mode allows you to directly update the number of replicas without manually interacting with YAML. Click on Scale and provide the count. As shown in the below screenshot, we have increased the number of replicas for deployment resources.

So this way cluster mode helps in getting full insight into the cluster. You can avoid any accidental change using form editors, compare the actual cluster with desired deployment state, validate, and scale your resources quickly without manual interaction with YAML. These robust features of Monokle help you error-proof your application in ways that are not possible in a traditional single tool.

## Dashboard: View and debug resources

As a developer, you want to get a complete picture of the cluster after deployment which can help in planning infrastructure and understanding the scalability requirements of the application. Monokle dashboard comes in handy for viewing and debugging resources along with Kubernetes observability and cost optimization.

Click on **View cluster dashboard** in the toolbar and select the connect button to enable the cluster mode. After the resource deployment is successful, the dashboard will list the resource utilization (CPU, Memory, etc.) along with the resources deployed and their count. You can view each resource and its manifest. Select the namespace in which resources are deployed.

In this way, Monokle gives a complete view of the cluster and takes away the pain of using a separate tool for the cluster dashboards. You get to know the dependent resources, understand scaling requirements, and maintain consistency across environments. You can view the errors against each resource which can help in planning the infrastructure changes.

## Compare and sync: Actual vs the desired state

For any change in the application, understanding the expected deployment state is not easy due to the complex nature of Kubernetes. Maintaining consistent application performance across environments and ensuring the desired state is always maintained is essential for developers.

To avoid misconfigurations in such cases, Monokle provides a feature to [compare resources](https://kubeshop.github.io/monokle/compare-sync/). You can compare across Git branches and even individual commits, Helm/Kustomize preview against the cluster. This helps in capturing staging and development environments together and analyzing the differences which make it very easy to replicate resources based on the requirements and have the least difference.

In the compare and sync mode, you can also apply the filter to view only matching or non-matching resources. In case your application is deployed using [Kustomize](https://monokle.io/blog/a-faster-kustomize-workflow-in-kubernetes-with-monokle), you can filter resources using left join to view resources specific to overlay. In the below example, we have selected **only matching** to view all the resources that have differences.

In case you are using Helm to deploy your application, you can compare the local Helm chart with cluster deployment. In the screenshot below, we can see that DB's root password has been changed which is highlighted against each line.

With these features of Monokle, any developer can get a preview of the changes, and thus avoid errors. Functionalities like dashboard help in cost optimization and Kubernetes observability. Validation and previewing of resources help in avoiding misconfiguration errors post-deployment.

## Conclusion

We have highlighted the capabilities of [Monokle](https://kubeshop.github.io/monokle/features/) in this post to ensure the application is error-proof before deployment. This is what makes it so powerful over other IDEs and cluster dashboards. Multiple tools can help with post-deployment debugging and error-proofing but not many help with pre-deployment. With such Monokle features, the application will face the least downtime or issues post-deployment.

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.