Terminal : Support for Windows Subsystem for Linux #179

fjudith · 2020-03-31T07:28:17Z

What would you like to be added:

Add an option in the Preference page allowing to select the shell used by the terminal similarly to Visual Studio Code.

Why is this needed:

Windows Subsystem for Linux is commonly used by Kubernetes administrator running on Windows. Today Lens seems to only support Git Bash

Environment you are Lens application on:

Kubernetes distribution: Any
Desktop OS: Windows

The text was updated successfully, but these errors were encountered:

RobertDiPaolo · 2020-04-02T16:01:42Z

I've found lens to be a breath of fresh air after struggling with the kubernetes dashboard for some time. The UX is excellent and the UI very fast, etc, kudos to all involved. Being able to use the WSL terminal as well would mean I could do all k8s admin in a single app.

Also when connecting to AWS EKS clusters, the aws cli needs to be invoked to verify iam credentials. Running those commands in WSL would also be helpful, as I don't normally install all the aws tools in windows (though can work around that).

LaysDragon · 2020-10-19T16:38:15Z

Since I need to use some kubectl plugin only available under Linux, so I bump into this issue too. I trying to figure out if I can solve problem manually and have some conclusion.

the env of KUBECONFIG won't pass directly into wsl2 bash

Evening I manually enter bash shell in Lens Terminal. The KUBECONFIG env won't pass directly to bash. I have trying to fix the env problem though WSLENV to share the KUBECONFIG to WSL2 bash.

set WSLENV=KUBECONFIG/pu

wsl2 network problem

Now, another problem is that in WSL2 cannot access to windows localhost network directly. So kubectl will simply get rejected on 127.0.0.1 address since there is no service listening in WSL2.
At least I can set up script in .bashrc to auto fetch host's ip and replace it in kube config. I trying to do some test, fetch the host's ip. Then replace the ip in the kube config manually. It actually work.

Lens security restriction

Then I head into next problem is that looks like lens create a localhost api proxy for it own terminal and restrict to local access only. But as WSL2 environment is a virtual machine have it own ip, so kubectl can only get the default response From lens still failed.

