Introduction
Kubernetes turned 10 years old in 2024 and one of the main reasons why this open source project has become so popular and important in the DevOps, Cloud, and infrastructure communities is its flexibility. It can support from the smallest workload to the biggest possible thought application stack with many moving pieces and all on top of container solutions. But great power comes with great responsibility, and normally when things get so flexible and has so many options, difficult decisions could turn into issues at scale. This is why that optimal visualization over our cluster to, not only monitoring and alerting, but also troubleshooting is critical.
Kubernetes Lens is a desktop tool that comes to make easier and faster the visualization and troubleshooting of multiple Kubernetes clusters. With Lens, you can access the pods detailed information in a fancy way, with basic monitoring of resources, logs, configuration, and so on. With this IDE you can also forward traffic from the pod, which is remotely deployed, to your local computer (via service port forward) to review and understand how the application is behaving and better troubleshoot.
How to get started
First letʼs go to the official Kubernetes Lens Webpage (http://k8slens.dev/) where we can find information about the tool and download to supported platforms Windows, macOS, and Linux).
Once installed and opened, it'll ask you to create an account or use one that you already have. Then you can start adding Clusters.
Basically Lens is a Kubernetes client as any other, and the best way to access a Kubernetes cluster and get authenticated is through the KUBECONFIG file. This is a YAML file that has all the information about the cluster regarding its location, way to access, username, context, even other Clusters, etc. You normally this need file to access with things like kubectl, which is the main Kubernetes CLI.
Lens can receive this KUBECONFIG file through various methods. By going to the left panel, then clicking on “Catalog (app)ˮ button, you'll see three options.
Click on “Clustersˮ and, in the right bottom corner, there should be a Plus (ˮ+ˮ) button. Once you click it, youʼll see two options.
This means that you can either add the your KUBECONFIG file directly copy and pasting the content of the file in a field that is proper for this, or synching a specific folder where you store the files.
Lens also offers the cloud option to sync multiple configs even with other team members. This is not covered in this blog, but worth mentioning as it provides a lot value to Lens itself.
After the cluster is added, you can see it in the list of Clusters and, if connection allows it, permissions and more, you should be able to interact with it!
Now that we have our cluster setup, letʼs start reviewing what we can do in Lens.
General view
As soon as you jump into Lens with a cluster configured, in the left panel you can see different options like:
- Cluster: If you have proper Prometheus monitoring, Lens will be able to pull metrics from it and show them here.
- Nodes: Shows the nodes of your cluster and its metrics.
- Workloads: It has multiple options inside like Pods, Deployments, Daemon Sets, Stateful Sets, etc
- Config: For Config Maps, secrets, autoscalers, etc.
- Network: For services, ingresses, endpoints, Network Policies, etc.
- Storage: For persistent volumes, persistent volume claims, storage clases, etc
You can even see things like Namespaces, Events, or even a Helm section where you can interact with it there and do quick changes like updating the values on a chart release. You can read more about Helm here).
Another one I really like is Custom Resources, as these objects are not
Kubernetes native and is impressive to see how you can interact with them in Lens. It shows fields as columns from “arbitraryˮ objects based on its definition and show you the actual objects that are of these types.
This setup already gives you ton of visibility across the whole stack to see what's healthy, what's not, where the pressure could be, filter by namespace, etc.
Inspecting objects
One of the main features of Lens is its capacity to go from high level, reviewing metrics at the cluster level, to the low level stuff like inspecting at the object itself in YAML format and even doing changes right there.
As an example, let's take one Pod from our cluster and let's see its details in a nice view Lens provide:
Please note that we can see general information about the pod and its containers (in this case, just one container) and get information like the Status, which replica set created it, the node where it lives, the service account it has associate, the Pod ID, and may other things. Also we dig deeper on container details like its environment variables, ports, image URI, volumes, etc.
Although this high level detail view has the most important items of the pod, we can go even beyond by inspecting the actual YAML file that represents this object. By clicking Edit button in the detail view, another tab will be displayed with the YAML definition of our pod:
Doing changes here and saving them will result in immediate modification of the object in Kubernetes, which can be very convenient for quick updates on a quick situation.
Port forwarding
Just like with Kubectl, we could port-forward a service to use Lens as a proxy between our computers and the cluster. To do this we could simply go to a Network Services and opening the service of the application weʼll want to access and then click in "Forward" under the “Portsˮ section. We can then pick which port of our computer to use (or leave it empty if we want) and if we want to enable HTTPS before we start the port-forward:
In this example, I'm port-forwarding a front end application so I can troubleshoot it locally and interact with it as if itʼs deployed and running from my computer. Very handy for quick review or if there are no easy ways to access the application yet from wherever the Kubernetes cluster is deployed.
One of the things Iʼve personally suffered when doing port-forward is to remind “where is the terminal I had opened for this? I need to close that connection!ˮ. That problem is gone with Lens, because itʼll help me find where are the port-forward processes I have running and edit them (change the port and HTTPS, for example), stop them to use them later, or completely delete them. Lens will show me these processes in a list under Network Port Forwarding, so I can inventory what my processes are and decide what to do with them later.
Extensions
These features are already very enriching, because most of Kubernetes work goes into this. But thereʼs more!
Lens offers an extension layer where the community can develop their own extensions to add even more value to it.
For example, letʼs say I want a visual way to display my cluster and show relationships between the pods and the services. Some sort of Map that represents how our cluster is setup in a graphical way. For this, thereʼs an extension called Lens Resources Map Extension that allows you to do that (itʼs GitHub page is here https://github.com/nevalla/lens-resource-map-extension).
The documentation shows how the extension can be easily installed and have that functionality right away on our local computer.
Here we can see that, after installing that extension, thereʼs a new section in the left panel called Resources Map that, after opened, itʼll display our cluster with a Namespace filter on it (as it can have hundreds or thousands of objects, making it hard to view).
We can of course zoom into a specific area of interest and hover the items to get more detailed information, like in this example where we want to see the information about this specific pod.
And this is just one extension!
Thereʼs an official extension list that Lens promotes in this GitHub repository.
OpenLens
Lens is not an open source product (at least not any more), so the community has taken some cards here. One of them is OpenLens, which is the unofficial open source version of Lens. https://github.com/MuhammedKalkan/OpenLens. It provides a lot of the great features of Lens but without the login feature (important for security concerns, if any).
This project has gained popularity for its base, which is the same as Lens, but thereʼs no active development on it, so worth give it a try under specific circumstances.
Lens Pricing
Lens offers paid plans per month per user with added features to both the remote synching part and the local part.
At the time we write this block, the paid plans are:
Pro: $24.90 per user per month
Enterprise: $99.90 per user per month.
Some of the paid features are:
- CVE scanning and reporting
- User and Teams management
- Local Kubernetes Dev Cluster
- SSO
- SCIM user provisioning
- VDI support
- Offline mode
For detailed information on the whole difference lists, please visit https://k8slens.dev/pricing
Conclusion
Lens is definitely increasing in popularity, features, community, and respect. It has demonstrated that applications built on top of Kubernetes make easier, faster, and more precise the job of the administrators, developers, DevOps engineers, etc. that work on this container era.
It also shows that thereʼs business opportunities on top of Kubernetes still, as, according to their web page, Lens is a company with around $10 million US dollars in anual revenue, which gives certain level of maturity and confidence that its flagship product, Lens, is very well backed.
Feel free to give it a try!
