kubectl slower to respond through OpenLens terminal, compared to Lens or standalone terminal

[mossroy]

Try for example command: time kubectl version, and run it 10 times in a row in 2 different contexts: inside your client OS terminal (with appropriate KUBECONFIG en var), and inside OpenLens terminal (connected to the corresponding cluster)

• In the client OS terminal, the response time is stable (in my case around 70 milliseconds)
• In the latest OpenLens (6.5.2-366) terminal, it varies between the same ~70 milliseconds and 5 seconds. Using the default kubectl executable (injected in the PATH by OpenLens), or using the same executable as in the client OS terminal.

I tested with latest Lens (2023.11.131420-latest), and the response time is stable with it, around 70 milliseconds.

To investigate further, I tried the corresponding kubeapi HTTP call, that you can find by running kubectl version -v=6 In the OS terminal, it directly points to the kube control plane IP, like https://x.x.x.x:6443/version?timeout=32s. In OpenLens & Lens, it points to something like https://127.0.0.1:35047/4bc5aa7ab8cdb1ee83ef85010323c356/version?timeout=32s (because it injects a specific KUBECONFIG that seems to proxy all HTTP requests through a local reverse-proxy)

So I took the bearer token from secret default-token-xxxxx of the kube cluster, exported it in a $BEARER variable of my client OS terminal, and executed (outside of OpenLens):

time curl --header "Authorization: Bearer $BEARER" --insecure https://x.x.x.x:6443/version?timeout=32s

-> stable time around ~70ms

time curl --header "Authorization: Bearer $BEARER" --insecure https://127.0.0.1:35047/4bc5aa7ab8cdb1ee83ef85010323c356/version?timeout=32s

-> time varying between 70ms and 5s

So it seems to me that the delays are introduced by the local reverse-proxy hosted by OpenLens.

I tested with different kubernetes servers: a k3s 1.27.7 running locally, a k3s 1.27.7 running remotely, a remote k8s 1.21.7, and a remote GKE 1.27.5

[ghost]

Hi!

For product-related issues, you have to open a ticket using Lens repo

Regards

[mossroy]

For product-related issues, you have to open a ticket using Lens repo

Maybe I was not clear in my description, but this issue does not occur in latest Lens app distributed by Mirantis, while it occurs in latest OpenLens distributed here. So I don't see the point of reporting it in Lens repo, where it would logically be closed as "could not reproduce".

Maybe it could come from the fact that latest OpenLens package was released almost 6 months ago here, and this issue might have existed in Lens, and been solved since then?

[ebbypeter]

This repo only provides signed binaries and does not alter the source code for the OpenLens repo.
Mirantis, the parent company of Lens, build Lens Desktop on top of the "open source" Lens Core. That source code is not available to us.