How Lens extends Kubernetes to help you work smarter
Lens Desktop helps developers and operators save time and work smarter with Kubernetes. While a command-line client like kubectl is a refined instrument for Kubernetes professionals, the developers on your team probably aren’t Kubernetes pros, and they shouldn’t have to be—not if their job is to write, troubleshoot, and push code. In this series, we’ll explore how your team can use Lens to solve common Kubernetes challenges, including collaboration, security, and more.
Extensibility is right at the heart of Kubernetes’ design, and is arguably the secret of Kubernetes’ success. Custom resources and operators enable a vast number of new functionalities. (Custom resources are bespoke abstractions manageable via the Kubernetes API, while operators are more complex apps that utilize those custom resources.) Standard interfaces with container runtimes, networking solutions, and storage providers let you plug-and-play the tool that works for you.
All of this extensibility leaves Kubernetes users spoiled for choice. In fact, it can be hard to know where to start. The Cloud Native Computing Foundation (CNCF) landscape is full of amazing open source projects, but it can be a bit dizzying to behold:
CNCF landscape from cncf.io
Lens helps you get started by bundling essential open source tooling, some of which you’ve already used in the course of this series:
Trivy: A Kubernetes operator that scans Kubernetes resources for known vulnerabilities and misconfigurations.
Helm: A “package manager for Kubernetes” that helps define and manage applications on a cluster.
Prometheus: A monitoring and alerting toolkit that can help standardize and coordinate metrics on a cluster.
This article will explore Lens’ Helm and Prometheus integrations—then dig into the ways you can extend Lens itself.
Charting a path with Helm
By design, Kubernetes doesn’t provide an abstraction for “applications” per se—instead, Kubernetes objects correspond to the various components that work together to constitute an app. This situation creates serious challenges for packaging and managing complex apps consisting of many different Kubernetes resources, all of which need to be configured properly.
Helm provides one solution to this problem by acting as a sort of package manager. Applications—WordPress, for example—are defined in “charts” which serve as declarative configurations for the swath of resources (Services, Deployments, StatefulSets, Secrets…) that comprise an app.
Lens Desktop seamlessly integrates Helm for all users, and the popular bitnami chart repository is enabled by default. Need to add new repositories containing other charts? Click Lens in your operating system taskbar menu and select Preferences. On the Preferences pane, choose Kubernetes and scroll down to the Helm Charts section.
Here you can add repositories from a large, pre-populated collection or add new Helm repos by URL.
Once you’re happy with your repo selection, press ESC to close the Preferences pane and select Helm> Charts in the Lens navigation menu. This will bring you to a pane in which you can search your repositories for charts—just like we did in the last article.
This time, search for postgresql.
After you select the postgresql chart, click Install. You could deploy Postgres with just one more click, but pause here to look over the chart itself. This YAML file enables you to look over and manage the configuration of the app, including details like authentication, as well as to get a sense of the various Kubernetes resources you will be deploying.
When you’re ready, click Install. Now you’ll see postgresql on the Releases pane—this lists applications deployed to your cluster.
You can click on postgresql for more details, or explore the various Kubernetes resources in the navigation menu to see what has been deployed. (Try, for example, Services, StatefulSets, and PersistentVolumeClaims.) You can click on each of these resources to see more details about them.
When you’re finished, you can remove Postgres from the cluster by clicking the ⋮ icon on the Releases pane and choosing Delete, or by selecting the Postgres release and clicking the Trash icon.
Note that—owing to the nature of PersistentVolumes, which may be reused by ephemeral services—the PersistentVolumes and PersistentVolumeClaims for postgresql will need to be deleted manually. You can do this the same way, by selecting those resource types in the Storage section of the navigation menu, then clicking Delete in the ⋮ icon options for the resource in question.
Prometheus: Now you're cooking with fire metrics
Prometheus is the de facto standard for Kubernetes monitoring. The open source project provides robust metrics and alerting functionality—and even more pertinently for our topic, it brings along its own API endpoints for extension and integration.
Like Helm, Prometheus functionality is bundled with Lens. You can choose to run a small Prometheus instance in your cluster, giving you metrics for nodes visible to you according to RBAC permissions on your account. (Admins can naturally see metrics for everything.) If you're already running Prometheus, you can export metrics from that instance to Lens.
To set up metrics, click on the Cluster Catalog button in the upper-left-hand navigation menu:
Click the ⋮ icon for your cluster and select Settings.
On the settings pane, select Metrics. Here you can choose a variety of metrics systems (such as a pre-existing Prometheus instance). Choose Lens to activate the bundled instance of Prometheus.
If you choose this option, Prometheus will take a minute or two to start. Press ESC to exit the Settings pane. Lens will connect to your Prometheus and cluster metrics will appear on your cluster dashboard.
Extending Lens
Like Kubernetes, Lens is a platform designed for extensibility, so you can tailor your tools to your precise needs. You can reach the Lens Extensions pane through the system menu:
From here, you can install the extensions of your choice:
There are a variety of third-party extensions available, from both vendors and community contributors, including:
Kubecost by Kubecost: Monitor cost data by namespace.
Kubescape by Armo: Scan for misconfigurations, vulnerabilities, and RBAC violations.
Starboard by Aqua Security: Gain visibility into vulnerability assessment reports for workloads.
Resource Map by nevalla: Visualize cluster resources on a real-time graph.
You can find a complete list of extensions on GitHub.
If you want try out extensions, you can quickly and easily install a community-created Resource Map extension by entering @nevalla/kube-resource-map in the installation field and clicking Install:
(You may need to restart Lens Desktop and enable the extension after installing.)
Once the Resource Map extension is installed and enabled, you can click on Resource Map at the bottom of the navigation menu. Here you can see a visual map of the resources on your (likely very simple) cluster.
Of course, this would look much different on a cluster in active use:
Screenshot from nevalla
To remove an extension, navigate back to Settings > Extensions and click on the ⋮ icon to delete or disable.
If you’re interested in developing your own Lens Extensions, you can explore the Lens Extension API docs.
Conclusion
Kubernetes and Lens Desktop alike are built for extension, so you can tailor your tools to your needs. Lens Desktop brings the added benefit of curation, integrating some of the most essential projects from the CNCF landscape directly into your development environment. With Lens Desktop, you have the tools you need ready to hand, so you can get the job done faster.
Even with the best tools available, however, you’ll sometimes find yourself in situations where you need extra support. In the next article, you’ll learn more about how Lens integrates best-in-class support right into your workflow.
