Impact of Lens Desktop on Kubernetes Clusters#
Lens Desktop reads a user’s kubeconfig to communicate with clusters through the Kubernetes API via a series of internal proxies. Lens uses the Kubernetes API and therefore, respects the RBAC set on the Kubernetes clusters. Because of this the load that Lens generates on a Kubernetes cluster is similar to that of a user using the kubectl CLI.
As Lens Desktop provides a rich graphical user interface it also takes advantage of the Kube Watch API as described below to optimize load on the Kubernetes cluster.
- All the builtin Lens views utilize the Kube Watch API for retrieving updates of Kubernetes objects in a connected cluster.
- On first navigation to a view in Lens all the resources are listed from the selected namespaces. If all namespaces are selected then Lens Desktop will try to list from all namespaces at once instead of looping through individually.
- A watch request is registered for each resource listed and the views are updated when changes are sent from the Kubenetes cluster to Lens Desktop.
- Lens Desktop only keeps a single watch request for the currently selected namespaces per resource at a time.
Lens Desktop has been tested on a cluster with 20k namespaces and 50k pods with no significant effect on performance of either Lens Desktop or the Kubernetes cluster.