Back
Table of Contents
Engineering Tips

What is Kubernetes Lens?

Nov 08, 2021 / Updated: Mar 10, 2026

What is Kubernetes Lens?
Lightrun Team
Lightrun Team
11 mins read

As a DevOps Engineer, one day you’re performing magic in the terminal, settling clusters, and feeling like a god. On some other days, you feel like a total fraud and scam. Errors and bugs appear from everywhere, you don’t know where to start, and you don’t know where to look. Sadly, days like this come far too often. To be more specific, what often causes these bad days is none other than Kubernetes itself. While Kubernetes is the force and magic that manages your clusters, it can also be your bane.

Kubernetes is a portable, extensible open-source system for automation, deployment, scaling, and management of containerized applications and services. It is a cluster management tool that helps to abstract machines, storage, and networks away from their physical implementation. Almost everyone in the DevOps community uses Kubernetes.

However, one major problem with Kubernetes is that it comes with a vast amount of moving parts and certain complexities, such as handling clusters, scaling, storage orchestration, batch execution, and more. This all hinders mainstream developer adoption.

Another problem with Kubernetes is the use of command-line CLIs that consume and retrieve multiple files, and the use of tools like kubectl that might be good for some, but which can be overwhelming for others who may prefer GUIs.

In this article, you will learn what Kubernetes Lens is, what it does, and why it is useful.

About Kubernetes Lens – The Kubernetes IDE

Kubernetes Lens is an effective, open-source IDE for Kubernetes. Lens simplifies working with Kubernetes by helping you manage and monitor clusters in real time. It was developed by Kontena, Inc. and then acquired by Mirantis in 2020, who then open-sourced it and made it available to download for free.

Lens is a standalone application and can be installed on macOS, Windows, and some Linux flavors. With Kubernetes Lens, you can talk to any Kubernetes cluster, anywhere.

Kubernetes Lens is aimed at developers, SREs, and software engineers in general. It is most likely the only platform you will need to manage the cluster system of your Kubernetes. It is backed by a number of Kubernetes and cloud-native ecosystem pioneers such as Apple, Rakuten, Zendesk, Adobe, Google, and others.

Why Kubernetes Lens?

There are a variety of features that make Kubernetes Lens a highly attractive tool. Here is an overview of a few of them.

Cluster Management

Managing clusters in Kubernetes can be difficult, but with Kubernetes Lens, you can work on multiple clusters while maintaining context with each of them. Lens makes it possible to configure, change, and redirect clusters with one click, organizing and revealing the entire working system in the cluster while providing metrics. With this information, you can easily and very quickly edit changes and apply them confidently.

Adding a Kubernetes cluster to Lens is easy. All you need to do is point the local/online kubeconfig file to Lens and it automatically discovers and connects with it.

With Lens, you can inspect all the resources running inside your cluster, ranging from simple Pods and Deployments to the custom types added by your applications.

Built-In Visualization and Metrics

Kubernetes Lens comes with a built-in Prometheus setup that has a multi-user feature that gives role-based access control (RBAC) for each user. That means that, in a cluster, users can only access visualizations they have permission to access.

In Lens, when you configure a Prometheus instance, it is able to display metrics and visualizations about the cluster. To add Prometheus to Lens if it is not already installed, follow these steps:

  1. Right-click on the cluster icon in the upper left corner of the UI.
  2. Click Settings.
  3. Under Features, find and select the Metrics stack.
  4. Then click Install to install Prometheus stack (This may take a couple of seconds or minutes.)

Prometheus stack

After the installation, Lens autodetects Prometheus for that cluster and then begins to display cluster metrics and visualizations. You can also preview the Kubernetes manifests for Prometheus before you apply them.

With Prometheus, you get access to real-time graphs, resource utilization charts, and usage metrics such as CPU, memory, network, requests, etc., which are integrated into the Lens dashboard. These graphs and metrics are shown in the context of the particular cluster that is viewed at that moment, in real time.

Usage metrics

Kubernetes Lens also integrates with Helm, making it easy to install and manage Helm charts and releases in Kubernetes.

Helm charts

