Monokle vs. Lens vs. K9s

Finding the right tools to optimize Kubernetes deployment workflows is challenging. Here's a look at what these key players offer to handle everything from configuration tasks to cluster management.

Along the path of deploying an application to a Kubernetes cluster, there has always been a messy “handshake” between tools designed for authoring and approving your configuration versus tools designed for managing your clusters. The work might even pass between teams of application engineers and platform engineers.

Lately, at Monokle, we’ve been seeing a groundswell of demand to converge the work around this handshake, or at least provide more visibility, to help both sides converge around a shared goal of reliably and quickly shipping high-quality software. Developers and engineers of all stripes are looking for the right tools to optimize their Kubernetes workflows.

This leads them to look at a handful of key players operating around these handshakes in the Kubernetes configuration lifecycle:

• Lens Desktop (and its open-source version in OpenLens, that lacks some features like log access) has tools for exploring Kubernetes clusters in a visual environment, with statistics, events, and logs for troubleshooting.

• K9s is a terminal-based UI for observing and managing deployed applications on Kubernetes clusters.

• Monokle, a suite of tools designed to help everyone from developers to platform engineers manage the application configuration lifecycle in Kubernetes.

While Lens Desktop and K9s have earned their place in the industry being great tools for managing clusters, focusing on monitoring and management, we in the Monokle team think there are more human and technical issues to deal with when deploying applications. By unifying teams on Monokle, these leaders can improve productivity and quality while also reducing cognitive load through cooperation.

To illustrate how Monokle solves problems for users throughout the entire configuration lifecycle, for developers to platform engineers, let’s look at the major stages of your configuration lifecycle to see where these tools come into play and what they offer.

You should walk away with a clear understanding of which tool(s) meet your workflow best, whether you’re focused on the entire configuration lifecycle or just cluster management.

Authoring

In this stage, you’re working primarily in YAML files, the groundwork for Kubernetes manifests and resources, to design a desired cluster state that will support the application as developed. That includes specifying ingress, databases, secrets, resource relationships, environment configurations, resource constraints, and more.

Neither OpenLens or K9s offer tools or features for authoring configuration via manifest files. If you adopt Lens or K9s as a platform engineer, for example, you’ll have to pair it with another tool that helps developers create and validate their configurations, or end up with a “wild west” of Kubernetes IDEs and manual code reviews.

Or you could pick Monokle as the common language for all things authoring configuration.

Monokle helps you configure the desired cluster state quickly and error-free by moving checks and validations before you even commit code to your repository. It has features designed to make YAML a manageable and even educational experience, like:

*Forms, which simplify how you specify resource configurations in YAML by automatically interpolating the inputs into one or more manifest files.

• Templates, a mechanism for specifying custom visual forms using JSON to define the data schema and custom visuals.

• Support for configuration management through Helm and Kustomize, including viewing previews of generated resources, helping you debug charts/kustomizations before deployment.

• Real-time validation to educate engineers and eliminate YAML syntax or configuration errors before engineers even commit their changes, which results in less rework and higher quality configuration from the get-go.

Review and analysis

In this stage, you’ve already defined your desired cluster state in multiple manifests, and you’re either reviewing your work yourself or are ready to share with others via a pull request. This kicks manual peer reviews and automated analysis from your CI/CD pipeline to help you catch errors before you merge code that will inevitably fail on your production cluster.

Open Lens and K9s are not designed to help you at this stage, as they focus on looking at the state of your cluster after you deploy your configuration. The paid version of Lens includes access to additional tools that provide image scanning, team collaboration, and remote cluster access.

You could opt for Lens Pro at $19.90/seat/month to unlock a few useful features, or you could use Monokle to establish a common language for the quality of your configurations before you finally push to main and bring your latest changes into production via your CI/CD pipeline.

However, Monokle’s main goal at this stage is to provide visibility into the impact of your proposed changes. With this insight, you and your peers can make adjustments now rather than creating additional hotfix PRs to address issues that only crop up at the end of your CI/CD pipeline or on your production cluster. Here are some methods for reviewing and analyzing your commits:

