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.
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.
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.
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.
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.
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 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’s attention to isolation, especially with vClusters and their corresponding Spaces, 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, 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.
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 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.
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. I cannot recommend Podman 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.
$ 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.
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 a swing if you know you want to see the details without being overwhelmed by them.
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 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
Kubernetes projects like Minikube come out of the box with a sleek and straightforward GUI called 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. 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.
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 shines. Anyone living in a Kubernetes world has to start by installing this one.
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 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.
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 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.
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.