I1020 00:23:57.265435    5900 round_trippers.go:420] GET http://172.23.208.1:53937/02f71990-ec55-4309-9aa0-45d731dcf08e/api?timeout=32s
I1020 00:23:57.266435    5900 round_trippers.go:427] Request Headers:
I1020 00:23:57.266435    5900 round_trippers.go:431]     Accept: application/json, */*
I1020 00:23:57.266435    5900 round_trippers.go:431]     User-Agent: kubectl/v1.17.11 (windows/amd64) kubernetes/ea5f00d
I1020 00:23:57.269436    5900 round_trippers.go:446] Response Status: 200 OK in 3 milliseconds
I1020 00:23:57.269436    5900 round_trippers.go:449] Response Headers:
I1020 00:23:57.269436    5900 round_trippers.go:452]     Content-Type: text/html
I1020 00:23:57.269436    5900 round_trippers.go:452]     Date: Mon, 19 Oct 2020 16:23:57 GMT
I1020 00:23:57.270436    5900 round_trippers.go:452]     Connection: keep-alive
I1020 00:23:57.270436    5900 request.go:1017] Response Body: <!doctype html><html lang="en"><head><meta charset="UTF-8"><title>Lens - The Kubernetes IDE</title><link href="/build/Lens.css" rel="stylesheet"></head><body><div id="app"></div>
<script src="/build/Lens.js"></script></body></html>
I1020 00:23:57.271435    5900 cached_discovery.go:121] skipped caching discovery info due to couldn't get version/kind; json parse error: json: cannot unmarshal string into Go value of type struct { APIVersion string "json:\"apiVersion,omit
empty\""; Kind string "json:\"kind,omitempty\"" }
F1020 00:23:57.272435    5900 helpers.go:114] error: couldn't get version/kind; json parse error: json: cannot unmarshal string into Go value of type struct { APIVersion string "json:\"apiVersion,omitempty\""; Kind string "json:\"kind,omite
mpty\"" }

Lens have no option to remove or add ip white list to its proxy server, so it still head into another dead end. Unless I setup another port forwarding to pass though such problem, but it still inconvenience.

For support WSL2 in Lens I guess we need to implement these function:

Auto fetch real Host ip in WSL2 to setup specified kubeconfig for WSL2
Auto fetch WSL2's virtual IP to setup IP whitelist in Lens's API proxy server
Setup specified KUBECONFIG for WSL2

jasonnance · 2020-10-19T17:50:11Z

I got this working by running Lens in my WSL2 Ubuntu distro with the AppImage release (snap install didn't work) and using X11 forwarding (VcXsrv) to show the app in my Windows desktop. There are a bunch of guides lying around for using X11 forwarding to access Linux GUI apps on your Windows host -- here's an example: https://stackoverflow.com/questions/61110603/how-to-set-up-working-x11-forwarding-on-wsl2

Seems to be working fine, and as a bonus, it used the AWS CLI in my Ubuntu distro to authenticate to my EKS cluster out of the box.

LaysDragon · 2020-10-20T05:58:08Z

I got this working by running Lens in my WSL2 Ubuntu distro with the AppImage release (snap install didn't work) and using X11 forwarding (VcXsrv) to show the app in my Windows desktop. There are a bunch of guides lying around for using X11 forwarding to access Linux GUI apps on your Windows host -- here's an example: https://stackoverflow.com/questions/61110603/how-to-set-up-working-x11-forwarding-on-wsl2

Seems to be working fine, and as a bonus, it used the AWS CLI in my Ubuntu distro to authenticate to my EKS cluster out of the box.

That sounds really crazy to use WSL as ubuntu desktop, too bad most of my work still done on windows side, this is not suitable for my situation, but still kind of interesting.

xrubick · 2021-04-18T03:03:59Z

I got this working by running Lens in my WSL2 Ubuntu distro with the AppImage release (snap install didn't work) and using X11 forwarding (VcXsrv) to show the app in my Windows desktop. There are a bunch of guides lying around for using X11 forwarding to access Linux GUI apps on your Windows host -- here's an example: https://stackoverflow.com/questions/61110603/how-to-set-up-working-x11-forwarding-on-wsl2

Seems to be working fine, and as a bonus, it used the AWS CLI in my Ubuntu distro to authenticate to my EKS cluster out of the box.

emmm,It can't work by running Lens in my WSL,and got some desc:
$ kontena-lens
Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Permission denied
[1] 648 trace trap (core dumped) kontena-lens
$ sudo kontena-lens
[660:0418/110114.492723:FATAL:electron_main_delegate.cc(254)] Running as root without --no-sandbox is not supported. .
[1] 659 trace trap (core dumped) sudo kontena-lens

Help,pls!

vildek · 2021-04-30T17:08:52Z

Found a way to run Lens with WSL1. Automatic context switching and access to pod shell also works. To do that, you need to install WSL manually.

Download wsl appx file for your favorite OS (i use Ubuntu18.04) - https://docs.microsoft.com/en-us/windows/wsl/install-manual
Extract the appx with 7zip, go inside the extracted directory and run the installation, in my case Ubuntu1804.exe. Once you configure wsl, download kubectl, install it as in regular linux os - https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-binary-with-curl-on-linux
Run Lens, go File>Preferences and set Terminal shell - C:\Users<User>\Documents\UbuntuWSL\ubuntu1804.exe
Have fun

black-snow · 2021-07-02T09:29:25Z

All my thumbs for this one. I know PS can be great once you get to know it but all my tooling lives inside the WSL.

nevalla · 2021-07-02T11:07:33Z

Seems that WSL is supported on terminal, so closing this now. Please re-open if you still find this an issue.

LaysDragon · 2021-07-02T16:20:54Z

@nevalla So Lens still not directly support WSL? Right? vildek's method can only work on WSL1 with manually configured…

black-snow · 2021-07-02T18:01:50Z

@nevalla Hi, what do you mean by that? What terminal?

nevalla · 2021-07-03T12:37:50Z

Maybe I've understood the issue wrong, but if I set Terminal Shell Path, for example, as wsl.exe in App settings:

Then install manually kubectl binary on Ubuntu box.

Lens opens then wsl on embedded terminal and I'm able to use kubectl there as well:

LaysDragon · 2021-07-03T13:09:47Z

@nevalla hmmmm until you post the screenshot, I didn't realized that Lens have already release the 5.0.0 version several day ago(I didn't received the 5.0.0 update notification on 4.x latest version), We finally can set the terminal we want. So I upgrade and test it. The KUBECONFIG env automated pass in wsl2 bash looks good.
But there is still a problem after I try, as I known lens seems use a proxy to deal with connection ,but WSL2's network structure
still make it can't access host's service directly. Did I miss something?

nevalla · 2021-07-03T14:06:46Z

Alright, it seems that this is issue on WSL (found multiple open issues). You can try to run wsl --shutdown on PowerShell and then open Lens terminal.

LaysDragon · 2021-07-03T14:18:52Z

That didn't work. :(
It is the problem about how network work under WSL2. It seems won't be the problem under WSL1,I didn't test it. But as I known
that WSL2 is a virtual machine and bridge the network to the windows host, so it can't directly access localhost service under windows like WSL1. microsoft/WSL#4619 (comment)
It need to do serval tweak on the KUBECONFIG env and proxy server to configure the right ip under wsl2 environment. I feeling that there might have confusion between wsl1 and wsl2 here.

nevalla · 2021-07-03T14:57:00Z

Someone hinted that disabling Fast Start-Up might fix the issue but I haven't tested this since I'm able to connect fine.

https://stephenreescarter.net/wsl2-network-issues-and-win-10-fast-start-up/

LaysDragon · 2021-07-04T15:34:35Z

That post it talking about the problem that windows can't access WSL2's service directly via localhost. That is the opposite of the situation here.(windows can accesss wsl2 service directly via localhost)(Here is wsl2 kubectl need to access the Lens's proxy service on windows side from WSL2). I'm wondering what version of you wsl versrion? if you are in WSL1 then it makes sense 🤔

LaysDragon · 2021-07-06T04:44:25Z

Ok,I have to point out that it just still not support WSL2 as terminal directly with kubectl due to network structure of WSL2,not WSL1. 😐 This issue should reopen.

MartinGolding515 · 2021-07-15T13:50:37Z

wsl.exe as terminal works for the terminal window. However, as other have said, when using the pod shell command it shows windows folders and it is not possible to get to the container's folder structure

WLun001 · 2021-08-10T13:09:50Z

Please support WSL 2

Getting Connecting ... when configure with WSL 2

Ajay250496 · 2021-08-16T03:33:57Z

Maybe I've understood the issue wrong, but if I set Terminal Shell Path, for example, as wsl.exe in App settings:

Then install manually kubectl binary on Ubuntu box.

Lens opens then wsl on embedded terminal and I'm able to use kubectl there as well:

So I have two clusters. I set my terminal as wsl.exe and configure my kubeconfig like below. One of my clusters work perfectly fine, while the other shows "Invalid Credentials". Looking through the logs show "401: Unauthorized" however I have this exact config (other than the wsl in the command section) working on that same bash with no issue. Even have it working on another VM. Trying to find more verbose logs but doesnt seem to provide more info on that. Any idea what I can check to fix this? I think even more verbose logs can help solve it. Tried DEBUG=TRUE after lens.exe but no difference

Error

�[31merror�[39m: Failed to connect cluster "cluster-1": StatusCodeError: 401 - {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Unauthorized","reason":"Unauthorized","code":401}

Config

clusters:
- cluster:
    certificate-authority-data: very long base64 output
    server: super secret endpoint
  name: cluster-1
- cluster:
    certificate-authority-data: very long base64 output
    server: suprt secret endpoint
  name: cluster-2
contexts:
- context:
    cluster: cluster-2
    user: cluster-2
  name: sssp-staging
- context:
    cluster: cluster-1
    user: cluster-1
  name: sssp-prod
current-context: sssp-prod
kind: Config
preferences: {}
users:
- name: cluster-1
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - aws
      - eks
      - get-token
      - --region
      - ca-central-1
      - --cluster-name
      - sssp-prod
      command: wsl
      env:
      - name: AWS_PROFILE
        value: production
- name: cluster-2
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - aws
      - eks
      - get-token
      - --region
      - ca-central-1
      - --cluster-name
      - sssp-staging-eks
      command: wsl
      env:
      - name: AWS_PROFILE
        value: staging

EDIT

Realized this is due to the AWS_PROFILE variable. It was using the credentials in the "default" profile. Unsure what to do to fix this. I've tried passing environment variables with WSLENV and setting AWS_DEFAULT_PROFILE in kubeconfig.

davekats · 2021-08-17T00:31:54Z

Maybe I've understood the issue wrong, but if I set Terminal Shell Path, for example, as wsl.exe in App settings:

Then install manually kubectl binary on Ubuntu box.

Lens opens then wsl on embedded terminal and I'm able to use kubectl there as well:

@nevalla I am new to Lens and I'm trying to get the program set up by adding clusters from my WSL2 kubeconfig file. I set the terminal shell path to wsl.exe as you showed, but it doesn't seem to be working. In the "Add clusters from kubeconfig" screen it gives me an error User Exec command "aws" not found on host which makes me think that it is still trying to look on Windows for running the command instead of using WSL2.

jvandervelden · 2021-10-22T13:34:45Z

Maybe I've understood the issue wrong, but if I set Terminal Shell Path, for example, as wsl.exe in App settings:

Then install manually kubectl binary on Ubuntu box.
Lens opens then wsl on embedded terminal and I'm able to use kubectl there as well:

@nevalla I am new to Lens and I'm trying to get the program set up by adding clusters from my WSL2 kubeconfig file. I set the terminal shell path to wsl.exe as you showed, but it doesn't seem to be working. In the "Add clusters from kubeconfig" screen it gives me an error User Exec command "aws" not found on host which makes me think that it is still trying to look on Windows for running the command instead of using WSL2.

I too am seeing this except with gcp's gcloud:

error executing access token command "/usr/lib/google-cloud-sdk/bin/gcloud config config-helper --format=json": err=exec: "/usr/lib/google-cloud-sdk/bin/gcloud": file does not exist output= stderr=

My preferences -> terminal is wsl.exe

jvandervelden · 2021-10-22T15:22:19Z

This is very naïve but it seems like the auth proxy here: https://github.com/lensapp/lens/blob/master/src/main/kube-auth-proxy.ts#L89 needs to be spawned within the context of the specified terminal preferences. Likely will cause other issues with the kubectl location since I noticed it's always using a bundled version. Maybe adding a preference to use the installed kubectl rather than bundled.

XFNeo · 2021-10-26T17:28:00Z

wsl2 network problem

Now, another problem is that in WSL2 cannot access to windows localhost network directly. So kubectl will simply get rejected on 127.0.0.1 address since there is no service listening in WSL2. At least I can set up script in .bashrc to auto fetch host's ip and replace it in kube config. I trying to do some test, fetch the host's ip. Then replace the ip in the kube config manually. It actually work.

I have wrote the script to replace the IP

if [ -n "${KUBECONFIG}" ] && grep -q "user: proxy" < "${KUBECONFIG}"; then
  WSL_WINDOWS_HOST=$(grep nameserver < /etc/resolv.conf | cut -d ' ' -f 2)
  sed -i "s/127.0.0.1/${WSL_WINDOWS_HOST}/" "$KUBECONFIG"
fi

And it is still not working because my windows host listening port on 127.0.0.1 and I cant connect through wsl network.
@LaysDragon how did you manage to get this to work?

LaysDragon · 2021-10-26T21:04:38Z

wsl2 network problem

Now, another problem is that in WSL2 cannot access to windows localhost network directly. So kubectl will simply get rejected on 127.0.0.1 address since there is no service listening in WSL2. At least I can set up script in .bashrc to auto fetch host's ip and replace it in kube config. I trying to do some test, fetch the host's ip. Then replace the ip in the kube config manually. It actually work.

I have wrote the script to replace the IP
if [ -n "${KUBECONFIG}" ] && grep -q "user: proxy" < "${KUBECONFIG}"; then
  WSL_WINDOWS_HOST=$(grep nameserver < /etc/resolv.conf | cut -d ' ' -f 2)
  sed -i "s/127.0.0.1/${WSL_WINDOWS_HOST}/" "$KUBECONFIG"
fi
And it is still not working because my windows host listening port on 127.0.0.1 and I cant connect through wsl network. @LaysDragon how did you manage to get this to work?

ohhh I didn't make it clear,I mean I can get the right ip of the host. The next line is about I also bump into this problem. :(
Unless we setup another a port forwarding to allow access connection from wsl. But its just too troublesome. :(

davekats · 2021-10-26T21:11:20Z

Now that Windows 11 is released, I was able to run Lens from WSL2 and see the GUI. You can follow this guide to get it set up: https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-apps

LaysDragon · 2021-10-26T21:15:03Z

yeah but windows 11 still need some time to go. its still good to have a alternative way to use lens. at least it more easy to use gui app in wsl2 on windows 11 then now.

XFNeo · 2021-10-26T21:57:33Z

@nevalla Please reopen ticket to fix issue with wsl2
#4224

jc-roman · 2022-01-17T22:23:23Z

I made it work with wsl.exe by configuring the "path of the kubectl binary" to the wsl path of the kubectl.exe included with Lens installed on Windows. How-to:

In the 'Application' tab, set the Terminal Shell Path to wsl.exe

2, In the Kubernetes Tab, disable 'Kubectl Binary Download'

Take note of the kubectl.exe path in Lens. Usually:
C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe
and translate from a Windows path to a WSL path. From a wsl terminal you can use wslpath :

# The Windows path should be within quotes

$ wslpath "C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe"
/mnt/c/Users/my-user/AppData/Local/Programs/Lens/resources/x64/kubectl.exe

Copy the WSL path you got from the previous step and paste it in Lens at 'Path to kubecl Binary'

The terminal, port-forwarding or exec'ing into containers now work without issues for me.

pduchnovsky · 2022-01-26T17:50:24Z

I made it work with wsl.exe by configuring the "path of the kubectl binary" to the wsl path of the kubectl.exe included with Lens installed on Windows. How-to:

In the 'Application' tab, set the Terminal Shell Path to wsl.exe

2, In the Kubernetes Tab, disable 'Kubectl Binary Download'

Take note of the kubectl.exe path in Lens. Usually:
C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe
and translate from a Windows path to a WSL path. From a wsl terminal you can use wslpath :
# The Windows path should be within quotes

$ wslpath "C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe"
/mnt/c/Users/my-user/AppData/Local/Programs/Lens/resources/x64/kubectl.exe
Copy the WSL path you got from the previous step and paste it in Lens at 'Path to kubecl Binary'

The terminal, port-forwarding or exec'ing into containers now work without issues for me.

This gives me:

Bafff · 2022-01-27T15:28:09Z

@jc-roman

hi!
Are you using wsl1 or wsl2?

philipp1992 · 2022-02-06T12:07:11Z

getting this error

pkerschbaum · 2022-03-10T09:57:58Z

I think I found a more simple approach based on #2079 (comment).
The idea is to delegate any kubectl usage in Windows to kubectlin WSL.

Create a file "kubectl.bat" somewhere in the Windows file system (e.g. in C:\scripts) and include this code:
```
@echo off
echo.
wsl kubectl %*
```
Add the folder (e.g. C:\scripts) to your PATH environment variable (using the Windows environment variables control panel).
Start a new command line or PowerShell and type where kubectl. The first entry should be C:\scripts\kubectl.bat.
- If this entry is not present, restart your computer.
- If it is not the first entry in the list, you have to move the folder C:\scripts higher up for the PATH environment variable (this can be done in the Windows environment variables control panel).
Start Lens

Finally, you might have to add your kube config from WSL. In my case, I had to add this folder using "Sync folder(s)": \\wsl.localhost\Ubuntu\home\pkerschbaum\.kube.

Bafff · 2022-03-10T10:09:09Z

@pkerschbaum hi!

I'll try your solution now, but one question - I see problem that there would be only one kubectl binary for al clusters, so if you have very old (unsupported) and very new clusters you could have issues

pkerschbaum · 2022-03-10T10:31:49Z

@Bafff that's true, I think this limitation applies also to the approach suggested by @jc-roman (#179 (comment)).
I don't know how to handle that...

Bafff · 2022-03-10T10:43:23Z

@pkerschbaum anyway thanks for sharing! How long are you using this? Does it work well, any issues or need-to-know things maybe?

pkerschbaum · 2022-03-10T10:56:46Z

@Bafff I shared the solution just after I got it working, it seems to work very well (can connect into containers etc).

Bafff · 2022-03-10T11:29:26Z

And what are your setting on the Kubernetes settings Tab in Lens? @pkerschbaum

pkerschbaum · 2022-03-10T11:36:08Z

@Bafff

hpzzz · 2022-03-10T12:41:43Z

@pkerschbaum Hey, I followed Your instructions and am getting following errors:

any way to fix these path issues?

Bafff · 2022-03-10T13:23:57Z

@hpzzz you can try this workaround instead
ln -sf "/mnt/c/users/$windowsUser/.kube/config" ~/.kube/config
where $windowsUser is your Windows (not WSL) username

pkerschbaum · 2022-03-10T16:34:20Z

For me, there was also more to do regarding authentication for GCP:

For my cluster, gcloud is the authprovider.
If I did not use Lens for a while and then started it again, this error happened:

Running kubectl get pods once in WSL would refresh the access token and thus, Lens would work again - but this is of course annoying.

I "fixed" this issue in a similar way as I did for kubectl:

Created gcloud.bat in C:\scripts:

@echo off
echo.
wsl /usr/lib/google-cloud-sdk/bin/gcloud %*

Edited ~/.kube/config in WSL:

users:
- name: ...
  user:
    auth-provider:
      config:
        ...
        cmd-path: gcloud # instead of /usr/lib/google-cloud-sdk/bin/gcloud

PePoDev · 2022-03-19T13:48:22Z

I have created aws.bat to try with AWS

@echo off
echo.
wsl aws %*

I got this error message

Unable to locate credentials. You can configure credentials by running "aws configure".

E0319 20:27:45.776919 19308 proxy_server.go:147] Error while proxying request: getting credentials: exec: executable aws failed with exit code 253

getting credentials: exec: executable aws failed with exit code 253

jvandervelden · 2022-03-19T15:10:36Z

Try adding --user <wsl username>. Looks like it might be staring the wsl terminal not as the required user.

PePoDev · 2022-03-19T15:21:07Z

Try adding --user <wsl username>. Looks like it might be staring the wsl terminal not as the required user.

@jvandervelden Hi, Thanks for the workaround.

I have tried to patch aws.bat to the below script, But not working.

@echo off
echo.
wsl --user <wsl-username> aws %*

But with option --profile <aws-profile> it's worked!

I don't know why 🤔

ZILosoft · 2022-05-31T23:54:31Z

workaround
in lens powershell terminal run wsl.exe
after
alias kubectl="kubectl.exe"

romubaron · 2022-06-28T09:23:41Z

I just was able to fix this issue by changing the default WSL default Distribution to Debian.
My setup was originally:

>wsl --list
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
docker-desktop
Debian

And by setting up Debian as my default WSL, it has fixed my issue:

>wsl --set-default Debian
>wsl --list
Windows Subsystem for Linux Distributions:
Debian (Default)
docker-desktop
docker-desktop-data

Source: https://klaushofrichter.medium.com/using-windows-subsystem-for-linux-for-kubernetes-8bd1f5468531

pureliumy · 2022-09-22T14:56:59Z

@hpzzz Try to edit the certs paths in your .kube/config to a relative path, such as ../.minikube/ca.crt. That works for me.

kobethuwis · 2022-10-21T10:55:01Z

I have created aws.bat to try with AWS

@echo off
echo.
wsl aws %*

I got this error message

Unable to locate credentials. You can configure credentials by running "aws configure".

E0319 20:27:45.776919 19308 proxy_server.go:147] Error while proxying request: getting credentials: exec: executable aws failed with exit code 253

getting credentials: exec: executable aws failed with exit code 253

@PePoDev I fixed this issue by using the solution provided here. Add the aws.bat file to your LocalAppData and the change will be picked up on restarting Lens. Not sure about the user credentials though 🤔

DzeryCZ · 2022-12-07T10:59:28Z

I have created aws.bat to try with AWS

@echo off
echo.
wsl aws %*

I got this error message

Unable to locate credentials. You can configure credentials by running "aws configure".

E0319 20:27:45.776919 19308 proxy_server.go:147] Error while proxying request: getting credentials: exec: executable aws failed with exit code 253

getting credentials: exec: executable aws failed with exit code 253

I'm also using kubectl with aws, but the default aws.bat did not work for me correctly. I had to tune it up a bit so it exports all env variables, etc...

This one starts your shell (bash, zsh, ...) in interactive mode:

@echo off
echo.
wsl "$SHELL" -i -c "aws %*"

kobethuwis · 2023-03-22T08:10:21Z

I just was able to fix this issue by changing the default WSL default Distribution to Debian. My setup was originally:
>wsl --list
Windows Subsystem for Linux Distributions:
docker-desktop-data (Default)
docker-desktop
Debian
And by setting up Debian as my default WSL, it has fixed my issue:
>wsl --set-default Debian
>wsl --list
Windows Subsystem for Linux Distributions:
Debian (Default)
docker-desktop
docker-desktop-data
Source: https://klaushofrichter.medium.com/using-windows-subsystem-for-linux-for-kubernetes-8bd1f5468531

I'm also unable to use Lens with WSL2 since changing my default installation to a non-Debian version. (Kali Linux) Did anyone else manage to get it working?

robertomanfreda · 2023-07-10T22:16:16Z

I have lost 2 hours of my time but now all it is working fine.
I'll describe the process here:

Install wsl (default is wsl 2) -> wsl --install -d Ubuntu-22.04
Setup you Ubuntu user
Install an app from Ubuntu, for testing if wslg is working (I installed terminator for this test)
Install lens via .deb
curl -fsSL https://downloads.k8slens.dev/keys/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/lens-archive-keyring.gpg > /dev/null
echo "deb [arch=amd64 signed-by=/usr/share/keyrings/lens-archive-keyring.gpg] https://downloads.k8slens.dev/apt/debian stable main" | sudo tee /etc/apt/sources.list.d/lens.list > /dev/null
sudo apt update
sudo apt install lens
Try running 'lens-desktop', now I got 2 consecutive errors
5.1 lens-desktop: error while loading shared libraries: libgbm.so.1: cannot open shared object file: No such file or directory
FIX: sudo apt install libgbm1
5.2 lens-desktop: error while loading shared libraries: libasound.so.2: cannot open shared object file: No such file or directory
FIX: sudo apt install libasound2
Now running 'lens-desktop' lens should start on your desktop but here trying to activate the license ID for me it was not working,it requires a browser inside your wsl in order to open link (it was so obvious - not obvious in the beginning)
sudo apt install firefox
Click the activation link on Lens desktop, now you should be redirected to the Lens page and all should work.

As notes you need to install kubectl in your wsl instance and your additional plugins such as oci or aws, just like lens works on native linux-based OSs

jhonnyll · 2023-07-11T23:37:16Z

That worked. Thank you!
The only problem I encounter besides the mentioned above was that my lens was off meaning I needed to hover my cursor somewhere above whatever icon/button I intended to click. This is probably a problem with a lens dependency or Linux GUI library. I found a workaround by going to View > "Toggle Full Screen" in the hamburger button on the top left screen of Lens

MartinGolding515 · 2023-11-09T12:46:05Z

I made it work with wsl.exe by configuring the "path of the kubectl binary" to the wsl path of the kubectl.exe included with Lens installed on Windows. How-to:

In the 'Application' tab, set the Terminal Shell Path to wsl.exe

2, In the Kubernetes Tab, disable 'Kubectl Binary Download'

Take note of the kubectl.exe path in Lens. Usually:
C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe
and translate from a Windows path to a WSL path. From a wsl terminal you can use wslpath :
# The Windows path should be within quotes

$ wslpath "C:\Users\my-user\AppData\Local\Programs\Lens\resources\x64\kubectl.exe"
/mnt/c/Users/my-user/AppData/Local/Programs/Lens/resources/x64/kubectl.exe
Copy the WSL path you got from the previous step and paste it in Lens at 'Path to kubecl Binary'

The terminal, port-forwarding or exec'ing into containers now work without issues for me.

I found running lens in wsl a pain due to display scaling issues, so reverted to windows app, but keeping kubeconfig in wsl.
Using ws.exe as the terminal path and the following format for kubectl

wr-jc · 2024-01-22T21:40:49Z

I was able to get this working on Lens 2024.1.170738-latest

In [ preferences -> Kubernetes ], uncheck "KUBECTL BINARY DOWNLOAD" and leave "PATH TO KUBECTL BINARY" unset. This way the terminal doesn't reference kubectl via absolute path and it just tries to run "kubectl"
In [ preferences -> Terminal ], set "TERMINAL SHELL PATH" to wsl.exe

Initially this didn't work because Lens was overriding the KUBECONFIG environment variable to point to a custom kubeconfig in /mnt/c/Users//AppData/Local/Temp/-. I was able to workaround this issue using these steps:

Open powershell and run wsl.exe (this ensures you are using the default wsl instance)
use vi/vim/nano to edit ~/.bashrc file, this file is executed by default when you start a new bash shell
At the end of ~/.bashrc add the following line:
export KUBECONFIG=
Save the file

Now when you launch a terminal in Lens, the .bashrc file will be sourced and override whatever value is being passed by Lens

fjudith added the enhancement New feature or request label Mar 31, 2020

buzzedword mentioned this issue Apr 23, 2020

Start of work for supporting WSL #308

Closed

nevalla closed this as completed Jul 2, 2021

XFNeo mentioned this issue Nov 2, 2021

Terminal : Support for Windows Subsystem for Linux version 2 #4224

Open

Terminal : Support for Windows Subsystem for Linux #179

Terminal : Support for Windows Subsystem for Linux #179

Comments

fjudith commented Mar 31, 2020

RobertDiPaolo commented Apr 2, 2020

LaysDragon commented Oct 19, 2020 • edited Loading

jasonnance commented Oct 19, 2020

LaysDragon commented Oct 20, 2020

xrubick commented Apr 18, 2021 • edited Loading

vildek commented Apr 30, 2021

black-snow commented Jul 2, 2021

nevalla commented Jul 2, 2021

LaysDragon commented Jul 2, 2021 • edited Loading

black-snow commented Jul 2, 2021

nevalla commented Jul 3, 2021

LaysDragon commented Jul 3, 2021 • edited Loading

nevalla commented Jul 3, 2021

LaysDragon commented Jul 3, 2021 • edited Loading

nevalla commented Jul 3, 2021

LaysDragon commented Jul 4, 2021

LaysDragon commented Jul 6, 2021 • edited Loading

MartinGolding515 commented Jul 15, 2021

WLun001 commented Aug 10, 2021

Ajay250496 commented Aug 16, 2021 • edited Loading

EDIT

davekats commented Aug 17, 2021 • edited Loading

jvandervelden commented Oct 22, 2021

jvandervelden commented Oct 22, 2021

XFNeo commented Oct 26, 2021

LaysDragon commented Oct 26, 2021 • edited Loading

davekats commented Oct 26, 2021

LaysDragon commented Oct 26, 2021 • edited Loading

XFNeo commented Oct 26, 2021 • edited Loading

jc-roman commented Jan 17, 2022 • edited Loading

pduchnovsky commented Jan 26, 2022

Bafff commented Jan 27, 2022 • edited Loading

philipp1992 commented Feb 6, 2022

pkerschbaum commented Mar 10, 2022

Bafff commented Mar 10, 2022

pkerschbaum commented Mar 10, 2022

Bafff commented Mar 10, 2022

pkerschbaum commented Mar 10, 2022

Bafff commented Mar 10, 2022

pkerschbaum commented Mar 10, 2022

hpzzz commented Mar 10, 2022

Bafff commented Mar 10, 2022

pkerschbaum commented Mar 10, 2022

PePoDev commented Mar 19, 2022

jvandervelden commented Mar 19, 2022

PePoDev commented Mar 19, 2022

ZILosoft commented May 31, 2022

romubaron commented Jun 28, 2022

pureliumy commented Sep 22, 2022 • edited Loading

kobethuwis commented Oct 21, 2022 • edited Loading

DzeryCZ commented Dec 7, 2022

kobethuwis commented Mar 22, 2023

robertomanfreda commented Jul 10, 2023

jhonnyll commented Jul 11, 2023

MartinGolding515 commented Nov 9, 2023

wr-jc commented Jan 22, 2024 • edited Loading

LaysDragon commented Oct 19, 2020 •

edited

Loading

xrubick commented Apr 18, 2021 •

edited

Loading

LaysDragon commented Jul 2, 2021 •

edited

Loading

LaysDragon commented Jul 3, 2021 •

edited

Loading

LaysDragon commented Jul 3, 2021 •

edited

Loading

LaysDragon commented Jul 6, 2021 •

edited

Loading

Ajay250496 commented Aug 16, 2021 •

edited

Loading

davekats commented Aug 17, 2021 •

edited

Loading

LaysDragon commented Oct 26, 2021 •

edited

Loading

LaysDragon commented Oct 26, 2021 •

edited

Loading

XFNeo commented Oct 26, 2021 •

edited

Loading

jc-roman commented Jan 17, 2022 •

edited

Loading

Bafff commented Jan 27, 2022 •

edited

Loading

pureliumy commented Sep 22, 2022 •

edited

Loading

kobethuwis commented Oct 21, 2022 •

edited

Loading

wr-jc commented Jan 22, 2024 •

edited

Loading