Failed to get contexts

[CapKenR]

Expected behaviour

When I open the GitOps Tools extension I expect it to use the current context from my kubeconfig. It's always worked that way in the past.

Actual behaviour

Instead, I get a message saying "Failed to get contexts: Config fetched, but contexts not found."

Steps to reproduce

Open code from a WSL command line. Select the GitOps Toolkit extension.

Versions

kubectl client v1.25.0 kubectl server v1.22.9+vmware.1 Flux: v0.32.0 Git: 2.25.1 Azure: 2.40.0 Azure extension "k8s-configuration": not installed Azure extension "k8s-extension": not installed VSCode: 1.72.0 Extension: 0.22.0 OS: Linux x64 5.15.57.1-microsoft-standard-WSL2

[kingdonb]

Thanks for the report! I'm sorry we haven't got back to you before now! We have been embroiled in some KubeCon related things and missed you.

Have you been able to resolve this? We expect the KUBECONFIG environment variable to be respected, unless you have leveraged the Set KubeConfig option here, which can change the setting for both the GitOps Tools extension and the Kubernetes Tools extension together. (We use their contribution point, so it is the same KUBECONFIG on the backend.)

I think this feature should be present in the version that you have installed. Please let us know if you gave up, or if this might have been resolved?

[CapKenR]

It's still broken and it looks like I have the newest versions of VS Code and the extension installed. A kubectl config get-contexts shows 5 contexts. However, 2 of the contexts don't work any more.

[CapKenR]

I deleted the 2 contexts that didn't work but still get the same error.

[CapKenR]

There is an additional error message now. (See below.) I'm not sure why it would be trying to connect to localhost:8080 as it's not referenced anywhere in ~/.kube/config.

"Failed to get namespaces W1118 10:18:44.957472 6790 loader.go:221] Config not found: [object Object] The connection to the server localhost:8080 was refused - did you specify the right host or port?"

[kingdonb]

Can you provide a screenshot so we can see some context of the error and how it's presented?

Thanks for following up 👍 another question, if you do "Command-Shift P" or however you get to the command palate on your OS, and check the config through this option:

do you find a config section that matches this:

I suspect that the environment variable is being lost, or the config setting is not being used properly, perhaps it has been overridden somewhere.

What other information might help us to debug this: a sanitized version of your kubeconfig and any env variables that might be kubectl-related from your env (again, sanitized)

We definitely are going to have some WSL linux users, and it's a fact that one of us on the developer team is using WSL as well, (maybe @juozasg can help us shed some light) on whether he has had a similar experience?

If so we can add an FAQ how to work around it. Thank you for the added detail @CapKenR !

