Kubetools: a curated index of Kubernetes tooling, and what it is not

The problem Kubetools addresses is discovery, not installation

The README opens with a specific claim about scale: there are more than 500+ Kubernetes Certified Service Providers and many certified distributions, and the project argues that choosing a distribution can be a daunting task. Kubetools exists to answer a narrower question than a distribution comparison does. It is a curated list of popular Kubernetes tools, organised by what the tool does rather than by vendor, and it is aimed at engineers who already run a cluster and need to find out what exists in a given category. The audience is implied by the categories themselves: alerting and monitoring, logging and tracing, troubleshooting and debugging, security, network policies, service mesh, observability, storage providers, backup, cost optimisation, caching and cleanup. Those are operational concerns, so the list assumes you have a cluster and a problem, not that you are choosing a cloud provider. The README also states the list is maintained by the Collabnix Slack community, and it points readers to a Slack invite and a Twitter account for updates. That community framing matters: the entries are contributed and reviewed by people in a Slack workspace, so the list reflects what that group finds useful, which is a different selection bias from a vendor-published catalogue.

How the list is structured and how the site is generated

The primary artefact is README.md. It begins with a table of contents that names each category, then each category is a Markdown table with four columns: a serial number, the tool name, a description with a link, and a GitHub popularity badge. The badge is a shields.io image pointing at the tool's own repository, so the popularity figure is rendered at view time rather than stored. The repository layout shows a second delivery path: a portal/ directory, a _layouts/ directory, a _config.yml, a Gemfile and a Gemfile.lock. That combination is the signature of a Jekyll site, and the homepage is https://kubetools.collabnix.com, so the README and the site are two renderings of the same editorial content. There is also a scripts/ directory, a fix.sh at the top level, a .codespellrc, and an image of a periodic table of Kubernetes tools. The periodic table image is a good illustration of the project's editorial stance: it groups tools spatially by domain, which is a presentation choice, not a technical taxonomy. Nothing in the repository layout suggests a database, an API or a package registry. The data flow is one-directional: contributors edit Markdown, the site build renders it, and readers follow links outward.

Reading the list and building the portal locally

There is no package to install and no binary to run. The README does not document an installation procedure for the list itself, because the list is consumed by reading it. What the repository does give you is the Jekyll site configuration, if you want to preview edits or run the portal yourself: the repository root holds _config.yml, Gemfile and Gemfile.lock, and the site content sits in the portal/ directory. Those are the files a Jekyll build reads, and the standard Ruby dependency install and local serve commands are what that toolchain uses, but the README does not spell them out, so treat the exact invocation as something to confirm against Jekyll's own documentation rather than something this repository states. For most readers the practical path is simpler. Open README.md and search for a category you already care about, for example backup or cost optimisation, and read the description column rather than the popularity column. The description column is the part a contributor wrote; the badge is a number that changes without anyone editing the list. For a first real decision, pick one category, list the tools named there, and open each linked repository separately, because that is where the actual documentation lives. The README's featured section, dated June 2026, names a smaller rotating set of tools including KubeArchInspect, Kuberay, K8s-insider, Agentkube, Stern, Node Problem Detector, Karpenter, Kubestalk, K8sGPT, Kubeshark, K9s and KubeGraf, with links that mix GitHub repositories and kubetools.io articles.

Where the curated-list format breaks down

A list is only as good as its maintenance, and the failure modes here are structural rather than accidental. The last push to the repository was on 2026-09-11, so the project is not dormant, but a push does not tell you which rows were updated; a single commit can add one tool while twenty other rows keep describing a project that has since been renamed or abandoned. The popularity column is a live badge, which means the list can look current while its prose is stale. That is the central limitation: the README mixes two kinds of information with very different freshness, editorial descriptions that change only when someone edits them, and badges that update themselves. A second limitation is selection. The categories are broad, but the number of entries per category varies, and the README excerpt shows some categories populated with only a handful of rows, for example the Pods table with three entries. A short table is not evidence that few tools exist; it is evidence that few were contributed. Third, the list cannot tell you whether two tools are compatible, which versions they support, or whether a tool is still maintained. It links out and stops there. If you need a compatibility matrix or a support statement, this is the wrong artefact, and no amount of reading it will produce one.

Kubetools compared with a package manager or an operator hub

The closest alternatives are not other curated lists but distribution mechanisms. A Helm chart repository or an operator hub gives you an installable artefact with a version, a values schema and an upgrade path. Kubetools gives you a name and a link. The difference in approach is the difference between a catalogue and a registry: a registry can resolve dependencies and fail loudly when a version is missing, while a catalogue can only point. That is not a defect in Kubetools, because it is solving the earlier problem of not knowing a category exists. But it does mean the two are used at different moments. You read Kubetools before you know what to search for in a chart repository, and you stop reading it once you have a candidate, because the candidate's own documentation is the only place that can tell you how to install it. The same applies to the periodic table image and the featured list: they are entry points, and the linked repositories are the substance.

Licence, contribution and the cost of keeping a list current

The repository is licensed Apache-2.0. That licence covers the repository contents, meaning the README text, the site templates and the build configuration. It does not extend to the tools the list names; each of those has its own licence, and the README does not summarise them. If you fork the list to maintain an internal version, Apache-2.0 permits that, and you inherit the maintenance obligation that comes with a fork: someone has to re-check the descriptions. The upgrade cost of the list itself is low, because there is no runtime. The upgrade cost of what the list points at is entirely separate and is not something the project can absorb. The repository includes a .codespellrc and a fix.sh, which suggests the maintainers run at least a spelling check over contributions, and the topics include hacktoberfest and hacktoberfest2020, so some contributions arrive through that event. Contribution volume driven by an event is a real pattern and it has a known effect: entries get added faster than they get reviewed for staleness. That is worth knowing before you treat any row as vetted.

Editorial conclusion

Adopt Kubetools as a starting point when you need to know what exists in a category such as backup, cost optimisation or service mesh, and treat each row as a pointer to a separate project you still have to evaluate. Do not adopt it as a dependency, a package source or a compatibility guarantee: the repository is a list, the licence covers the list, and the tools it names carry their own licences and release cycles. Before relying on it, open the portal/ directory to see how the site is generated, check whether the category you care about has more than a handful of entries, and follow the linked repository for any tool you intend to run in production.

Frequently asked questions

Official sources

1. collabnix/kubetools on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README