vscode-kubernetes-tools turns the cluster into a VS Code tree view

An extension that wraps the tools you already have

vscode-kubernetes-tools is the Kubernetes extension for Visual Studio Code, published under the ms-kubernetes-tools publisher, and the README states its audience plainly: developers building applications to run in Kubernetes clusters and DevOps staff troubleshooting Kubernetes applications. It works with any Kubernetes anywhere, with Azure, Minikube, AWS and GCP named. The important design fact is that the extension does not implement a Kubernetes client. It invokes command line tools that must be on your PATH, and the dependency list names kubectl, docker or buildah, and helm, with az for Azure cluster creation, minikube if you want it, and git for the sync working copy to repository feature. The README recommends installing those binaries before using the extension, notes that some commands will not work without them, and says that if a core Kubernetes tool is missing the extension will offer to install it. So the mental model is a graphical front end over a CLI you were going to use anyway, which is why it survives contact with real clusters.

The cluster explorer tree is the entry point

The primary surface is an explorer tree view. You see your clusters in the tree and drill into workloads, services, pods and nodes, and you can watch resources in the cluster explorer and get live updates as they change, with Kubernetes: Watch and Kubernetes: Stop Watching bound to specific resources. The tree is also where the resource commands live, including Kubernetes: Get for the status of a specific resource, Kubernetes: Describe to describe the object in a terminal window, Kubernetes: Delete and Kubernetes: Delete Now, which force deletes a pod immediately without waiting for graceful termination. Kubernetes: Copy Name puts a resource name on the clipboard, and Kubernetes: Run CronJob Now manually triggers a CronJob to run immediately rather than waiting for its schedule. For a troubleshooting session, the useful pair is Describe and the event commands, since Kubernetes: Follow Events and Kubernetes: Show Events work on a selected namespace and are usually where the answer to a crash loop lives.

Manifest editing, diffs and the link back to Git

The second half of the extension works on files rather than on the cluster, and this is where it is more than a viewer. You can edit Kubernetes resource manifests and apply them to your cluster, with Kubernetes: Create to create an object from the current document, Kubernetes: Apply to apply changes, Kubernetes: Expose to expose the object as a service, and Kubernetes: Diff to show the difference between a local copy of the object and the one deployed to the cluster. That diff runs in both directions against reality, which is the feature that catches a manifest that was edited but never applied. There is also Kubernetes: Explain, which uses the kubectl explain tool to annotate Kubernetes API objects, and IntelliSense for Kubernetes resources and for Helm charts and templates, so the editor knows the shape of the object while you type it. The link back to source control is the Kubernetes: Diff command against a manifest in your Git repo, and the extension can check out the Git commit corresponding to a deployed application, which is how you find out what is actually running in a cluster that has drifted from the repository.

Run and Debug need a container registry you configure first

Running an application from the editor requires one setting before anything else works. The Kubernetes: Run and Kubernetes: Debug features need a configured user and repository for your container images, because the commands push an image of your application for the cluster to run it. The setting is added to your VS Code preferences under File, Preferences:

{
  "vsdocker.imageUser": "<your-image-prefix-here>",
}

The placeholder is something like docker.io/brendanburns, so the value is a registry prefix with your user in it. With that in place, Kubernetes: Run runs the current application as a Kubernetes Deployment, Kubernetes: Terminal opens an interactive terminal session in a pod of that Deployment, and Kubernetes: Exec runs a command in a pod. The debug commands are the heaviest feature. Kubernetes: Debug (Launch) runs the application as a Deployment and attaches a debugging session to it, and the documentation says it supports Go, Java, Node.js, Python and .NET deployments, with a separate document on debug on Kubernetes cluster in the repository. Kubernetes: Debug (Attach) attaches to an existing Deployment. The building blocks come from the same place as the rest of the tooling, since the repository carries a Dockerfile for building container images in the cluster from Dockerfiles in your project, and the snippet and schema directories for the language support.

Helm charts, logs, port forwarding and kubeconfig juggling

Helm support is broader than a single install command. You can browse Helm repos and install charts into your Kubernetes cluster, create Helm charts using scaffolding and snippets, and get IntelliSense for charts and templates. The repository shows how much of this is first party, with rawsnippets/, snippets/, buildsnippets/, syntaxes/ and schema/ directories at the top level, and a separate recommendation/ directory. For day to day operations there are the log commands, Kubernetes: Logs opens a view with options to display or follow logs, and the extension can follow logs and events from your clusters. Kubernetes: Port Forward forwards local ports to your application's pods, which is the usual way to reach a service that is not exposed. The kubeconfig handling is where configuration gets interesting, because the extension defaults to the active kubeconfig file, that is, the file the KUBECONFIG environment variable points to, or the default kubeconfig if that variable is unset. You can override it with the vs-kubernetes.kubeconfig setting in user or workspace settings, and for multiple clusters you can list them in vs-kubernetes.knownKubeconfigs and switch with the Set Kubeconfig command.

Where the extension stops and the cluster takes over

The limits come from the fact that the extension is a front end over command line tools, and it is honest about the edges. It works with any Kubernetes because it only calls kubectl, so any cluster behaviour that kubectl does not expose is not reachable from the tree, and the extension cannot tell you about it. The Kubernetes: Delete Now command exists precisely because the graceful path is sometimes too slow, which tells you how often the happy path is not the one you want. IntelliSense for Kubernetes resources depends on the schema information the extension can obtain, and for Helm it depends on the chart and its templates rather than on a general schema. The build and debug features are the heaviest dependency, since they need a registry prefix, a build tool and a cluster that can pull the image, and the image push is a step people forget until a run fails. The extension also is not a deployment pipeline. It applies from the editor, on a developer's machine, and for a team that wants a reviewed, automated path to a cluster, that belongs in CI rather than in a command palette.

Project shape, versions and how the build is organised

The repository is the Kubernetes Tools organisation's project, with the module path still pointing at the older Azure organisation, github.com/Azure/vscode-kubernetes-tools, and a small Go module whose only direct requirement is the sprig template library, which is there for Helm template rendering. The extension itself is TypeScript, bundled with webpack, with an eslint config, husky hooks, a package-lock and a tsconfig. The extension version in package.json reads 1.4.1, the engine requirement is VS Code 1.125.0 or later, and the activation events are limited to the helm and yaml languages and a filesystem scheme for the cluster, so the extension does not load for every file you open. Releases 1.4.1, 1.4.0 and 1.3.29 were published in 2026, with the last push on 2026-10-15. The licence is Apache-2.0, and the repository carries a GOVERNANCE.md and an OWNERS.md, which tells you this is run under an ownership model rather than by a single maintainer. The CHANGELOG.md at the root is where the release notes live, and the configuration keys in the manifest are namespaced under vs-kubernetes.

Editorial conclusion

Adopt vscode-kubernetes-tools when your day to day work is deploying to and debugging inside Kubernetes from VS Code, and when you are comfortable installing kubectl and helm on your PATH. Do not adopt it as a replacement for kubectl or a cluster management plane, since the extension drives those binaries rather than reimplementing them, and do not use it for GitOps deployments where a pipeline owns the apply step. Verify first that the kubectl version you have is one the extension supports, that your kubeconfig selection through vs-kubernetes.kubeconfig and vs-kubernetes.knownKubeconfigs behaves as you expect in a multi cluster setup, and that the vsdocker.imageUser setting is correct before you use Kubernetes: Run or Kubernetes: Debug.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vscode-kubernetes-tools/vscode-kubernetes-tools on GitHub