When there is no kubeconfig, the default behavior of kubectl is to check localhost:8080 for an unsecured endpoint, like used to be possible in Kubernetes versions ~1.4 or thereabouts, back before RBAC was enabled by default, and insecure localhost access with no auth required was considered OK... (and that's why I suspect the KUBECONFIG setting simply is not being honored, it seems that either it is being lost on the way into VSCode or lost on the way out to the kubectl CLI.)

I don't remember exactly how many versions back that is, and it's probably not important either, but I suppose there is probably some non-vestigial explanation for that behavior to remain in the client, now that insecure configs are less commonplace/generally prevented from a policy perspective in the standard kubeadm distro. Anyway, that's how you get localhost:8080 connections when there is no such cluster endpoint in the kubeconfig file, it likely means that the kubeconfig file isn't connected at all.

[kingdonb]

If you think you can narrow down the issue and a patch is needed, we can try it in the pre-release channel. There are some patches in the pre-release channel that you might be interested in as well, though I don't think we've done anything that will have an impact on this issue.

We're very keen to help iron out these usability issues and flesh out the docs with troubleshooting steps.

[CapKenR]

First, it’s not just a WSL problem. If I open VS Code from PowerShell and the Windows desktop, I get the same behavior. I made a short video of starting VS Code from WSL then going to the GitOps extension. You can find it at https://clipchamp.com/watch/gDzBy58oP1l.

Second, my settings.json, regardless of where I open VS Code from, is the same and doesn’t have a vs-kubernetes.knownKubeconfigs. It only has a vs-kubernetes.kubeconfig.

    "vs-kubernetes": {
        "vs-kubernetes.kubeconfig": {
            "collapsibleState": 2,
            "label": "docker-desktop",
            "children": [],
            "clusterProvider": "Generic",
            "clusterProviderManuallyOverridden": false,
            "isCurrent": true,
            "cluster": {
                "name": "docker-desktop",
                "cluster": {
                    "server": "https://kubernetes.docker.internal:6443",
                    "certificate-authority-data": "DATA+OMITTED"
                }
            },
            "clusterContext": {
                "name": "docker-desktop",
                "context": {
                    "cluster": "docker-desktop",
                    "user": "docker-desktop",
                    "clusterInfo": {
                        "name": "docker-desktop",
                        "cluster": {
                            "server": "https://kubernetes.docker.internal:6443",
                            "certificate-authority-data": "DATA+OMITTED"
                        }
                    }
                }
            },
            "clusterName": "docker-desktop",
            "contextName": "docker-desktop",
            "description": "https://kubernetes.docker.internal:6443",
            "iconPath": {
                "light": {
                    "$mid": 1,
                    "path": "/c:/Users/KenRider/.vscode/extensions/weaveworks.vscode-gitops-tools-0.22.3/resources/icons/light/cloud.svg",
                    "scheme": "file"
                },
                "dark": {
                    "$mid": 1,
                    "path": "/c:/Users/KenRider/.vscode/extensions/weaveworks.vscode-gitops-tools-0.22.3/resources/icons/dark/cloud.svg",
                    "scheme": "file"
                }
            },
            "isGitOpsEnabled": false
        }
    },

My WSL kubeconfig (/home/ken/.kube/config):

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.docker.internal:6443
  name: cluster-b796g6fbkm
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.docker.internal:6443
  name: docker-desktop
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://tkg-mgmt-azure-20220609080551-xxxxxxxx.westus2.cloudapp.azure.com:6443
  name: tkg-mgmt-azure-20220609080551
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://tkg-workload-azure-xxxxxxx.westus2.cloudapp.azure.com:6443
  name: tkg-workload-azure
contexts:
- context:
    cluster: docker-desktop
    user: docker-desktop
  name: docker-desktop
- context:
    cluster: tkg-mgmt-azure-20220609080551
    user: tkg-mgmt-azure-20220609080551-admin
  name: tkg-mgmt-azure-20220609080551-admin@tkg-mgmt-azure-20220609080551
- context:
    cluster: tkg-workload-azure
    namespace: default
    user: tkg-workload-azure-admin
  name: tkg-workload-azure-admin@tkg-workload-azure
current-context: tkg-mgmt-azure-20220609080551-admin@tkg-mgmt-azure-20220609080551
kind: Config
preferences: {}
users:
- name: docker-desktop
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: tkg-mgmt-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: tkg-mgmt-azure-20220609080551-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: tkg-workload-azure-admin
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
- name: user-b796g6fbkm
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

My Windows kubeconfig (C:\Users\KenRider.kube\config):

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://kubernetes.docker.internal:6443
  name: docker-desktop
contexts:
- context:
    cluster: docker-desktop
    user: docker-desktop
  name: docker-desktop
current-context: docker-desktop
kind: Config
preferences: {}
users:
- name: docker-desktop
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED

In regards to the localhost:8080 question, it must not be using my default kubeconfig or the kubeconfig referenced in settings.json as both have valid contexts.

[kingdonb]

OK, my best guess right now is that something fails when the extension sets your KUBECONFIG.

Can you please try one more thing? Using this widget, could you point the extension at a Kubeconfig you want it to use:

This should result in a "known kubeconfigs" section being added to your settings.json – if you have set a kubeconfig there and it still does not connect from end to end, then we know for sure the problem is somewhere between the extension and the kubectl binary (and not just a matter of KUBECONFIG somehow not being passed in properly to the editor's context)

[kingdonb]

For what it's worth, we use the same method to attach kubectl as the kubernetes-tools extension that comes from Microsoft. So it should also be the case that, if you switch to the Kubernetes extension and try to use it to do some kind of inspection on the clusters, you will most likely get the same bad behavior there.

[CapKenR]

That worked. My settings.json now has the vs-kubernetes.kubeconfig and vs-kubernetes.knownKubeconfigs. I had to add both the WSL and the Windows default kubeconfig. However, I do get the same error message when I switch between the two. I must then use the Set Kubeconfig widget again.

{

"workbench.colorTheme": "Default Dark+",

"redhat.telemetry.enabled": true,

"git.autofetch": true,

"vs-kubernetes": {

    "vs-kubernetes.kubeconfig": "/home/ken/.kube/config",

    "vs-kubernetes.knownKubeconfigs": [

        "/home/ken/.kube/config",

        "c:\\Users\\KenRider\\.kube\\config"

    ]

},

"security.workspace.trust.untrustedFiles": "open",

"window.commandCenter": true

}

From: Kingdon Barrett @.> Sent: Sunday, November 20, 2022 4:43 AM To: weaveworks/vscode-gitops-tools @.> Cc: Ken Rider @.>; Mention @.> Subject: Re: [weaveworks/vscode-gitops-tools] Failed to get contexts (Issue #393)

OK, my best guess right now is that something fails when the extension sets your KUBECONFIG.

Can you please try one more thing? Using this widget, could you point the extension at a Kubeconfig you want it to use: https://user-images.githubusercontent.com/3286998/202899984-7789c03e-d9db-4b1c-a39e-732ce24cfa97.png

This should result in a "known kubeconfigs" section being added to your settings.json – if you have set a kubeconfig there and it still does not connect from end to end, then we know for sure the problem is somewhere between the extension and the kubectl binary (and not just a matter of KUBECONFIG somehow not being passed in properly to the editor's context)

— Reply to this email directly, view it on GitHub https://github.com/weaveworks/vscode-gitops-tools/issues/393#issuecomment-1321109847 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC3EFK5UDBSR73CUT3WHFXLWJIFCVANCNFSM6AAAAAAQ77C2FU . You are receiving this because you were mentioned. https://github.com/notifications/beacon/AC3EFK25QWLXWW4OMMJABY3WJIFCVA5CNFSM6AAAAAAQ77C2FWWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSOX2EVO.gif Message ID: @. @.> >

[kingdonb]

Hello,

We have done a major refactor in 0.25.0 and are hoping that your issue has resolved itself. If you see it persists, then we can perhaps address it better now that the refactor is out of the way! The new model still uses kubectl for limited things but it mostly works through a JavaScript library that talks to kube API through a proxy connection.

Are you still in a position to test and confirm if the issue persisted on 0.25.0?

[CapKenR]

My (related) settings are the same as I left them back in November.

    "vs-kubernetes": {
        "vs-kubernetes.kubeconfig": "/home/ken/.kube/config",
        "vs-kubernetes.knownKubeconfigs": [
            "/home/ken/.kube/config",
            "c:\\Users\\KenRider\\.kube\\config"
        ],

When I open VS Code in WSL, everything works. If I open VS Code from Windows, I get the following error.

> flux check --pre
► checking prerequisites
✗ flux 0.35.0 <2.0.1 (new version is available, please upgrade)
W0731 11:57:58.584545    1708 loader.go:223] Config not found: /home/ken/.kube/config
✗ Kubernetes API call failed: Get "http://localhost:8080/version": dial tcp [::1]:8080: connectex: No connection could be made because the target machine actively refused it.

If I use Set Kubeconfig to use "C:\Users\KenRider.kube\config" I get the following error even though kubectl is working from PowerShell and a command prompt.

Failed to load kubeconfig: c:\Users\KenRider\.kube\config Error: 'kubectl' is not recognized as an internal or external command, operable program or batch file. . Code: 1

[kingdonb]

Thanks for the specific detail, I'll see if we can't have someone with this context and a Windows install reproduce the issue.

[kingdonb]

v0.25.1 delivers significant UX improvements, We have not had the resources budgeted for AKS testing, but we plan to wrap back around and verify all features are still at parity within the next few releases.

There are some minor performance issues we would like to nail down yet, but if you have any feedback about this release we would appreciate it!

[onedr0p]

I seem to be having the same issue, the kubernetes extension works with the below relative path but not this vs extension. I get if I make this a abs path it will likely work, but I separate my kubeconfigs per gitops repo and include a .vscode/settings.json workstation file in each repo.

workspace config

    "vs-kubernetes": {
      "vs-kubernetes.kubeconfig": "./kubeconfig",
      "vs-kubernetes.knownKubeconfigs": [
        "./kubeconfig"
      ]
    },

error

Error loading document: CodeExpectedError: cannot open file:///kubeconfig. Detail: Unable to read file '/kubeconfig' (Error: Unable to resolve nonexistent file '/kubeconfig')