How to get the busywork out of handling Kubernetes and finding out what is going on in your cluster? If you feel like you have written quite enough kubectl commands for a while, this is for you!
In this post, we will go through a selection of Kubernetes tooling – the tools we use at Stackable to develop our Kubernetes-based data platform. These tools can make it easier to interact with your k8s clusters. They can also help understand what’s going on at a faster pace.
NOTE: we will focus on tools that interact with your Kubernetes cluster, but don’t need to be “installed” on the actual cluster. Just because this happens to be what we as a team seem to gravitate towards.
An Overview
The variety of the Kubernetes ecosystem is huge. As Stackable is an open source focused company, our selection leans towards open source, freely usable tools as well.
Here is an overview of the tools we will visit in this article (the order is based on the author’s personal usage frequency):
- k9s – a surprisingly intuitive and powerful terminal UI.
- octant – an application which provides a web interface to your cluster.
- tilt – ever wanted a convenient way to deploy code to a k8s cluster? Tilt got you.
- kuttl – THE tool to run e2e tests on a k8s cluster.
- stackablectl – our own CLI, which provides higher levels of abstraction for our products, wraps helm under the hood.
- helm – used under the hood
- kubectl – we couldn’t do without it.
Each has their own strong points, and if you ask me, at least one distinct use case where each shines. Personally, I wouldn’t want to miss any of them!
K9s
I never thought a terminal-based interface could be this smooth, convenient and useful.
“a terminal UI to interact with your Kubernetes clusters”
“The aim of this project is to make it easier to navigate, observe and manage your applications in the wild.”
“Kubernetes CLI To Manage Your Clusters In Style!”
You don’t type single commands, but navigate around different views using a mix of vim-like commands and emacs-like shortcuts. Don’t worry, arrow keys do what you’d expect them to do and the shortcut overview is always visible. Think htop for your k8s cluster.
You can see a preview video on the k9s website and installation instructions over at their GitHub repo. I wouldn’t want to miss this tool in my tool belt for any work that touches a k8s cluster. Big recommendation.
Octant
Although k9s is great, I find myself reaching for octant for specific types of resources instead.
“Open source developer-centric web interface for Kubernetes that lets you inspect a Kubernetes cluster and its applications.”
It is a local app, which provides a web interface to browse around your k8s cluster resources.
I find it really convenient to view config maps and inspecting workload stats. It feels like a good additions to scenarios when I would not get as much overview navigating around within the k9s interface. You can learn more about octant on their website.
Tilt
“Tilt automates all the steps from a code change to a new process: watching files, building container images, and bringing your environment up-to-date. Think docker build && kubectl apply or docker-compose up.”
While the last two tools were focused on finding out what’s going on in a Kubernetes cluster, tilt is for taking away some busy work during from your k8s dev processes.
If you have manual steps that you take between making changes to your code, and getting it to run in a k8s development environment, tilt is the tool for you.
You can read more on their main page, in their docs or on GitHub.
NOTE: If you’re interested, you can read how we use Tilt at Stackable in a section of our contributor guide.
Kuttl
“The KUbernetes Test TooL (kuttl)”
Way cooler than manual testing could ever be! You can create black box integration tests for your Kubernetes workloads and environments with this tool. Specify steps to take (aka manifests to apply to your cluster), and check if the desired states are reached after each step.
We rely on kuttl extensively for all our integration tests. If we didn’t have it, it would need to be created. Our operators would be really hard to test without it.
NOTE: We also have a custom templating tool to generate test files for different parameters, but that’s a topic for another time.
If you want to start running tests remote cluster without your attention. You can learn more about it on the project’s website.
NOTE: If you want to see how we use Kuttl, take a look at the smoke test for our Kafka operator.
Stackablectl
Our own CLI tool, which abstracts away some k8s busywork to make dealing with our data platform as easy as possible.
“A command line tool is used to interact with the Stackable data platform. It can install individual operators as well as platform releases. It also ships with a set of pre-built Demo that utilize different data products of the Platform to get e.g. an end-to-end data pipeline.”
If you want to spin up your data tools on a fresh cluster using Stackable, you don’t really care about the details happening in the background. You just want a Kafka cluster and a Nifi to start (or many more tools, if needed).
Stackablectl helps to focus on what matters. If you’re curious, check out the docs or dive straight into the Rust codebase over here. It uses helm under the hood!
Helm
Helm helps install packaged and templated applications to your Kubernetes cluster.
“the package manager for Kubernetes”
You probably are already using it (it’s hard to get around it, really). If you are not, you really should check it out, either on the project site or on GitHub.
We use it both to power our stackablectl CLI tool, and also for installing third party dependencies for various dev and demo scenarios.
Kubectl (IMPROVED)
This is not a distinct tool! I just wanted to add a section to mention that you can greatly enhance your experience with good ol’ kubectl. (yes, even if you are tired of it). There are a tweaks and additions you can make, to make it pretty convenient and powerful.
Setting shell aliases (like alias k) or installing other CLI tools to smooth over some rough usability edges (especially around namespaces and multiple clusters) for example. However, this is a topic which deserves its own article. Stay tuned!
Conclusion and Honorable Mentions
I hope you could find one or two new tools to check out and maybe add to your personal Kubernetes tool box!
The ecosystem is ever-growing and ever-changing. Although the tools above are great, there is always one more use case or specific problem which is not sufficiently easy to address. If you are like me, you never stop looking.
I want to do this fact justice, and list some tools which are not currently in use at Stackable, but have made it on my personal radar.
- ktop – like htop for your k8s cluster.
- k8slens – this looks cool, and I have heard good things about it but, as far as I understood, it is a paid product for commercial use.
- groundcover – yummy eBPF tooling. Observability turned up to 11. I would like to try sometime, when there is a use case for it. From what I understood, they use advanced eBPF sorcery for an astounding amount of observability gained.
- kind – a cornerstone of our dev processes. Not exactly for interacting with clusters, but for creating local disposable dev clusters instead.
- t2 – our own internal infra tool, which plays nicely with our on-demand and nightly tests. It provisions k8s clusters for us on several providers as needed. It’s kind of like
kind, but works across managed k8s cloud providers. Hat-tip to Nikolaus who built and extended it!t2powers most of Stackable’s internal testing infrastructure needs and simply works. - It’s necessary and important to mention kubedoom in this context.