Best of 2021 – Why We Need Lens as a Kubernetes IDE
As we close out 2021, we at Container Journal wanted to highlight the most popular articles of the year. Following is the twenty-first in our series of the Best of 2021.
There’s been a lot of talk lately about the open source Lens project, the “Kubernetes IDE.” That’s a pretty new software category, but there are plenty of contenders for the title already in the wild. Why so?
DevOps folk are now creating modern applications with distributed architectures and many moving parts, iterating locally, then pushing these out to a sequence of scaled Kubernetes clusters for test, staging and production via CI/CD and version control. Operators are using the same apparatus to build, scale and LCM clusters on a growing range of infrastructures.
Everything is ‘X as code’—and everybody is coding. Core tools (e.g., VScode, Git, Jenkins, etc.) and workflows (e.g., GitOps) are widely used across all IT job descriptions. But still, there’s no consensus about how to scale interactions around the Kubernetes API and cluster management.
This is a big problem, particularly since a) almost everyone now needs to do this stuff; b) usually on at least several clusters; and c) enterprises seem to have decided (for the moment, anyway) that more small, task-dedicated clusters are better than a few big ones. These days, it’s increasingly common to meet operators responsible for hundreds of clusters. I have (counting, because the number changes daily) three multi-node Kubernetes clusters in my house.
So what’s the problem, exactly? Using Kubernetes means interacting with clusters using CLIs that consume and retrieve files—many, many files, in many contexts—describing cluster, resource and application states. Managing many Kubernetes clusters—perhaps across many different platforms and substrates—means wrangling the additional complexity of diverse access contexts, modes, secrets and methods for reaching clusters, components, nodes and infrastructure.
Doing all this straight from the command line is difficult, error-prone and slow—slower still as the number of clusters and applications grows and their configurations and requirements diverge. Software, thankfully, can solve some of these problems. As coders, we’re familiar with the notion of an Integrated Development Environment (IDE), which marshals information and tools for us, helps us work unerringly across different contexts and hides pointless complexity by automating common tasks.
Lens, now arguably the most widely used Kubernetes IDE, does all this and more. It’s one of the fastest-trending Kubernetes projects out there, with around 7,000 stargazers on GitHub. It’s fully open source under the MIT license.
How Lens Solves These Problems
The current version of Lens vastly improves quality of life for developers and operators managing multiple clusters. It installs on Linux, Mac or Windows desktops, and lets you switch from cluster to cluster with a single click, providing metrics, organizing and exposing the state of everything running in the cluster, and letting you edit and apply changes quickly and with assurance.
Lens can hide all the ephemeral complexity of setting up cluster access. It lets you add clusters manually by browsing to their kubeconfigs, and can automatically discover kubeconfig files on your local machine. You can manage local or remote clusters of virtually any flavor, on any infrastructure or cloud. You can also organize clusters into workgroups any way you like and interact with these subsets. This capability is great for DevOps and SREs managing dozens or hundreds of clusters or just helping to manage cluster sprawl.
Lens installs whatever version of kubectl is required to manage each cluster, eliminating the need to manage multiple versions directly. It works entirely within the constraints each cluster’s role-based access control (RBAC) imposes on identity, so Lens users (and teams of users) can see and interact only with permitted resources.
Lens organizes Kubernetes objects (nodes, namespaces, virtual services, deployments, statefulsets, pods and so on) coherently in browsable trees, making it easy to find, explore and edit related entities in context. It connects you with editable resources via context-aware terminals that let you use whatever workflow and tooling suit the task(s) at hand, from using editors and version control to maintain strict infra-as-code discipline to interacting fluently with clusters to exploring and modifying objects on the fly. Lens even automates the use of ‘kubectl edit’. Terminals interoperate as expected with applications on the local system, so you can do anything you’d do in a local shell, such as move around the local file system, invoke CLI or GUI applications and so on. In this way, Lens integrates quite fluently with whatever workflow and tooling your projects require.
All of this works down to the pod/container level, so you can click to open a pod terminal on a container and work with its shell directly. Lens can also instantly extract logs from any workload and save them locally to assist with troubleshooting or analytics.
Lens can even automatically install a Prometheus instance inside any namespace to which you have access, and provide permitted metrics automatically. It can also easily attach to Prometheus instances already running on your clusters.
All of these capabilities combine to fulfill the capabilities developers expect from an IDE.
Moving Forward
Lens can accelerate almost any imaginable Kubernetes development or operations workflow, boosting individual and team productivity. Moving forward, the Lens project has announced that their next release will introduce a “pluggable architecture, making it easier to add new functionality to the project.
This will likely motivate the creation of a centralized plugin catalog, and seed formation of a community of users who consume, develop and share plugins.
What kind of functionality will users add? We have some ideas (you might have some, as well):
- Plugins that make Lens more able to retain complex contexts, across invocations. For example, when starting Lens, it might be nice to be able to automatically restart multiple terminals in a particular context, such as loading a tmux config.
- Plugins that integrate with Git (and/or other tools, such as VSCode and Atom) to simplify and automate standard Kubernetes GitOps workflows. Of course, Lens already interoperates with these tools at the terminal level (and the tools with one another; for example, VScode and Atom both integrate with Git/GitHub). But there may be value to integrating Lens with Git as well, particularly since the mortal enemy of GitOps and immutability are changes made directly on cluster objects, and Lens enables both.
- Plugins that extract whole collections of descriptors for clusters and save them locally (for example, in a repo branch) as a backup or as a quick way to integrate the current cluster state (including manual changes) with a GitOps workflow.
- Plugins that let Lens interoperate with various deployment tools (for example, Terraform) and cloud provider integrations to facilitate cluster operations, scaling and lifecycle management.
- Workload-aware plugins that facilitate interoperation with (for example) serverless platforms and their workloads, running on top of Kubernetes.
If we’ve inspired any ideas for you, or you’d like to weigh in on the above, please join the Lens movement on Slack and let’s discuss them!
Lens Today and Tomorrow
Lens’ position in the workflow as a Kubernetes API enhancement is important and strongly complements the role played by code editors such as VScode. What’s more, Lens is an ideal place to experiment with adding new functionality around Kubernetes and potentially, around the infrastructures on which Kubernetes is deployed.
Given what Lens can do today and what its pluggable architecture is likely to enable soon, we think it’s definitely time for a Kubernetes IDE and for the community to take a hand in exploring, validating and extending the ways a Kubernetes IDE can improve work for dev and ops.
Learn more or get started with Lens now!