• Visually navigate the incoming/outgoing relationships and dependencies between your configurations and Kubernetes resources to catch misconfigurations during renaming or refactoring efforts.
• Compare and synchronize two sets of resources, like local vs. cluster resources, across Git branches/repositories or namespaces/clusters, to understand the impact of your configuration on the actual state of your cluster.
• Identify and fix additional validation errors, such as Kubernetes schemas and Open Policy Agent policies.
• Quick diffs for viewing your commits against the deployed state of your cluster.

Deployment and cluster management

Your configuration lifecycle doesn’t end when you push the green Merge button and watch your CI/CD pipeline push your new code into production. In this stage, you’re focused on observing the state of your cluster and resources over time to identify and troubleshoot any potential issues.

Lens has always focused on the cluster management stage, with a focus on multi-cluster infrastructure, with open-source tooling that works with any flavor of Kubernetes. Its cluster management features include:

• Visual UIs for exploring Kubernetes clusters over using a command line and oftentimes overwhelming kubectl commands.
• Integration with Prometheus to visualize CPU, memory, network, and disk metrics all the way down to individual Kubernetes resources.
• Notifications for cluster or workload issues.
• Access logs for all workloads to troubleshoot ongoing issues and design fixes.
• Remote access to clusters.

K9s offers many of the same multi-cluster dashboarding capabilities, emphasizing speed, watching for changes and offering commands to interact with resources showing signs of trouble.

• A real-time dashboard based on a terminal UI, meeting many engineers where they already spend much of their time.
• Cluster metrics for pods, containers, and nodes.
• Keyboard-based (and customizable) support for viewing logs, restarting portions of your cluster, and scaling resources.
• Built-in benchmarking for HTTP services/pods to help you plan for optimizing resource requests and limits.

Monokle recently began supporting this stage of the configuration lifecycle with a new cluster mode, released in Monokle 1.13, which reduces your cognitive load in managing the health of your cluster with features like:

• A real-time dashboard of all deployed resources on your cluster and detailed information about each, like resource utilization.
• Access to live logs for investigating the states of an individual resource and a terminal to help you investigate further or resolve the issue.
• An activity dashboard with recent alerts and warnings to provide you with real-time information on the health of your cluster and configuration.
• Validation of in-cluster production resources against best-practices policy from Trivy (based on OPA) and more.

The skinny on designing your perfect configuration lifecycle

The truth is that there is a wealth of fantastic open source open-source tools available for engineers looking to manage their application configurations across the standard software lifecycle of plan->define->design->build->test->deploy. If you’re already using Lens or K9s, or a different tool not mentioned here, and feel like you’re covering your bases, then we wish you success!

But the great thing about the cloud native ecosystem is that you aren’t forced to use any tool in a vacuum—you can adopt or integrate multiple solutions to build the ideal lifecycle for your team.

Monokle is uniquely powerful because it guides you through the entire process, from authoring your first line of configuration to managing your production cluster. You don’t have to use anything else, but if you do, all the more power to you.

For those who love aligning their configuration management processes around a single tool to reduce cognitive load, check out Monokle. We have a mix-and-match suite of tools that cover the entire Kubernetes configuration lifecycle in a single language. Monokle Desktop is the powerhouse with advanced features, Monokle Cloud offers instant visibility and team collaboration, and Monokle CLI smooths over all the gray areas other tools can’t reach.

You can get started in just a few minutes on the Cloud or with our Desktop application to begin authoring, validating, and managing your Kubernetes configurations with collaboration and quality at the forefront.

And if you don’t see your use case covered by Monokle, especially the new cluster mode features that match most of the functionality offered by OpenLens and K9s, join our entire team on Discord or schedule a 30-minute conversation. We’d love to know how we could help solve your ongoing challenges with Kubernetes configuration with better authoring, reviewing, and managing features!