Toolbox & Manifest

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

Toolbox Manifest

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

Local parts of the tool bundle: (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: (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.

Curated Tool Containers

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 or extend, in place. We use the dockerfile_inline directive to avoid extra clutter. 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 to avoid the common problem of messing up file permissions on the host.
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.