DEV Community

loading...
Cover image for Kubernetes Dashboards: Lens
Loft

Kubernetes Dashboards: Lens

Rich Burroughs
Senior Developer Advocate at Loft Labs
Originally published at loft.sh ・5 min read

Command-line tools like kubectl are a great way to interact with Kubernetes clusters for some of us, but many people prefer a graphical interface. Kubernetes has a built-in dashboard, but some people are looking for features that it doesn’t support. In this series, we’ll look at some of the other dashboards that are available for Kubernetes and what they have to offer.

We’ll begin with one of the most popular alternatives out there, Lens. The Lens team describes their tool as  “The Kubernetes IDE for Development,” and it is a very powerful tool. Lens was originally proprietary, but Mirantis acquired it in August of 2020 and open sourced the code. It’s an Electron-based app that you run locally on your computer. It allows read and write access to your Kubernetes clusters.

Adding a Cluster

Connecting to a Kubernetes cluster with Lens is easy. If you have a local Kubeconfig file that points to the cluster, you can import that into Lens to connect.

Screenshot showing how to add a cluster to Lens from a Kubeconfig

Lens allows you to configure multiple clusters to manage, and switch between them easily.

Metrics

The metrics in Lens are very handy.

Screenshot showing the metrics dashboard in Lens

Lens won’t be able to display metrics until you configure it to work with Prometheus, though. If you don’t have a Prometheus instance in your cluster you can add one easily directly from Lens. Right-click on the cluster icon in the upper left corner of the UI, and then choose Settings. There you can install a Prometheus instance that is already set up to work with Lens. You can also preview the Kubernetes manifests for Prometheus before you apply them.

If you already have Prometheus running you can configure it to work with Lens.

Managing Objects

You can view the state of the objects in your cluster, including pods, deployments, namespaces, network, storage, and even custom resources. Lens is a great way to quickly identify pods that aren’t operating correctly, and get an idea why.

Screenshot showing the pod listing in lens. One pod has a yellow yield sign icon indicating an error. Mousing over it shows that the problem is insufficient CPU.

As you can see, in this view I’ve selected multiple namespaces to view the pods for. I’m able to just mouse over a pod that’s stuck in a pending state to see why. These are all things you can surface with kubectl, but some people do prefer a more graphical view.

Lens will allow you to make changes in the cluster if your user has the correct access. This could be very good or very bad depending on the context. If you’re a shop using GitOps, you may not want individual developers or platform engineers to make changes to the state outside of your code workflow. If you’re working with a development cluster, though, that may be fine. It all depends on how your team works.

One thing you can do with Lens is install applications from Helm charts. Click the Apps icon in the left menu, and then you can search for the chart you want to install. This is a lot handier than going to Artifact Hub and tracking down a chart there and it could be very useful for evaluating new Helm charts. 

Screenshot showing how to deploy NGINX from a Helm chart in Lens

After clicking the Install button you’re presented with a screen where you can edit the YAML directly to make changes. In this example, I’ve changed the number of NGINX replicas from one to three.

Screenshot showing how to edit the number of replicas in the Helm chart deploy

You can also edit running objects in the cluster like you would with kubectl edit.

Screenshot showing how to edit a running deployment in Lens

Again, this is not likely something that most teams would want to do in a production environment, but it could be great for people who aren’t comfortable with kubectl yet, or for people working in isolated development environments. It’s also important to note that the changes a user can make in Lens would also be possible with kubectl, so the real way to prevent changes from being made outside of your GitOps workflow is with Role-based access control (RBAC) permissions.

Extensions

Extensions is a newer feature in Lens that allows you to write custom code to extend Lens, or to re-use extensions that other people have built. Right now there are a few extensions shared on GitHub. Hopefully more will emerge. Kubecost just released an extension for tracking your cost metrics in Lens.

If you’d like to get your feet wet building your own Lens extensions, there is a development guide in the docs. Typescript is recommended, and you can also write tests for your extensions. If you enjoy using Lens and are comfortable with JavaScript/Typescript, this may be worth looking into.

Conclusion

Lens has a lot of great features, and it’s a standalone app as opposed to the built-in Kubernetes Dashboard. We all use tools differently, which is why it’s great that there’s such a variety of graphical user interfaces for Kubernetes. 

If you use Kubernetes, it’s worth taking a look at Lens.

In my next post in the series I’ll be looking at Headlamp, another popular UI for Kubernetes, and later we’ll look at the official Kubernetes Dashboard. Stay tuned.

Discussion (0)