Kubernetes Lens allows you to use available Helm repositories from the Artifact Hub and automatically adds a bitnami repository by default if no other repositories are already configured. If you need to add any other repositories, those can be added manually via the command line. Do note that configured Helm repositories are added globally to the user’s computer, so other processes can see those as well. All charts from configured Helm repositories will be listed in the Apps section.

Lens Extensions

Kubernetes Lens Extensions allow you to add new and custom features and visualizations to accelerate development workflows for all the technologies and services that integrate with Kubernetes. To use Lens Extensions, go to File (or Lens on macOS) and then click Extensions in the application menu. You can install extensions in three ways on Lens:

  1. Installing the extension as a .tgz file, then dragging and dropping it in the extension management page will install it for you.
  2. If the extension is hosted on the web, you can paste the URL and click Install, and Lens will download and install it.
  3. You can also move the extension into your ~/.k8slens/extensions (or C:Users.k8slensextensions) folder and Lens will automatically detect it and install the extension.

Kubernetes Lens also allows you to script your own extensions with the Lens APIs. They support adding new object details, creating custom pages, adding status bar items, and other UI modifications. Extensions can be published to npm to generate a tarball link that the Kubernetes Lens install screen can reference.

Extensions

GUI over CLI

Lens provides a way to manage Kubernetes through GUI because managing multiple clusters across various platforms and substrates means deciphering the other complexities of multiple access contexts, modes, and methods for organizing clusters, components, nodes, and infrastructure. Solving all these from the command line is difficult, slow, and fallible. This is due especially to the constant increase in the number of clusters and applications, not to mention their configurations and requirements.

With the Kubernetes Lens GUI, you can do several things:

  1. You can add clusters manually, by browsing through their kubeconfigs and can immediately identify kubeconfig files on your local machine.
  2. With Lens, you can put these clusters into workgroups in whatever way you interact with them.
  3. Lens provides visuals on the state of objects such as including Pods, Deployments, namespaces, network, storage, and even custom resources in your cluster. This makes it easy to identify and debug any issue with the cluster.

For the CLI lovers, Lens doesn’t leave you high and dry. You can also invoke its built-in terminal and execute your favorite kubectl command line.

Lens Terminal

The built-in terminal uses a version of kubectl that is API-compatible with your cluster. The terminal can:

  1. Automatically detect your cluster version and then assign or download the correct version in the background.
  2. Maintain the correct kubectl version and context as you switch from one cluster to another.

Kubernetes Lens terminal

Integrations

Lens gives you access and allows you to work with a wide variety of Kubernetes clusters on any cloud, all from a single, unified IDE. The clusters may be local (e.g., minikube or Docker Desktop) or external (e.g., Docker Enterprise, EKS, AKS, GKE, Rancher, or OpenShift). Clusters may be added simply by importing the kubeconfig with cluster details.

Lens Spaces

Kubernetes Lens promotes teamwork and collaboration via this feature called Spaces. It is a collaborative space for cloud-native development teams and projects. With a Lens space you can:

  1. Easily organize & access your team clusters from anywhere: GKE, EKS, AKS, on premises, or a local dev cluster.
  2. Easily access and share all clusters in a space securely.

Cluster Connect

In Kubernetes, sharing access to the different clusters is difficult. When working as an administrator with different providers that require you to use the same tools, or when trying to get access to kubectl files, make those files work with your kubectl. Then connect the kubectl file to the same network with the target cluster API. However, you will need to use a VPN to be in the same network as the provider, and in some cases, you will also need to use different IAM providers. These are security risks because users might bypass security best practices.

Lens uses Cluster Connect to share access to the cluster without compromising the security of the cluster.

With Kubernetes Lens Spaces, you can send and receive invitation access to other clusters. All invitations are aggregated and then exposed to you using the Lens Kubernetes proxy. To access the clusters, you download the Cluster Connect agent in the desired cluster. The agent then allows you to connect to clusters from Lens Spaces using end-to-end encryption to secure connections between you and the clusters, eliminating the need for a VPN and the need for an inbound port to be enabled on the firewall. This also means you can access and work with their Kubernetes clusters easily from anywhere.

