11 of the Best Open-Source Kubernetes Tools - 2021 Edition
Tags: kubernetes, docker, ide
Published: 2021-06-02 20:58:32

---
title: 11 of the Best Open-Source Kubernetes Tools - 2021 Edition
published: true
description: A look at tools to help with running Kubernetes clusters, testing them, and IDEs for Kubernetes users!
tags: Kubernetes, Docker, IDE
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dzywn8p550pd8ra7lrwr.jpeg
---

By Matt Broberg

Nearly everyone touching cloud infrastructure in 2021 is familiar with the Kubernetes project. Put simply, Kubernetes is an incredibly powerful platform for container orchestration. But in my opinion, Kubernetes, more than anything, is a collection of best practices baked into a system that can scale from a Raspberry Pi up to the largest Fortune 500 infrastructure. It empowers developers and operators alike to collaborate through standardized APIs and meaningful abstractions (like a Pod or a ConfigMap).

Kubernetes can save an organization from decades of fumbling through rolling their own "container strategy" by offering an open source standard that, thankfully, is also a standard of every major cloud vendor. That said, something that’s as big of a beast as Kubernetes can be difficult to tame, and to use it to the best of it’s potential, you’ll need a suite of additional tools.

The incredible community around Kubernetes is constantly sharing tools that help improve the experience of being a Kubernetes developer. Here is my list of the 11 essential tools I keep in my arsenal. I break them down by important categories: which ones help me run Kubernetes, test Kubernetes, and—last but not least—have fun in my IDE.

## Category 1: Running Kubernetes Environments

### Minikube Still Works Well

![Minikube start command](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rvxw0aji03ok8hs9svcs.png)

