pod shell not working while proxy configured

[funcx27]

Describe the bug

When I perform Pod shell with http proxy. I got error

To Reproduce Steps to reproduce the behavior:

1. configure proxy
2. go to pod
3. click Pod shell and see error

Expected behavior kubectl exec into pod

Environment (please complete the following information):

• Lens Version: 4.0.8
• OS: windows10
• Installation method (e.g. snap or AppImage in Linux): scoop

Logs: When you run the application executable from command line you will see some logging output. Please paste them here:

error: unable to upgrade connection: error dialing backend: dial tcp 192.168.7.28:6443: connectex: A connection attempt failed because the connected party did
 not properly respond after a period of time, or established connection failed because connected host has failed to respond.

[gtskaushik]

Facing a similar issue. I'm behind a corp proxy. At this point I'm unable to shell into the pods

[CZmikee]

Similar issue on 4.1.1 with corporate proxy and GKE pods, Windows 10. Proxy is set both in preferences and cluster settings.

Running shell to pod will end with error error: unable to upgrade connection: error dialing backend: dial tcp XXX:443: connectex: No connection could be made because the target machine actively refused it.

Logs show Error while proxying request: error dialing backend: dial tcp XXX:443: connectex: No connection could be made because the target machine actively refused it.\n","error":true,"meta":{"id":"XX","name":"XXX","initialized":true,"ready":true,"online":true,"accessible":true,"disconnected":false}}

Running the same via Powershell directly (not in Lens) works fine, running other kubectl commands (in Lens) work fine (e.g. kubectl get pods -n XX from inside Lens terminal works fine) . Adding localhost or 127.0.0.1 to no_proxy env does not help.

[jeremyd]

I have the same issue. Using a proxy everything works fine except for exec. Exec is missing the HTTPS_PROXY=localhost:8888 settings that are set in the lens config. If I take the same command lens is running to perform the exec and add HTTPS_PROXY environment variable the kubectl exec command works.

lens version = 4.1.2

[mirkoszy]

Can't wait for the fix

[gtskaushik]

Waiting for this

[gjaldon]

This is still an issue in Lens 4.2.1 on Macos. All other kubectl commands from within Lens terminal seem to work fine. Only kubectl exec doesn't work when a proxy is set. I see $HTTPS_PROXY env var is set in the terminal though but don't understand why it doesn't work for kubectl exec.

[jhourque]

Same issue here. Powershell in terminal has a weird behavior. I can't access to environment vars:

Get-ChildItem -Path Env:
Get-ChildItem : Un élément avec la même clé a déjà été ajouté. Au caractère Ligne:1 : 1

• Get-ChildItem -Path Env:\

•   + CategoryInfo          : NotSpecified: (:) [Get-ChildItem], ArgumentException
    + FullyQualifiedErrorId : System.ArgumentException,Microsoft.PowerShell.Commands.GetChildItemCommand
  
  

Same command in another powershell works fine.

[tvanderka]

Shell/exec/port-forward do not work in Lens if cluster is behind http proxy because Lens uses "kubectl proxy" to communicate with the cluster (replacing server url in kubeconfig) which is broken. Root cause is "kubectl proxy" ignores http proxy for "connection upgrades" (spdy protocol) and connects directly instead. The result is you get one of connection refused, unknown host, timeout errors. Example:

# should work
HTTPS_PROXY=ip:port kubectl exec somepod -- uname -a
# this is broken, and is what Lens does
HTTPS_PROXY=ip:port kubectl proxy -p 11111 -v8 --reject-paths='^[^/]' &
kubectl -s localhost:11111 exec somepod -- uname -a

[mmslkr]

A hacky workaround on Win10 using WSL, based on the comment by @tvanderka:

First make sure kubectl works inside WSL. Then set wsl.exe as "TERMINAL SHELL PATH" in Lens. Finally, add the following snippet to your WSL .bashrc (or equivalent):

if [ -n "$LENS_SESSION" ]; then
        c=$(kubectl config current-context)
        export KUBECONFIG=""
        kubectl config use-context "$c"
fi

Lens is creating a temporary kubectl config refering to the "kubectl proxy" and pointing to it via env variable KUBECONFIG inside the shell it creates to enter pods. This snippet reads the context from the temporary config, unsets it and sets the same context, this time from your normal config. This will probably not work if you use more complex setups / multiple configs.

[joaogomez]

Hey guys while we don't have a solution I've created a bash script to workaround it on linux/macos.

After the exec command I'm restoring on background the original context to avoid unwanted context updates on your environment.

#!/bin/bash
#https://github.com/lensapp/lens/issues/2021
shopt -s expand_aliases
alias kubectlens="/usr/local/bin/kubectl"
LENS_CONTEXT=$(kubectlens config current-context)
echo "Lens Context: $LENS_CONTEXT"
export KUBECONFIG=""
DEFAULT_CONTEXT=$(kubectlens config current-context)
echo "Default Context: $DEFAULT_CONTEXT"
kubectlens config use-context "$LENS_CONTEXT"
(sleep 1 && kubectlens config use-context "$DEFAULT_CONTEXT" >> /dev/null) &
kubectlens "$@"

Create a bash file with it and point your lens kubectl to this file on preferences.

[kodem-shayel]

it's been quite a while here, I want to share a solution I found for mac, worked for my case using zsh:

# shell extension to make openlens work with pod terminal
if [[  "${TERM_PROGRAM}" -eq "OpenLens" ]]; then
        echo "OpenLens Terminal detected overriding kubectl to empty kubeconfig"
        lens_current_context=$(kubectl config current-context)
        echo "running in context ${lens_current_context}"
        kubectl() {
          export KUBECONFIG=""
          command kubectl --context ${lens_current_context} $@
        }
fi

Thanks for all the info here for a better understanding here for building this hacky and yet simple solution

[3RX0]

it's been quite a while here, I want to share a solution I found for mac, worked for my case using zsh:

# shell extension to make openlens work with pod terminal
if [[  "${TERM_PROGRAM}" -eq "OpenLens" ]]; then
        echo "OpenLens Terminal detected overriding kubectl to empty kubeconfig"
        lens_current_context=$(kubectl config current-context)
        echo "running in context ${lens_current_context}"
        kubectl() {
          export KUBECONFIG=""
          command kubectl --context ${lens_current_context} $@
        }
fi

Thanks for all the info here for a better understanding here for building this hacky and yet simple solution

Nice one but my lens (not OpenLens) is using command composition like exec /bin/kubectl ....... so this doesn't work for obvious reasons. Went for solution from @joaogomez.

[martinwagenmann]

Please tell me someone has solved this problem. What is the proxy settings even good for than?

[glitchracer]

Configure OpenLens -> Preferences -> Terminal -> Terminal Shell Path:

C:\Program Files\PowerShell\7\pwsh.exe

In your pwsh profile exclude everything else for a non OpenLens session with:

if (-not(Test-Path env:LENS_SESSION)) {
...
}

For OpenLens Session add:

if (Test-Path env:LENS_SESSION) {
   $context = $(kubectl config current-context)
   $env:KUBECONFIG = $env:USERPROFILE + "\.kube\config"
   kubectl config use-context $context

[null9beta]

The problem unfortunately still exists.

Lens: 2024.1.300751-latest
Extension API: 6.10.33
Electron: 27.2.4
Chrome: 118.0.5993.159
Node: 18.17.1
© 2023 Mirantis, Inc.

Any idea how to solve it?

[Str1ker17]

Reporting the same issue. For me, the GCP Kubernetes pod shell connects directly and not though proxy. The faulty executable is lens-k8s-proxy.exe