Cluster Connect is based on the BoreD OSS software. Check out the documentation to learn more about Cluster Connect.

Kubernetes Lens terminal

Multiple Workspaces Management

Lens organizes clusters into logical groups called workspaces. This helps DevOps and SREs who have to manage multiple (even hundreds of) clusters. Usually, a single workspace contains a list of clusters and their full configuration.

Kubernetes Lens is one of the most effective Kubernetes UIs you’ll ever use. It supports CRD Helm 3 and it has a friendly GUI. Lens will, of course, also handle the cluster settings for you.

Recap of Key Features for Beginners

Kubernetes Lens provides situational awareness for everything that runs in Kubernetes, lowering the barrier to entry for developers just getting started. It is an ideal solution for many reasons, including:

  1. It provides the confidence that your clusters are properly set up and configured.
  2. There is increased visibility, real-time statistics, log streams, and direct troubleshooting facilities.
  3. The ability to organize clusters quickly and easily totally improves productivity and business speed.
  4. EKS, AKS, GKE, Minikube, Rancher, K0s, etc.—any Kubernetes you might be using—all work with Lens. You only need to import the kubeconfigs for the appropriate clusters.
  5. Kubernetes Lens is built on an open source with an active community, supported by Kubernetes and cloud-native ecosystem pioneers.

Debugging Kubernetes in Production

Kubernetes Lens consists of numerous great features, as this article has shown you. It is an independent app much unlike the built-in Kubernetes dashboard. If you use Kubernetes and appreciate the variety of its GUI, then you should definitely check out Kubernetes Lens.

For developers looking to get visibility into their code regardless of environment or deployment type, from monolith to microservices, consider Lightrun.

For advanced users of the Kubernetes stack, Lens can’t provide the type of observability and debugging capabilities that Lightrun can for production applications in real-time. With Lightrun, developers can:

  • Troubleshoot Kubernetes easily by dynamically adding logs lines
  • Add as many logs as you need until you identify the problem
  • Multi-instance support (microservices, big data workers) using a tagging mechanism
  • Explore the call stack and local variables in any location in the code in the same version they occurred in
  • Traverse the stack just like a regular breakpoint
  • Add snapshots in the IDE you’re already using, easily
  • Need more snapshots? Add as many as you need. You’re not breaking the system

Naturally, Lightrun offers a very robust yet easy to use way of monitoring the K8S stack, which you can try out yourself.

Lightrun is a secure, developer-native observability platform that enables you to add logs, snapshots, and metrics directly into your source code or application, in any environment. It really is the next level of Kubernetes Lens, allowing you to troubleshoot Kubernetes directly from any IDE.

With Lightrun, you can debug monolith microservices, Kubernetes, Docker Swarm, Big Data, and serverless in real time. Be sure to check out Lightrun for all of your cluster management needs.

Related articles

Black Friday 2024: What to Expect

Black Friday, the traditional kickoff to the holiday shopping season, is set to make waves in 2024 with projected sales reaching an impressive $10.8 billion—a 9.9% increase from last year according to Statistics.blackfriday analysts. According to the same team, Cyber Monday sales in 2024 are expected to reach $13.2 billion—a 6.1% increase from 2023.

Both events in sum are expected to generate $24 billion in sales. A major contributor to this growth is the increasing number of consumers who prefer to shop online. As consumer behaviors evolve to favor online shopping, retailers are expected to invest more in their online infrastructure, user experience, and platform reliability to meet this projected demand.

More traffic means more potential revenue, but it also means more queries, more transactions, and more potential problems. As an online retailer, you need to be well-prepared from a technical standpoint to ensure that you don’t miss out on any potential sales.

Amazon Prime Day 2018: A Prime Example For How Things Can Go Wrong

Q4 is a critical time for businesses, and developers are often under immense pressure to ensure that their systems are up and running. The last thing you want is for your website to crash during the busiest shopping season of the year. Poor performance means lost revenue, and problems can quickly escalate into a PR nightmare.