Nearly every Kubernetes tutorial starts with "download Minikube" and that still makes sense today. If you want to fiddle with containers in a truly low-risk environment, the well-packaged and maintained Minikube project will have you [running a cluster in about 23 seconds](https://minikube.sigs.k8s.io/docs/).

### Helm Is Still the Standard for Repeatable Deployments

While we have all written a one-off script or two to deploy some configuration to Kubernetes, the de facto way to manage repeatable deployments is with Helm. Much like apt on Ubuntu or rpm for RHEL, Helm is a package manager that does so much for Kubernetes developers. As a developer, I want to test my application with other projects without much work. Instead of writing my own Jenkins setup, I can simply run `helm install jenkins/jenkins` and be on my way. To find it and other Kubernetes packages, check out the [Artifact Hub](https://artifacthub.io/).

### Run Rancher K3s Anywhere and Everywhere

Pushing containers to a near-perfectly maintained Kubernetes service is one thing, but what if you want to mess with one in the wild of your Raspberry Pi farm? The K3s project from Rancher can do the trick. It's ideal for any edge or IoT attempt at Kubernetes "clusterology," as the maintainers put it in the [README](https://github.com/k3s-io/k3s#k3s---lightweight-kubernetes).

What makes K3s stand out as an option for local and lightweight clusters is its extensive range of supported devices. You can truly run Kubernetes anywhere with K3s. The fact that it downloads as a single binary means it  includes all the functionality of a production Kubernetes configuration (sqlite3 is the default, but you can scale up to Etcd3 through its pluggable storage backend), and it is quite actively maintained by the team at Rancher and its 1,749 (to date) contributors.

### Loft for Scaling the Team

Anyone can spin up a Minikube cluster as mentioned above with a call to `curl`. But what if you want to collaborate with others? There are a ton of options at the intersection of cloud-native development tools and local development clusters. 

The traditional option is to spin up some publicly accessible resources on a public cloud: AKS, EKS, DigitalOcean Managed Kubernetes, or one of the many others available. But anyone who has run a `hello world` tutorial on a cloud service and forgotten to delete it knows that it will cost you a lot, and quickly.

[Loft](https://loft.sh/) offers a set of services, including a UI and CLI, to further abstract the Kubernetes environments they'll eventually run on in production. By doing so, you can set up a self-service experience without the same concern for isolation and budget.

![Loft Spaces view](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/egdn019h4n0a84rd0a2r.png)

Loft’s attention to isolation, especially with [vClusters](https://loft.sh/docs/self-service/virtual-clusters) and their corresponding [Spaces](https://loft.sh/docs/self-service/namespaces), gives every developer a real-world environment without the real-world hit to the budget. That can be quite the value to developers and department leads alike.

The value of Loft comes down to the speed of spinning up and down secure Kubernetes environments. One of their use cases mentions creating live demos of on-premises products in a single UI click. Thinking more selfishly, imagine demoing your latest production feature in its own isolated test case without mucking up your development cluster's namespaces. That sounds good to me.

Additionally, Loft Labs recently hired the amazing [Rich Burroughs](https://loft.sh/blog/meet-rich-burroughs/), and that's a good sign for the type of community they are putting together.

When working with a team, Loft makes a ton of sense. 
## Category 2: Simplify Feedback Loop

### Skaffold for Hands-free Feedback Loops

Imagine you're a developer (because you are) and you want to write an app that will run on Kubernetes (because you do). The amount of Kubernetes concepts you need to know, from running Node.js or Python applications to running containers on Kubernetes can feel like a wall of YAML. Thankfully, the good folks at Google wrote [Skaffold](https://skaffold.dev/) to provide some much-needed scaffolding.

Don't get me wrong: you will still need your code, a Dockerfile, a manifest file, and all the services associated with your pipeline. What Skaffold offers is a clean way to rerun your deployment pipeline after every change to your code. It's known and loved by its users with quotes on the homepage from around the world.

You may relate to this feeling: running Skaffold feels like the first time I ran Vagrant instead of managing virtual machines by hand. Tasks that once took a ton of steps and were unreliable became straightforward and repeatable in a way that simplified everything else I did. Skaffold
is set to do that for your testing and deployment feedback loop for Kubernetes.

### Podman to Stop Managing Docker Daemons

While Dockerfiles may forever be the way we express a container, Docker itself is completely optional. Even Kubernetes itself is shifting its runtime away from [Dockershim](https://kubernetes.io/blog/2020/12/02/dockershim-faq/). I cannot recommend [Podman](https://podman.io/) enough as a replacement for running Docker locally, for the sole reason you don't need to maintain a daemon service. Not messing with a daemon means less time fiddling and more time coding.

That distinction may be new to you, so to explain: Docker is both a client to interact with local containers and a daemon (aka server) managing the userspace where containers run. Nick Janetakis explains it perfectly [here](https://nickjanetakis.com/blog/understanding-how-the-docker-daemon-and-docker-cli-work-together).

![Docker client and server model](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/le16ahiq43tsalxk75ee.jpeg)
Like me, you may forget there is a distinction between the Docker client and server when everything is working correctly. That said, I too often see this message:

```bash
$ docker ps
$ Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
```

Now I am left with a choice. I could troubleshoot the Docker daemon and what service in my toolchain messed things up, or I could use something that doesn't run into the same problem. I prefer the latter.

Podman gives you the option to run containers as a child process, removing the need for a separate daemon. That means I never get that error message, and my containers keep doing what they do.

You may be holding back from change because your muscle memory is too embedded. In that case, I highly recommend removing the `docker` CLI and adding `alias docker=podman` to your shell configuration file.

### Tilt Really Understands Your App

![Tilt interface](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nmmxjsaxo8gnb4bk9glf.png)

While I covered a few different ways to manage your pipeline, I still find Tilt is the most thorough and visual way to see a continuous feedback loop from a Kubernetes-based application. The Tilt UI has incredibly succinct error catching that I find points out minor YAML errors before they become significant deployment errors. It also has customizable buttons to give you unique application-specific functionality, like flushing a message queue in your architecture between iterations.

Give [Tilt](https://tilt.dev) a swing if you know you want to see the details without being overwhelmed by them.
### Efficient Development Workflow with DevSpace

Do you love what `kubectl` can do but lose track of the multitude of commands needed to get it to do what you want? Then you're in luck, as [DevSpace](https://devspace.cloud/) is an open source command-line utility that wraps your Kubernetes developer experience up in what will feel like a warm hug. It will manage a ton of the tedious tasks so you can treat a Pod like it's running on your local system.

Additionally, if you have rather particular preferences, they can simply be added to the devspace.yaml declarative configuration file.

While it won't be a one-to-one replacement for the scalpel that `kubectl` provides, running DevSpace will give you a ton of sane default behaviors that will make interacting with real Kubernetes environments feel more like `$HOME`.

### Debug Faster with Lens IDE

Kubernetes projects like Minikube come out of the box with a sleek and straightforward GUI called [Dashboard](https://github.com/kubernetes/dashboard). It is an excellent read-focused view of the environment, but what if you want to do everything from a UI?

The most powerful option from the open source community is [Lens](https://k8slens.dev/). I really should not call it a GUI, because it's feature-rich enough to be considered an IDE. You can do anything Kubernetes is capable of doing within Lens with a click of the button. What I most enjoy about Lens is its incredible thought context-specific options that help me learn the distinction of a service from a namespace from the many other resources that need to be known in Kubernetes land.

## Category 3: IDE Dev Tools I Can't Live Without

### The Kubernetes Extension We All Need for VSCode

No Kubernetes development experience should be without an IDE that knows the difference between a Kubernetes resource and a Helm chart. That is where [Visual Studio Code Kubernetes Tools](https://marketplace.visualstudio.com/items?itemName=ms-kubernetes-tools.vscode-kubernetes-tools) shines. Anyone living in a Kubernetes world has to start by installing this one.

### Make YAML More Manageable with This VSCode Plugin

Kubernetes developers have been described as YAML farmers, and I think the shoe fits nicely. While I like a structured domain-specific language as much as the next Kubernaut, I will take any help I can get with managing YAML itself. Thankfully the [YAML Language Support](https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml) extension, supported by Red Hat, helps me help myself.

It offers up a ton of autocompletion options on top of many additional nuanced options that help me out. All that said, the ability to right-click and choose to "Format Document" is worth its weight in gold alone.

### Find Your Way Through Code with Footsteps

![Example of Footsteps highlighting changes to code](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/pqufdj48uh9l56k1zo2q.png)

While not strictly a Kubernetes extension, I find navigating the YAML farm can lead me to losing track of where I left off. Where was I in my 2,000 line configuration file again? That's when [Footsteps](https://github.com/Wattenberger/footsteps-vscode) shines a light on where my short-term memory has lost its footing. This brilliant extension, also for VSCode or its equivalents, will show you where you most recently edited a document through highlighted text. As you continue to edit code, Footsteps slowly fades those colors away, giving you a sense of your coding pattern. Install this and save yourself quite a few moments of feeling lost.

## Wrapping Up

There is an unbelievable amount of tools out there to help Kubernetes developers and operators navigate this new paradigm of container orchestration. I like to think about them in three buckets: do they help me run Kubernetes, test Kubernetes, or code in a Kubernetes-aware manner? All three of these categories can lead you to well-maintained software in the open source ecosystem that will help you be a better YAML herder like the rest of us.

Photo by [Cesar Carlevarino Aragon](https://unsplash.com/@carlevarino?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/tools?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)