Lens & FreeLens — Making Kubernetes Visual

Post 14 mentioned Lens in two sentences and moved on, because the exam doesn't care about it. Your job does. This post is the deep dive that was missing: what Lens actually shows you, why the tool split into three names in the last few years, and the exact daily workflows where a GUI beats fifteen years of muscle-memory kubectl — without ever replacing it.

What Lens actually is

Lens is a desktop application that reads the same kubeconfig file kubectl already uses — the connection details, credentials, and context list for every cluster you talk to. It doesn't add a new way into your cluster; it points the exact same access at a window instead of a terminal. Everything it shows you, it's asking the Kubernetes API server for, the same way kubectl get pods does. There's no server-side agent to install, no extra permissions beyond what your kubeconfig already grants.

What you get back is a live, clickable map of the cluster: every namespace, every workload type, every Pod, updating in real time instead of frozen the instant a command returns.

The Lens window: workload browser, a Pod's live metrics panel, and a built-in terminal, all in one view. Screenshot: official Lens repo (github.com/lensapp/lens).

The 2026 landscape: Lens, OpenLens, and FreeLens

This part matters and it's easy to get wrong by reading an old tutorial: "just install Lens" isn't a complete answer anymore. The tool forked into three names, and which one you want depends on your budget and how much you mind a login screen.

• Lens (Lens Desktop, by Mirantis) — the original project, now a commercial product. It requires a free or paid Lens account to sign in, and gates newer features like an AI assistant and a cluster security scanner behind that account. Still actively developed, still the most polished option.
• OpenLens — used to be the open-source core that Lens Desktop was built on. After Mirantis restructured the project around accounts, OpenLens's own repository went quiet; its last release shipped in mid-2023 and nothing has followed. Treat it as dead — don't build a new habit around it.
• FreeLens — a community fork of OpenLens, started specifically to keep a genuinely free, no-account, open-source version alive. It's the actively maintained one now, and it's what most engineers reach for in 2026 if they don't want a subscription.

For this series, either works — the core workload/metrics/terminal experience described below is the same shape in both. If you'd rather not create an account just to look at Pods, start with FreeLens.

Installing FreeLens

# macOS (Homebrew)
$ brew install --cask freelens

# Windows (winget)
$ winget install Freelensapp.Freelens

# Linux (snap)
$ sudo snap install freelens --classic

FreeLens also ships AppImage, deb/rpm, and Flatpak builds if you'd rather not use a package manager. For the official commercial app instead, download it directly from the Lens website and sign in with a free account on first launch.

Feature tour

Once it's open, point it at a cluster — Lens auto-detects every context already in your kubeconfig, and EKS/AKS clusters if you're signed into those clouds — and it drops you into a sidebar organized almost exactly like the categories this series has already taught you: Workloads, Config, Network, Storage, Namespaces, Access Control, and Custom Resources.

The sidebar mirrors the object categories from this series — Workloads (Post 4, 13), Network (Post 5, 10), Storage (Post 7), Access Control (Post 11). Screenshot: official Lens repo.

• Multi-cluster switching. A dropdown in the corner swaps between every cluster in your kubeconfig — dev, staging, prod, a friend's minikube — with no kubectl config use-context typing and no risk of running a command against the wrong one by accident because you forgot which context was active.
• Workload browser. Click Workloads → Pods and get a sortable, filterable, searchable table of every Pod cluster-wide — the same information as kubectl get pods -A, but you can sort by RESTARTS or filter by namespace with a click instead of piping through grep.
• Live metrics graphs. Click into any Pod and its CPU, memory, network, and filesystem usage render as live time-series graphs, pulled from metrics-server or Prometheus if you have it wired up — the same data kubectl top pod gives you as one flat number, except you can watch the trend instead of polling.
• Built-in terminal and exec. A terminal panel at the bottom is pre-authenticated against whatever cluster/context is selected — click a Pod's exec icon and it drops you straight into a shell inside that container, no re-typing the Pod's full generated name.
• Live log streaming with search. Logs stream in real time with a search box and a follow toggle, and you can search across a workload's replicas without knowing which specific Pod name you need — a real upgrade over running kubectl logs -f against one Pod at a time.
• Helm chart browsing and installs. The Apps section lists installed Helm releases (Post 12's charts/values/releases) with their revision history, and lets you browse and install from configured repos through a form instead of hand-typing helm install flags.
• RBAC-aware views. Roles, ClusterRoles, and their Bindings (Post 11) get a dedicated, browsable view instead of reading raw YAML to figure out who can do what.
• Extensions. A plugin system lets you add cluster-specific tooling — cost dashboards, custom resource viewers, policy scanners — without it bloating the core app for everyone else.

Installing an extension: drop in a path or URL to a packaged extension, or browse the public extension list. Screenshot: official Lens repo.

Lens vs k9s vs raw kubectl

Post 14 already introduced k9s as "the terminal-UI middle ground." Here's the fuller picture now that you've seen what each one actually buys you.

None of these retire the others. Most working engineers keep all three within reach and pick per-task.

Daily workflows this actually speeds up

Spotting a CrashLoopBackOff visually. Post 14 taught you to read the STATUS column with kubectl get pods. In Lens, a Pod in CrashLoopBackOff shows up with a red status indicator in the sortable table across every namespace at once — no re-running get pods -A and scanning text for the one row that's wrong. Click it, and the Events tab and the log stream are one click away, no re-typing the Pod's generated name into a new command.

Tailing logs across every replica of a Deployment. With kubectl, tailing five replicas of the same Deployment means either five terminal tabs or a label-selector trick most people don't remember under pressure. In Lens, open the Deployment, and its logs view already spans all its Pods, searchable as one stream.

Switching between dev, staging, and prod without a slip. The single most dangerous mistake in Post 14's exam-trap section — running a command against the wrong context — has a real-world equivalent that's far worse than losing exam points. The cluster switcher shows the active cluster's name in the window at all times, which is a much harder thing to lose track of than a context name buried in your shell prompt.

For the one fact about Lens/FreeLens that actually matters on exam day — that neither is available in the CKA terminal — see Post 14's exam-trap callout; it hasn't changed, and it's not repeated here.

Next up: two reference posts for the job hunt itself — a deep, categorized bank of Kubernetes interview questions, followed by the scenario-based troubleshooting questions that actually separate candidates in 2026 interviews.