You’ve likely heard about the infamous Amazon Prime Day crash in 2018, which reportedly cost the company an estimated $100 million in lost sales. Despite the charm of the “Dogs of Amazon” error pages, they couldn’t mitigate the damage. Cute error messages are no substitute for a robust, well-prepared platform.

Some unofficial post-mortems of the Prime Day crash suggest that the root cause was a failure in the auto-scaling system, which left Amazon scrambling to manually add server capacity. The internal system “Sable,” Amazon’s e-commerce storage and computation platform, struggled under the surge—which led to a failure across the platform. Some experts speculate that misconfigurations or software bugs in scaling systems magnified the issue, forcing Amazon to temporarily shut down international traffic to the site according to CNBC.

In all cases, the lesson is clear: impredictable issues can arise, and you need to be prepared.

If you google “How to prepare for Black Friday for developers,” you’ll find a plethora of articles that will tell you to “test your system,” “monitor it,” “add autoscalability to your infrastructure,” and “secure your code.” While these may be good pieces of advice, they touch only the surface of the problem as they are not shifting left enough to prevent the issues from happening in the first place.

In sports, for example, achieving peak performance isn’t the result of a single training session but rather a dedicated regimen of practice, evaluation, and adjustment over time. Similarly, preparing for Black Friday is not a one-time event, but rather a continuous process that requires iterative improvements based on feedback. The earlier this feedback is received, the better.

Shift-Left Everything: The Early Bird Catches the Worm

Performance should be a first-class citizen in your development process. That’s why it should not be an afterthought, but rather a core part of your development cycle. A software development lifecycle includes several stages, such as planning, coding, testing, and deployment. You should be thinking about performance from the early stages of development. The problem is that performance testing is often associated with the staging and production environments—which is too late in the development cycle.

By shifting performance testing to the left, you can identify and fix performance issues early in the development process. This approach allows you to catch performance bottlenecks before they become critical issues.

Performance problems can be triggered by a variety of factors, such as bad capacity planning, downsized infrastructure, inefficient code, slow database queries, extreme edge cases, or code that doesn’t scale well. All these issues can be identified early in the SDLC if you have the right tools and processes in place.

For example, with Lightrun, you can dynamically add a log to a specific function suspected of causing slow database queries, without halting or redeploying the application. This enables you to pinpoint the exact query, analyze its execution time, and resolve the issue during the development phase, long before it reaches staging or production.

Using Lightrun’s snapshot feature, you can also capture the state of your application at a specific point in time. Let’s say you have an issue that only occurs under certain conditions (e.g., a specific event or input). You can capture the state of your application after reproducing the issue using a snapshot that can be added directly from the Lightrun IDE plugin. This snapshot not only captures the trace of the application but also the state of the variables at that point in time. This allows you to deeply analyze the issue from the inside and fix it accordingly. You can also export the snapshot and share it with your team members for further analysis. All of this happens from the comfort of your IDE while you’re coding. The best part is that you capture logs and traces from any environment, including your development, testing, staging, and production environments without any code changes on the remote server.

Another crucial, often overlooked practice you should consider is observability.

Observability is the ability to understand what’s happening inside your system based on external outputs. An e-commerce platform is responsible for different types of operations, including user authentication, product search, transaction processing, and more. Observability allows you to monitor these operations and understand how they are performing from the user’s perspective. Using logs, metrics, and traces, developers can gain useful and actionable understanding of their applications’ and infrastructure’s behavior.

Nowadays, observability is a key practice, but its implementation is often not quite right in many organizations. First, not understanding what to “observe” can lead to a lot of noise and irrelevant data – a sheer volume of data makes it challenging to identify the root cause of a problem. Second, observability is often associated with the production environment, which is a late phase in the SDLC. The first problem creates a siloed approach to observability where developers are less likely to use the data to improve their code. The second problem leaves developers out of the loop when it comes to understanding how their code behaves in production.

Instead of this approach, observability should be a part of the development process from the beginning. But here’s the catch: if developers have to wait for a new deployment on the testing or staging environment to add a log or a metric, a new bottleneck is created. A solution to this, besides having a continuous deployment pipeline, is to use a tool that allows them to instrument their code on the fly without the need to redeploy their applications. This is also known as “dynamic instrumentation” and it’s a key feature of Lightrun.

