Features

Curated Tool Containers

k8s-tools.yml is a docker compose file with 20+ container specifications covering popular platforming tools and other utilities for working with Kubernetes.

The collection is structured in the following ways:

Executable file, i.e. ./k8s-tools.yml ... is equivalent to docker compose -f k8s-tools.yml ....
Tool containers are easy to change / extend, in place. Using the dockerfile_inline directive, plus the fact that tool-containers tend to involve layering really small customizations. Customize them if you need to, and you can still avoid having N Dockerfiles cluttering up your whole repository.
Default versions for container-bases are provided, but you can set an environment variable to override them individually.
Sane defaults for volumes & environments are included for each tool-container, meaning that sharing the working directory, docker socket, and kubeconfigs is done automatically. For host vs. container file permissions, k8s-tools.yml also attempts to provide smoother operations with root-user containers (more details here.
All tool containers are just-in-time & on-demand, so that having these declared in case of eventual use won't saddle you with an enormous bootstrap process. As usual with docker-compose, containers aren't pulled until they are used, and build-when-changed mostly works as you'd expect.

The overall focus for k8s-tools.yml is to stand alone with no host dependencies (not even Dockerfiles), yet provide boilerplate that's parametric enough to work pretty well across different projects without changing the compose file. Read on in the next section for more details about the manifest.

Toolbox Manifest

Here's a quick overview of the manifest and some details about versioning:

Local parts of the tool bundle: (See the latest here)

Cluster management: kind, k3d
Workflows, FaaS, and Misc Platforming Tools: argocli, kn, fission, rancher
Lower-level helpers: helmify, kompose, kubefwd
Monitoring and metrics tools: promtool, k9s, lazydocker
Krew plugins: sick-pods, ktop, kubectx, and kubens available by default, and more on demand.
TUI and user-messaging utilities: gum, pv, spark, tte
General Utilities: Fixed (i.e. non-busybox) versions of things like date, ps, uuidgen, etc

Upstream parts of the tool bundle (See the latest here)

Cluster management: eksctl
Core Utilities: kubectl, kustomize, helm, krew
Misc Utilities: helm-diff, helm-unittest, helm-push, kubeseal, vals, kubeconform
Cloud Utilities: awscli v1, aws-iam-authenticator
General Utilities: Such as bash, curl, jq, yq, etc
Upstream tool versioning is determined by the alpine-k8s base,
But k8s-tools.yml has service-stubs for quick overrides if you need something specific.

Automation with k8s.mk

After you've made your whole kit portable in one swipe with the compose file, you might want to focus on driving those tools with something that offers more structure than a shell script, and something that also won't add to your host dependencies. If that sounds interesting, you might like to meet compose.mk and k8s.mk:

compose.mk: A domain-agnostic tool / library for makefile-based automation, scripting, and lightweight orchestration. Native support for docker, docker-compose, workflow primitives, TUI elements, and more.
k8s.mk: A kubernetes-specific extension of compose.mk, inheriting all of the above features plus easy access to the k8s-tools.yml manifest, providing powerful ways to run automation inside tool-containers and script orchestration across those tool containers.

So whereas compose.mk is useful in general, k8s.mk is more focused on projects working with kubernetes. A description of the full capabilities for compose.mk is out of scope for this documentation and not strictly required, but it's worth reading!.

For our purposes here, the most relevant feature of compose.mk is that it can generate automation scaffolding for each of the tool-containers that are defined in a compose-file. Automation scaffolding is in the form of make targets, targets are simultaneously entrypoints and as reusable task units, the "internal API" is automatically published as a CLI interface. And since composing task-units into DAGs is so simple, building up surprisingly sophisticated automation is very easy.

Because "importing" the k8s-tools.yml containers like this gives us simple handles to interact with them, using k8s.mk tends to be the most convenient way to invoke them. Using that as a base, we can also start to build an automation "vocabulary" on top and make it available for other scripting.

Primitives provided by k8s.mk include things like:

So besides helping to only make calls to versioned tools, k8s.mk can make it simpler to interact with them or make it simpler to script actions that involve multiple tools. And since k8s.mk also inherits and extends the TUI support from compose.mk, one can quickly throw together custom dashboards that actually treat other programs like k9s as widgets.

With that background out of the way.. a summary of the main features for k8s.mk looks something like this:

Useful as a library, especially if you're building cluster lifecycle automation
Useful as an interactive debugging/inspection/development tool.
Helps to do the common tasks quickly, either interactively or from other automation
- Launch a pod in a namespace, or a shell in a pod, without lots of kubectl'ing
- Stream and pipe commands to/from pods, or between pods
Assemble custom interactive dashboards with new or existing TUI elements
Curated collection of automation interfaces, arranged into a few namespaces:
- k8s.* targets: Default namespace with debugging tools, cluster life-cycle primitives, etc.
- ansible.* targets: A direct interface to containerized versions of things like kubernetes.core.k8s or kubernetes.core.helm, no playbooks and no inventories required.
- Many more specific interfaces to things like k3d, kubefwd, etc. See the full API here.