Lens as IDE for Kubernetes
This is a short and complimentary article regarding Lens desktop application. This open source software gives the possibility to look inside Kubernetes cluster with a handy UI which helps indeed to dig into cluster internals and does quick troubleshooting.
Kubectl is de-facto standard for communicating with cluster. My guess, it is the first tool the developer starts to use from the very beginning of Kubernetes journey and likely the last tool he stops using. Kubectl has a very structured and intuitive command and parameter set. Still, it is command line utility that might be the only option being inside terminal session. On the local computer, multi-windows IDE is more productive from the other side.
Lens is one of IDE but for Kubernetes. I must admit that I was unaware of the existence of such tools at the beginning and has practiced with Kubernetes by typing kubectl commands. That was OK and ultimately must-have skill for automation. But, this shook me a lot when I saw my cluster through the mature UI of Lens.
Let’s take a cluster I created in the scope of my previous story and look at it through that “magnifying lens”. It is zero efforts for Lens to connect to local minikube I use and it is equally easy to import kubeconfig section for remote cluster.
In Overview section I see that my solution has 2 pods, 1 deployment (for hand crafted heartbeat service), 1 stateful set (for RabbitMQ server).
Switch to pod details and select webapp (my heartbeat service) details:
The menu bar on the right top corner of details is an absolute treasure:
First button “Attach to Pod” opens the readonly widow to Pods terminal:
Area with terminal is multi tab, imagine how easy to open it for many pods and study logs to understand current application state.
Second command is twice useful as it opens shell to this pod to experiment with internals:
Sure thing, it is possible to use kubectl to reach pods internals, but imagine commands which need to type:
Fact, that pod names need to be either remembered or listed with kubectl in advance, and necessity to keep multiple opened terminal sessions to interact with many pods… I would not like having troubleshooting stress on production without Lens but armed with kubectl only! No way!
Next pod’s button allows to edit pod manifest YAML file:
This function might be handy to try-and-see session on development/staging environment. No need to remind that infrastructure as a code is a vital requirement for any project and better even to experiment with definitions stored in code repositories. Even in this case, nobody stops you observing results with Lens UI.
Deployments tab has a button for manual scaling to give the possibility to have +1 pod in a moment:
Workloads are an important part of the cluster but not the only.
Configs are another first-class citizen of the cluster. My example has a couple of secrets. So, to find credentials used to connect from heartbeat service, select heartbeat-secrets:
No problem to click crossed eye icon to see naked value:
In fact, values can be changed and applied with Save button click.
Network is a critical aspect of the cluster for sure. So far, my application has no ingress (plan to add it in one of the next articles) and I use port-forwarding command via kubectl or minikube to get HTTP access to the service.
More and more functionality can be found in other parts of Lens.
Overall, I enjoy using Lens UI a lot. By the happy coincidence, I heard about Lens after months of using kubectl commands, which literally took me aback when I suddenly started to see the visualization of Kubernetes cluster resources with the easy ability to tune and play with it.
As one more time notice, strict following the infrastructure-as-a-code practice is absolutely important, so do not forget to back merge modifications to original YAML file and put it under the source-control system.