According to a 2018 Stripe report, developers spend an average of 17.3 hours per week on maintenance and debugging issues. This amounts to $300 billion in lost developer productivity every year. By shifting left observability, performance testing, and debugging, you can reduce this number and save valuable time and resources.

Debugging in Production: No Longer a Meme

Shifting left observability, performance testing, and debugging is the secret sauce to a successful Black Friday. Small incremental changes with continuous feedback and early feedback are the ingredients to a successful recipe. However, incidents can still happen, and when they do, you need to be able to debug in production as close to the problem as possible.

Some years ago when someone mentioned “debugging in production“, it was often seen as a joke or the worst-case scenario. Today, it’s a regular practice for many organizations. The reason is simple: the production environment is the most complex and the most realistic environment. If a bug or a performance issue escapes your team despite all the early stages of testing, the early feedback, and the continuous improvement, you need to be able to debug it in production. Chances are that the issue is an edge case that only occurs in production.

Traditionally, debugging in production was a scary and unsafe process. The fastest way to do it was SSHing into the server and adding a print statement in the code. This is not only unsafe but also inefficient. It’s unsafe because you’re modifying the code in the production environment, which can lead to unexpected results. It’s inefficient because you need to redeploy the application to see the changes, which can take time and may disrupt the user experience.

Here’s when Lightrun once again comes to the rescue. A developer can add a line of log to the code in the live production environment without halting the application or redeploying it. Imagine the following scenario: you have a performance issue that only occurs in production. You can add a log to the suspected function or line of code, capture the logs, and analyze them in real-time to identify the root cause of the problem. Similarly, you can add a snapshot to capture the state of the application at a specific point in time and under specific conditions.

All you have to do is to install the Lightrun plugin in your IDE – available for IntelliJ, PyCharm, WebStorm, VS Code and select web IDEs – connect it to your production environment, and start debugging. It’s that simple.

Reduce the Mean Time to Resolution (MTTR)

It may be too late to prevent all performance issues from happening, but you can still reduce the time it takes to resolve them. The Mean Time to Resolution (MTTR) is a key KPI that measures the average time it takes to resolve an issue. The longer it takes to resolve an issue, the more revenue you lose.

To understand how to calculate the MTTR, let’s consider the following formula:

MTTR = (Total time to resolve issues) / (Total number of repairs

If you have a high MTTR, it means that you’re spending too much time resolving issues. Serious engineering teams aim to reduce the MTTR as much as possible. In general, there’s no good or bad value for the MTTR; this depends on the context of the organization, the criticality of the application, and the complexity of the issues. But as a rule of thumb, if your team is spending more than 3 hours per issue, you may want to consider improving your processes. This is especially true during Black Friday when every minute counts. According to ECDB, as an example, online shopping peak hours in some countries (e.g., Germany, UK) are between 8 pm and 10 pm. If your MTTR is 3 hours and your application crashes at 8 pm, your team will only start to resolve the issue at 11 pm. This means that you were down during all the peak hours.

Lightrun can help you reduce your MTTR. For example, Lightrun capabilities have enabled InsideTracker developers to diagnose and resolve application issues in real-time, saving valuable debugging time. Their MTTR improved by 50%, resulting in dozens of hours saved each month. Prior to using Lightrun, InsideTracker developers were unable to troubleshoot or access remote Kubernetes environments from their local machines in an easy, straightforward way. This led to long and inefficient debugging sessions that required hotfixes and redeployments taking hours.

What’s Next?

Lightrun provides a suite of powerful features that help developers quickly identify and resolve issues in production environments but before reaching production, Lightrun can also help you shift-left observability, testing, and debugging.

The tool offers a range of features that can help you improve your development process, including:

Lightrun empowers not only developers but also DevOps, SREs, Platform Engineers, and other stakeholders to improve their development process and as a result, catch issues early, reduce the MTTR, and improve the overall performance of their applications.

Ready for Black Friday 2024? If not, Lightrun is here to help: