Forem: Cortney Nickerson

Monokle vs. Lens vs. K9s

Cortney Nickerson — Sun, 05 Feb 2023 23:00:00 +0000

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!

Leverage OPA Security Practices with Monokle

Cortney Nickerson — Thu, 24 Nov 2022 01:30:47 +0000

At Monokle, we care about helping developers like you be more productive while working with Kubernetes. A big part of that mission is helping you spend far less time debugging and fixing common errors early in the deployment process.

You know the type—indentation, typos, misspelled resource names, invalid output from Helm or Kustomize to name a few. With Monokle, we help resolve these pain points straight away by checking off one more annoyance in your pre-deployment workflow on our way to achieve our mission of making your Kubernetes development experience joyful.

But as we work toward our goal of making configuration tasks easier to manage, we are very aware that not all errors are simple annoyances. Your organization likely maintains specific policies and best practices built around issues like cloud costs, security, and data privacy. These might come from internal discussions spearheaded by your CTO or cloud native best practices using an open-source validator tool from the Cloud Native Computing Foundation (CNCF).

These rules (and associated errors) are worthy of your attention and time, but that doesn’t mean that policy enforcement has to be an enormous burden on your productivity.

We believe in validating your work around complex errors before deploying so you spend less time fixing them. So in our Monokle 1.7.0 release we added support forOPA (OPA) to automate how you validate, identify, and fix mission-critical Kubernetes errors.

What is Open Policy Agent?

Open Policy Agent, also referred to as OPA, is an open source general purpose policy engine for building specific policy enforcement across an organization's development stack.

OPA policy allows Kubernetes development teams to define rules on exactly how their systems should behave, but without hardcoding those rules directly into the code itself. Instead, you query OPA with the rules you’re looking to apply and the code you want tested, and it gives you a pass/fail result.

OPA-driven policy decisions are entirely up to your organization. They can cover “simple” rules like requiring labels to complex directives like security, cloud costs, and best practices around availability.

What OPA rules does Monokle include?

We added automatic OPA validation directly into Monokle to keep your development workflows streamlined. No more context switching or worrying about whether you’re violating a cloud native best practice when you’re finally ready to deploy to your cluster.

We implemented rules developed by the DefSec team at Aqua Security—we’re grateful for their hard work and OPA expertise to help Monokle users get up and running with OPA.

The full list of rules can be found in our documentation, but here are some examples and their of various levels of severity:

SYS\_ADMIN capability added: Processes in your containers can use root-like privileges.
hostPath volume mounted with docker.sock: Your container can have full root access to its host system.
Accessto host network: Processes in the pod to communicate with processes bound to the host's loopback adapter.
CPU notlimited: Can create resource exhaustion during a DDoS attack.

How to enable and use OPA with your Kubernetes configuration files

If you don’t have Monokle yet, install the desktop app! We support macOS, Windows, and Linux, and it only takes a few clicks to see all your Kubernetes resources in Monokle.

Enable OPA policies

Monokle’s OPA features work with your vanilla Kubernetes manifests, the output from Helm charts or Kustomizations, and cluster resources. To integrate OPA into your workflows, start applying and viewing OPA rules by clicking the *Validate Your Resources* button located on the left-hand navigation menu, then the *Configure* button under the Open Policy Agent heading to view the list of available rego policies.

We recommend you enable them all with the *Enable all*button, and then disable those that cause too much headache or don’t work with your team’s policies. You can sort policies by their ID or severity to target your search and enable those most relevant to your organization. Just click the toggle button next to any policy to enable or disable it.

Validate your manifests and resources against OPA policies

Once you’ve enabled a policy, Monokle gets started validating all configuration files and cluster resources in the background—there’s nothing else to enable or configure.

As you develop a vanilla manifest, Monokle marks code that violates a given policy with a red error icon, just as it does with the "simpler" syntax errors mentioned earlier. Hover over that icon to see what OPA policy you’re violating, along with advice on fixing your manifest.

As you make changes, Monokle keeps querying OPA with your code until you meet your organization’s best practices, and poof—the error disappears in real-time!

But Monokle takes the use cases even further. Since OPA validation works with Helm/Kustomize output too, you can test those outputs before you try deploying any generated config files, objects, or resources. Monokle also lets you inspect your existing clusters for OPA errors, which helps you retroactively fix invalid manifests you deployed before implementing OPA policies or having the right tool to identify them quickly and easily.

Now that you can see OPA validation errors directly in Monokle, you don’t have to juggle more development tools, waste time deploying code that ultimately doesn’t meet your organization’s standards, or fret over rolling back a production deployment. Monokle’s OPA capabilities help reduce complexity of pre deployment configuration tasks and maybe even makes working with K8s objects and resources fun—well, easier for sure!

What’s next with Kubernetes configuration workflows?

We’re working non-stop listening to user feedback as we add new features and capabilities to Monokle with the vision of reducing your time working with YAML to a minimum so you can get back to what you enjoy most, coding!

Try Monokle and get our new releases directly to your desktop. Download for macOS, Linux, and Windows. It’s entirely free and open-source complete with an MIT license.

Learn more about how to create YAML Manifests in Monokle and once you’ve spent some time leveraging Monokle to validate and fix your errors—whether syntax or OPA related—we invite you to stop by our Discord Server to give us feedback.

Our engineers, DevRel, and product team are all active in this space and are happy to discuss implementing more OPA policies, new options for letting you build custom plugins for your organization, or other pains that we can help you resolve in your pre deployment workflows.

Monokle, Helm & Quality Kubernetes Deployments

Cortney Nickerson — Thu, 24 Nov 2022 01:13:24 +0000

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 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:

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. For example, Helm simplifies the process of installing the 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 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 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 and the resource 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 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 to get Monokle for macOS, Windows, or Linux. If you don’t already have Helm installed, 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 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.