Developer Tooling for Kubernetes in 2021 - IntelliJ, VSCode, Gitpod, and Lens (Part 3)

Table of Contents

Over the last few days, I have been hard at work writing an up to date comparison of Kubernetes tooling (check out the first and second posts if you haven’t already, which cover tools that help you reproduce issues locally). Going through the sprawling Kubernetes ecosystem and curating the knowledge that would be the most interesting to fellow developers and engineering managers has been no small task. That’s why section 3 will cover the heart of cloud-native development: the IDE.

Some of the questions I have been struggling with have been:

  1. Which tools should I cover?
  2. How do I categorize the tools in an easy to read manner?
  3. Which tools are worth mentioning, and which are too niche or immature?
  4. How do I write about the tools I have been using daily for years versus the tools I have never actually used?

I hope I have been doing well so far, and I would love to hear some feedback from you. In the meantime, I’ll dedicate this blogpost to the set of tools that is closest to every developer's heart. What IDEs support Kubernetes development, and how? Whether you are a fan of JetBrains, VSCode, Gitpod, or Lens you should check it out.


Ever since launching the first version of IntelliJ in January 2001 (what a start of the century!) JetBrains has defined the gold standard for the industry with its line of IDEs. With eleven different products for all the major programming languages out there, they are my personal favorite.

As a traditional IDE, IntelliJ focuses on providing you with the best possible experience as you are writing, building, and debugging code on your machine. It has built-in support for building and debugging Docker containers, but for Kubernetes support, we have to look to the extensive plugin marketplace.

From JetBrains, we have an official Kubernetes plugin. First and foremost, this plugin allows you to interact with Kubernetes clusters directly, viewing and editing cluster objects, seeing pod logs, and even running a remote shell. Additionally, the plugin provides rich editor capabilities for working with Kubernetes manifests, Helm charts, and Kustomize patches.

On top of that, all the major cloud vendors have their plugins for JetBrains. The Azure and AWS plugin deal mostly with Serverless workloads, but GCP’s offers many capabilities for working with Kubernetes.

VS Code

Visual Studio Code, the (relatively new) open-source IDE by Microsoft, is making waves in software development circles. VS Code is plugin-oriented, and extensions implement even the most elementary features such as Git integration and language-support. The VS Code marketplace is enormous and filled with high-quality plugins from Microsoft and many third-party vendors.

The official Kubernetes plugin is feature-rich. This extension has all the basics, such as viewing and editing cluster objects, accessing logs, and running a remote shell. It also contains a few more advanced features such as browsing Helm repositories, port forwarding, and remote container building/execution.

If you happen to be using the Azure Kubernetes Service for running your Kubernetes cluster, two new plugins may be of particular interest to you. The first, Bridge to Kubernetes, enables you to run a local application on your machine within the cluster’s network perimeter, potentially allowing you to create a local development and debugging environment. The second is the Azure Kubernetes Service (still in preview), which offers a more profound integration with AKS clusters.

With the thriving VS code marketplace, there are many other relevant plugins. For GCP users, an appropriate plugin with a Kubernetes integration is available. Unfortunately, the AWS plugin for VS Code deals mostly with Serverless workloads, and only has minor support for Kubernetes. Going through the marketplace, you are likely to find many more niche plugins, some of which might support other tools you happen to be using.

You might also want to keep track of the launch of Github Codespaces. Codespaces will empower you to migrate your development workload to the cloud in a (hopefully) seamless manner. It’s not Kubernetes focused yet, but I’m sure that day is not too far down the road.


Gitpod is a new IDE taking a cloud-first approach to cloud-native development. When using Gitpod, you are getting a VS-Code-like IDE (based on Theia) accessible from your browser. Any task you will execute, such as building and running applications, will be performed in a remote Kubernetes cluster.

The UI looks and feels very much the same, and you get access to any VS Code compatible extensions. In addition to classic IDE capabilities, Gitpod adds collaboration features such as sharing live development environments, taking static snapshots of environments, and code review.

Gitpod is all about optimizing the developer’s experience and making it as smooth and fast as possible. As part of that mindset, Gitpod will spin up as many environments as you may need, and allow you to easily switch between them. Gitpod will even work with multiple environments simultaneously. Gitpod employs various performance enhancement techniques such as prebuilding environments, offering a Chrome extension, and optimizing development environments deployed to Kubernetes.

Gitpod is still very young and may not be mature enough for you. It offers an intriguing alternative, especially for those who don’t want to rely on spinning up complex or resource-intensive development environments locally. Get started by refixing any GitLab, GitHub, or Bitbucket URL with


For some of us, hearing the phrase “IDE for Kubernetes” brings to mind the image of a feature-rich interactive UI that allows us to see anything and do anything with our Kubernetes clusters. A kubectl on steroids. If that’s you, you will be happy to find Lens.

Lens is a standalone application that allows you to connect to your Kubernetes clusters and manage them on the fly. Lens will enable you to go through and update every type of Kubernetes object, including workloads (i.e., deployments), configurations, networking, storage, access control, and even custom resources. It is designed from the ground up to work in a multi-cluster environment and makes it an intuitive process. It even has built-in Helm support, allowing you to browse through repositories for available Helm charts, and see which charts are deployed on your cluster.

However, it’s important to note that Lens is not an IDE in the traditional sense. You will not be using it to create and edit source or configuration files. You will not be using it to build, execute, or debug your application. Lens is all about giving you full visibility and control over your Kubernetes clusters.


An IDE is an integral part of every software engineer's daily workflow. When it comes to cloud-native software development, you have a couple of options:

  1. Stick with a traditional IDE, relying on plugins and third-party tools to bridge your workflows over to Kubernetes.
  2. Switch to a cloud-first IDE, one built from the ground up to provide a cloud-native and Kubernetes focused experience.

If your engineers are anything like any developer I have ever worked with, they already have a favorite IDE that they stick to religiously. Hopefully, by introducing them to some cool, sexy, new IDEs - with the added benefit of solving Cloud Native challenges they face every day - they may take your suggestion into consideration. My two cents here is that it's usually better to empower team members to choose their tools or offer them a few alternatives rather than force a uniform, one size fits all, solution.

Getting started is a breeze