Francesco Oghabi

Lens: The Kubernetes IDE That Changes Your Life (Almost)

Practical guide to Lens, the IDE for managing Kubernetes clusters. Setup, features, and when to prefer it over the CLI.

I'm a CLI fan. kubectl is powerful, k9s is fantastic, and most of the time I don't need anything else. But then I started managing 6 clusters simultaneously, and things got complicated.

Lens entered my workflow almost by accident, during a particularly frustrating debug session. A colleague told me "try looking at the logs with Lens, it's more convenient". He was right. Since then I use it daily, not as a CLI replacement but as a complement.

What is Lens

Lens is a desktop application that gives you a graphical view of your Kubernetes clusters. Think of it as an IDE, but instead of writing code, you manage Kubernetes resources.

You can see pods, deployments, services, configmaps, secrets — everything in the cluster — in a navigable interface. You can see logs in real-time, shell into containers, edit resources on-the-fly. Everything you would do with kubectl, but with a graphical interface.

The base version is free and open source. There's a paid Pro version with extra features (teams, enterprise security), but for most uses the free version is enough.

Installation

Nothing complicated:

# macOS
brew install --cask lens

# Linux (Snap)
sudo snap install kontena-lens --classic

# Linux (AppImage)
# Download from https://k8slens.dev/

# Windows
# Download the installer from the website

On first launch, Lens automatically reads your ~/.kube/config and imports all configured clusters. If you use multiple contexts, you see them all in the sidebar.

Why I Use It

I'm not here to sell you Lens. There are things it does well and things it does less well. Here's where I find it useful.

Overview

When I need to understand the general state of a cluster, Lens gives me an immediate dashboard. How many pods running, how many pending, how many failed. CPU and memory usage. Nodes and their state. In kubectl I would have to run a series of commands to get the same information.

Multi-Container Logs

Pods with sidecars are a nightmare for logs. With kubectl you have to specify the container, grep, keep multiple windows open. With Lens I see the logs of all containers in the pod in a single view, with synchronized timestamps. When debugging something like Istio with its envoy sidecars, this saves me hours.

Navigation Between Resources

"Which deployment manages this pod? Which namespace is that deployment in? What service exposes it?" With Lens I click and navigate. Resources are linked, I can jump from one to another. With kubectl I have to make separate queries and keep everything in mind.

On-the-fly Editing

Sometimes I need to change something quickly — a resource limit, an environment variable, an annotation. With Lens I click Edit, change the YAML, save. Done. With kubectl I have to do kubectl edit, open vim/nano, save, hope I didn't mess up the indentation.

Integrated Terminal

Lens has an integrated terminal that opens shells directly into containers. kubectl exec -it works the same, but in Lens it's a right-click on the pod. Less typing, same result.

Where I Don't Use It

It's not all roses. There are scenarios where Lens isn't the best choice.

Automation

If you need to script something, Lens doesn't help. It's an interactive tool, it doesn't have a CLI. For automation, kubectl and SDKs remain the only option.

Bulk Operations

Need to delete 50 pods that match a certain label? kubectl delete pods -l app=broken is instant. In Lens I would have to select them one by one. For operations on many resources, the CLI always wins.

Minimal Environments

If I'm working on a remote server via SSH without X forwarding, Lens doesn't run. k9s does, because it's terminal-based. For headless environments, k9s is the required choice.

Huge Clusters

With very large clusters (thousands of pods), Lens can become slow. It has to fetch and render all those resources. The CLI scales better because you can filter server-side.

Configuring Multiple Clusters

The use case where Lens shines the most is multi-cluster management. If you work with multiple environments (dev, staging, prod) or multiple clients, having everything in one place is convenient.

Each cluster appears in the sidebar. You can group them into categories (by client, by environment, however you prefer). The theme color can be different for each cluster — I use red for prod, so I don't make mistakes by accident.

To add a cluster, it just needs to be in your kubeconfig. If you use separate kubeconfigs, you can import them from File > Add Cluster.

# Example: adding a cluster from a separate file
# In Lens: File > Add Cluster > select the file

Useful Extensions

Lens supports extensions. Some that I use:

Lens Resource Map — visualizes relationships between resources as a graph. Useful for understanding complex architectures.

Starboard — integration with the Starboard security scanner. Shows vulnerabilities directly in Lens.

Prometheus — if you have Prometheus in the cluster, you can see metrics directly from the interface.

Extensions are installed from File > Extensions. There aren't thousands, but those that exist are generally useful.

Lens vs k9s: When to Use What

The question I always get: "So k9s or Lens?"

Honest answer: both, for different things.

I use Lens when:

  • I need to explore a new cluster and understand what's in it
  • Debugging problems that require seeing many things together
  • Demos or pair programming (the graphical interface is easier to follow for others)
  • Multi-container pod logs
  • Working with multiple clusters and jumping between them often

I use k9s when:

  • I'm SSH'd into a remote server
  • Quick operations where I already know what to do
  • Resource-limited environment
  • I prefer not to take my hands off the keyboard

I use kubectl when:

  • Scripting and automation
  • Bulk operations
  • Things that don't require exploration

There's no right answer. They're different tools that do similar things in different ways. Having both in the toolkit doesn't hurt.

Tips and Shortcuts

Some tricks I've learned:

Ctrl/Cmd + P — Quick open, search for any resource in the cluster. Like Cmd+P in VSCode.

Ctrl/Cmd + Shift + P — Command palette. Access features without navigating menus.

F5 — Refresh. Sometimes Lens doesn't update automatically, this forces a refresh.

Double-click on a pod — Opens details. Faster than navigating menus.

Right-click anywhere — Context menu with relevant actions. Shell, logs, edit, delete, etc.

In Preferences you can configure the theme (dark is default and I recommend it), the preferred terminal for shell, and various other things. It's worth exploring the options.

Common Problems

Lens doesn't see my clusters — Check that kubeconfig is correct and that contexts work with normal kubectl. If kubectl works and Lens doesn't, try restarting Lens or reimporting the kubeconfig.

Lens is slow — With large clusters it happens. Try disabling metrics in the cluster settings, or use filters to see only the namespaces you're interested in.

Logs don't update — Sometimes live log streaming gets stuck. Click refresh or close and reopen the log view.

Permission errors — Lens uses the same credentials as kubectl. If you don't have permission to see certain resources, Lens will show errors. It's not a Lens bug, it's your RBAC.

Conclusion

Lens doesn't replace the CLI. Nothing does. But it's an excellent complement for certain tasks, especially exploration and debugging.

If you manage Kubernetes clusters daily, try it. It's free, installs in a minute, and in the worst case you uninstall it. In the best case, it becomes part of your workflow and saves you time.

Don't expect magic. It's a tool, not a solution. But it's a well-made tool, and that counts.

The best tool is the one you use. If you prefer the pure CLI, that's fine. If Lens helps you, use it.