Kubernetes (K8s) has improved how we deploy and manage containers, but with this power comes a lot of complexity that can easily overwhelm even experienced engineers. If you are managing five production clusters across different environments, juggling kubectlcommands across multiple terminal windows, how fast could you actually debug an issue?
Visual cluster management has become essential for DevOps workflows, even though kubectl remains the backbone of Kubernetes management.
You need to remove the friction between memorizing debugging commands across multiple clusters, switching between them, and always remembering what are the resource relationships. This is where Lens comes in, your K8s IDE that shortens the gap between CLI and visual clarity.
In this post, we will walk through what Lens is, how to install it, how to connect it to a cluster (it’s way easier than you would expect), and we will also deploy a bunch of K8s resources inside it to view and troubleshoot them with Lens.
Check out my YouTube channel:
What is Lens?
Lens is your unified Kubernetes IDE that offers visual cluster management capabilities that complement kubectl. You should think of it as your mission control center for Kubernetes that gives you a single interface where you can monitor, debug, and manage multiple clusters without drowning in terminal commands.
One of the core values that Lens offers is multi-cluster visibility. You can stop switching between terminal contexts and memorizing cluster configurations. With Lens, you get real-time dashboards, integrated log streaming, and visual resource management across all your environments.
On top of that, you can view logs, connect easily to different pods, view configmaps and secrets information easily, port-forward to your services to see if they are working properly, real-time resource monitoring, and much more.
How to Install Lens
Installing Lens is an easy process. Just head out to https://k8slens.dev/download, choose your operating system, and then follow the process described for each OS:
After installing it, launch Lens and complete the initial setup, and create your own LensID. Lens will scan for existing kubeconfig files in your ~/.kube directory and will give you the option to import discovered clusters. This automatic discovery streamlines the onboarding process if you already have kubectlconfigured.
K0s clusters
I will assume that you don’t have any K8s clusters created, so let’s jump into creating one. If you already have a K8s cluster up and running, you don’t need to follow this, but at the same time, I will give you another option of creating lightweight clusters apart from minikube and kind by leveraging K0s.
So K0s is a lightweight Kubernetes distribution that delivers a production-like cluster from a single binary, making it ideal for learning, testing, and development workflows. Right now, it runs on Linux, with experimental Windows support.
Here are the steps you have to follow if you want to install it on your Linux machine:
$ curl -sSf https://get.k0s.sh | sudo sh
$ sudo k0s install controller --single
$ sudo k0s start # wait a minute
$ sudo k0s kubectl get nodes
Connect Lens to your cluster
As I’m on MacOS, I can’t use K0s right now, so I will stick to kind.
To create a kind cluster, you can simply run:
$ kind create cluster --name lens-cluster
Creating cluster "lens-cluster" ...
✓ Ensuring node image (kindest/node:v1.30.0) 🖼
✓ Preparing nodes 📦
✓ Writing configuration 📜
✓ Starting control-plane 🕹️
✓ Installing CNI 🔌
✓ Installing StorageClass 💾
Set kubectl context to "kind-lens-cluster"
You can now use your cluster with:
kubectl cluster-info --context kind-lens-cluster
Not sure what to do next? 😅 Check out https://kind.sigs.k8s.io/docs/user/quick-start/
$ kubectl cluster-info --context kind-lens-cluster
Kubernetes control plane is running at https://127.0.0.1:63490
CoreDNS is running at https://127.0.0.1:63490/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
As soon as I’ve created my cluster, if I open Lens, I can see that it already connected to it:
Populate your cluster with different K8s Resources
To really explore Lens, you need to have K8s resources inside your cluster. So I’ve put together a couple of resources that you can deploy to observe what is happening:
First, I will start with a basic nginx deployment that shows pod lifecycle management:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Apply this deployment using kubectl. I will use Lens’ built-in terminal:
kubectl apply -f nginx_deployment.yaml
Next, let’s create a service to expose the nginx deployment:
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
type: ClusterIP
Let’s apply it:
kubectl apply -f nginx_service.yaml
Now, let’s create a config map that will change the nginx.conf file:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
server {
listen 80;
location / {
return 200 'Hello from Lens!\n';
add_header Content-Type text/plain;
}
kubectl apply -f nginx_conf.yaml
Now that we’ve created a couple of resources, we are ready to explore Lens.
First Glance at Lens
Open your Lens application, and select the K8s cluster in which you’ve deployed the above resources.
You will see many options from which you can choose, and all of them are really important to understand:
- Overview shows your cluster health assessment. This is where you get visibility into node status, resource utilization, and workload distribution
- Nodes show you data about your cluster nodes
- Workloads will let you explore your deployed resources
- Config will show you data about your configmaps, secrets, resource quotas, limit ranges and more
- In the Network you will see information about your services, ingresses, and others
And as you can see, there are other options present, so this would be a great time to stay a couple of minutes in the app, and explore all the things that you can do.
As soon as there are changes happening in your cluster, Lens picks them and propagates them immediately through the interface. Pod restarts, scaling operations, and configuration changes appear without manual refresh, providing live insight into cluster operations that static kubectl output cannot simply match.
Let’s now explore the resources we have deployed. Here are all the pods running:
By clicking on the 3 dots on the right side, you get a couple of options:
You can easily attach to a pod, open a shell, evict it, view the logs, edit it, and even delete it.
I will now press on Shell, to connect to one of my nginx pods:
Here is the ConfigMap:
And this is the service:
Check Out Logs with Lens
Log management through Lens makes K8s log management a breeze. Instead of juggling multiple terminal windows with kubectl logs commands, you get unified log streaming with advanced filtering and search capabilities.
As you saw, when we connected to the pod’s shell, we had an option to access logs. The interface automatically handles multi-container pods by providing separate log streams with clear container identification.
The search functionality helps a lot with debugging specific issues. You can use the search box to filter logs for error keywords, specific HTTP status codes, and others. Lens highlights matching terms and provides context around each match, making it easier to understand the sequence of events leading to problems.
You also have the ability to export logs. Select a time range or search filter, then export the results to a file for offline analysis or integration with external logging systems. This feature bridges the gap between interactive debugging and formal incident documentation.
Port-Forward to Nginx
Apart from everything that I’ve shown you until now, you also get an easy way to enable port forwarding through Lens.
Just go to your Network tab, select Services, and then choose your service:
You will see an option to Forward it, so let’s click on it:
You can choose a local port to forward it to, or leave it as Random, have the option to directly open in your browser, and also choose https. I will leave everything as default and click on Start.
As soon as I clicked on start, I will get redirected to my browser, and I can see my web application.
As you can see, what I’ve added in my configmap is not currently rendering in my web page, and that’s to be expected, as I didn’t specify anywhere in my deployment that I want to use the configmap.
So let’s update the deployment to use the configmap:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
volumeMounts:
- name: nginx-config-volume
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: nginx-config-volume
configMap:
name: nginx-config
As soon as I did and I’ve reapplied the code, I see in Lens the yellow triangle with the exclamation point for my pod. This means that there is an issue there. Let’s check the logs and understand what is happening.
It seems like the “server” directive is not allowed in the /etc/nginx/nginx.conf, so this means that there is an issue with my configmap. Let’s fix it and come back:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-config
data:
nginx.conf: |
events {}
http {
server {
listen 80;
location / {
return 200 'Hello from Lens!\n';
add_header Content-Type text/plain;
}
}
}
After fixing it, we now correctly see the intended message from the configmap:
Security considerations remain important even with port forwarding. The tunnel only provides local access and doesn’t expose services to other machines on your network. Anyway, please be mindful of sensitive services like databases that contain production data, and terminate port forwards when they’re no longer needed.
You can always see a list of all the port forwards in the Network -> Port Forwarding:
If connection issues arise, Lens provides diagnostic information about tunnel status, including error messages and retry attempts. Common issues include local port conflicts and service endpoint problems.
Deploy ArgoCD and connect to It
ArgoCD implements GitOps principles that align perfectly with modern DevOps workflows. Deploying ArgoCD inside your K8s cluster and managing it with Lens demonstrates how visual cluster management integrates with continuous deployment tools.
If you want to learn more about ArgoCD check out this post.
Let’s install ArgoCD, but first let’s create a namespace:
kubectl create namespace argocd
kubectl apply -n argocd -f [https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml)
You can easily monitor the deployment progress through Lens by navigating to the argocd namespace in the Workloads section. You’ll see multiple ArgoCD components initializing, such as the API server, repository server, application controller, and Redis cache. The visual status indicators show pod startup progress and resource allocation for each component. This save us you a lot of time and frustration, as you don’t need to spam kubectl get commands.
ArgoCD requires initial password configuration for the admin user. You can easily get that from Lens by going to Config->Secrets and selecting the argocd-initial-admin-secret.
Secrets are Base64 encoded, but Lens gives you the ability to show them, by clicking the Show button. Save the password, and now let’s verify if all components were deployed successfully.
Seems like everything is running properly, so we are now ready to access the ArgoCD UI. We will use port forwarding once more. Navigate to your services, and look for the ArgoCD server service, and start the port forward:
This is what you will initially see in your Browser, so ensure you use the _visit this website _option.
The ArgoCD login page appears, requesting username and password credentials. Use admin as the username and the password you extracted from the secret:
The ArgoCD dashboard provides a clean interface for application management, showing deployed applications, sync status, and health indicators.
In Lens, you will see that a new Custom Resource Definition has appeared for the argoproj.io, making it easy to track all the Argo related resources in a single view:
I will now deploy a dummy ArgoCD application just to show you how you will see it in Lens:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: true
Save the above to a file and use kubectl apply to deploy it. This is how you see the App in Lens after deploying:
And in ArgoCD:
We won’t go through ArgoCD’s capabilities for this tutorial, I just wanted to show you how easy Lens makes the overall process of deployment, and also for debugging. If you have any ArgoCD apps that fail, you can use Lens to examine logs, resource status, and configuration details.
Deploy a Helm Chart
Let’s add a popular Helm repository to our local configuration:
helm repo add bitnami https://charts.bitnami.com/bitnami
As soon as I’ve done this, in Lens, I can go to Helm and select Charts, and I will see all the available from the repository.
I can easily search for a chart at the top of the Charts page:
Let’s deploy a WordPress application:
helm install my-wordpress bitnami/wordpress \
--namespace wordpress \
--create-namespace \
--set wordpressUsername=admin \
--set wordpressPassword=secretpassword \
--set service.type=ClusterIP \
--set persistence.enabled=false
Again, we can monitor the deployment process by navigating to the Wordpress namespace in the Workloads->Pods:
The Helm release appears in Lens under the Releases section, showing release status, chart version, and installation notes:
We can access the WordPress application by doing port forwarding, and similar to ArgoCD’s deployment, we should get the login credentials from the my-wordpresssecret (or well, this time we’ve actually hardcoded the password when we installed the helm chart; don’t do this).
Key Points
Lens is my go-to product when it comes to choosing a K8s IDE. You get all the debugging capabilities into one place, a built-in terminal, and the observability you need to understand what is happening in your K8s cluster.
Using Lens saves you a lot of time, because you don’t need to remember complicated kubectl commands for everything your process would require. It’s important to understand that Lens is not a 100% replacement for kubectl, and this is not what it promises. It’s a complement to kubectl that aims to make your life easier, and equip you with all the tools you need to make your cloud-native life easier.
Want to learn Terraform? Check out my Terraform series:
Terraform from 0 to Hero — 0. I like to start counting from 0, maybe I enjoy lists too much