It’s easy to get going with Lens on virtually any computer with a graphical desktop environment (Linux, Mac, or Windows). The only real requirement is that you need one or more pre-existing Kubernetes clusters for Lens to look at. (Otherwise, what’s the point?)
Specifically, Lens talks to the Kubernetes API via kubectl, so you’ll need connectivity to your cluster(s) from the computer on which you want to install Lens to port 6443 of the cluster controller using https. As long as you have the kubeconfig for your cluster stored locally (and Lens can help you find that), you should be good to go.
The cluster itself can be pretty-much anywhere and derive from any source. You can use Lens to control local clusters (such as Docker Kubernetes Service clusters running on your laptop), or remote clusters on bare metal, private, or public clouds. Lens adapts automatically to manage different recent versions of Kubernetes, so dealing with multiple generations of Kubernetes cluster is no problem.
Don’t have a cluster yet? Happily, that’s easy too, because you can install a Docker Enterprise cluster quickly, using Launchpad. In fact, Launchpad and Lens companion very well, since Launchpad is available for Linux, Mac, and Windows, too.
Basic docs can be found at the Lens repository on GitHub. Downloadables are available on the releases page. Installation on Windows (via .exe) and Mac (via .dmg) is easy; just download those files to the local machine and run them.
On Mac, you can also:
brew cask install lens
to get the latest version.
For Linux, Lens is available via snap or packaged as an AppImage, which we recommend for its convenience. If you haven’t encountered AppImages before (plenty of frequent Linux users haven’t – don’t feel bad), AppImage tech provides a way of packaging application dependencies together in executable binaries that will run on pretty much any Linux machine.
To use the AppImage, just download the release binary to a safe place on your system, make it executable, and run it from the command line or your desktop’s application browser. Because Lens is a desktop application, you don’t even need to be particularly concerned about making sure to save the Lens binary somewhere on your CLI execution path, because the first time it runs, it inserts an icon in your ‘Favorites’ bar that you can pin there to make subsequent execution easy.
Using a standard browser, this is pretty simple, but you can also do it from the command line. To do so, right-click on the link to the AppImage on the Releases page and select Copy link address, then:
- Make a lens directory
- cd into it
- download the binary there using wget, curl, or another tool
- make the binary executable, and
- run it, prefixing the file name with ./ to tell bash that it needs to look in the local directory instead of elsewhere on your execution path.
mkdir lens cd lens wget https://github.com/lensapp/lens/releases/download/v3.5.2/Lens-3.5.2.AppImage chmod +x Lens-3.5.2.AppImage ./Lens-3.5.2.AppImage
Lens checks for updates, then opens on your desktop. Right-click on its icon in your Favorites bar and click Add to Favorites to make it more easily accessible.
When launching Lens from a Favorites icon, be sure to just click once for each instance of Lens you want to run. Especially on slowish virtual machines, Lens takes a few moments to start up (check for updates, load contexts, and so on), so it’s easy to get half a dozen instances launching at once if you get impatient and click multiple times.
Configuring Lens to work with your cluster(s)
Lens makes configuration very simple. Click Add Cluster in the File menu, and Lens pops up a list of all the kubeconfigs it’s found on your local system. Pick one, and Lens self-configures — creating a context for that cluster so it can manage (for example) the particular version of Kubernetes API it uses, and other details.
If you can’t find your desired kubeconfig in the list, it may be that you haven’t yet downloaded an authentication bundle for that cluster. (Perhaps it was recently deployed, or you deployed it on a public cloud service). For Docker Enterprise clusters, just browse the Universal Control Plane webUI, click on Admin>My Profile>Client Bundles, generate and download a new client bundle, unzip it, and find the kube.yml file; that’s the one Lens needs.
Before manually adding the cluster, it makes sense to use kubectl to make sure the config is working and you can reach the cluster. For Docker Enterprise, this is easy — just source the env.sh from the client bundle, to authenticate:
Then run any kubectl command, such as:
kubectl get pods --all-namespaces
You can then list and copy the kube.yml. In Lens, click on Custom in the kubeconfig pick list, then just paste the YAML into the window and click Add Cluster.
In moments, Lens will populate its context, add your cluster, and show its details in the main window. The only thing you won’t see, at first, is cluster metrics, which is the next thing we’ll set up.
Enabling Lens metrics
Lens can run a small Prometheus instance in your cluster, giving you metrics for nodes visible to you according to RBAC permissions on your account. Admins, of course, will be able to see metrics for everything.
(If you’re already running Prometheus, you can export metrics from this instance to Lens; full instructions are accessible from within the application.)
To set up the internal Prometheus instance, right click on the cluster icon in Lens’ left-hand menu and select Settings, then scroll down to where it says Prometheus to connect an existing Prometheus instance, or a little further, under Features/Metrics, where you can just click Install to have Lens create an instance for you.
Either way, Lens connects to your Prometheus, and cluster metrics automagically appear on your cluster dashboard.
Lens makes all the objects and abstractions in each cluster instantly accessible to you. Take a look at the left-hand menu, and try clicking on Workloads. You get a highly browsable submenu (and an alternative, tabbed display) of everything, including handy, color-coded summary graphics that will clue you to any issues.
Drill down anywhere, right-click on the submenu associated with any line-item, and you can edit its YAML in Lens’ built-in editor, then Save to reapply it. Devs working with private clusters can quickly iterate live changes and check results. Drilling in further, Lens lets you access terminals inside running containers, and retrieves container and pod logs directly, with one click, for easy review.
If you’re working on a more infra-as-code basis, Lens also lets you open any number of terminals, letting you quickly browse a local repo for files you need, for example, then push changes to git, issue docker commands, or pop files into VScode or ATOM (or whatever IDE or editor you prefer) for editing, versioning, and careful reapplication.
Where to go from here
The best place to go for inspiration on more advanced use of Lens is the community slack channel (https://k8slens.slack.com), a link to which is provided in the About menu in Lens itself.
Please try Lens, let us know what you think, and what you’d like to see covered in upcoming Lens tutorials. We’re here for you!