Roadmap 🗺️

This document outlines some goals, non-goals, and future aspirations for kind as a project.

To reach “beta” kind needs to at minimum:

Improve documentation (Though this will eternally be “In Progress” !)
- create a documentation site - #268
- expand examples of using kind (We can always use more, but we have more of this now)
- cover known issues, debugging, work-arounds, etc.
Reliably the Kubernetes conformance tests
Conformance
Support multi-node clusters - #117
Support offline / air-gapped clusters
- pre-loaded / offline CNI -
Support mounting host directories - #62
Support usage as a properly versioned, supported, and documented library. This includes following semver without every release being a major / breaking change to the API (which must be extensible without breakage), ensuring the CLI only uses a suitable public library surface, documentation and examples for the library, versioned types for public APIs (E.G. config format), etc.
- TODO: what exactly do we want here? Should this really be beta blocking?
should be possible to troubleshoot kind without needing to modify kind ~or use external debugging tools~ (this should be possible now, if not perfect!)
- consistent logging (what is logged, when should it be logged, what levels are used) (this is consistent-ish now, if not perfect)
- errors have appropriate context (this is debatable and never perfect, but improved a lot, especially if you use or greater) for managing clusters in test harnesses
move API types / labels from into
Support all currently upstream-supported Kubernetes versions
come up with a plan for stable node image <-> KIND compatiblity

Support non-AMD64 architectures (namely ARM) -
- TODO: move this to post GA? This is expensive and has relatively low demand so far.
Automated publishing of Kubernetes release based kind “node” images - #197
Support for runtimes other than docker/default including podman, ignite etc.
First class support for skewed node (Kubernetes) versions (I believe this is relatively first-class now, things should work fine if you specify different node images)
… TBD, more will be added here …

Supporting every possible Kubernetes configuration
- In order to best support offline / hermetic clusters, we will likely not offer many options for CNI etc. out of the box. We may revisit this later.
Being “production workload ready” - kind is meant to be used:
- for testing Kubernetes itself
- for testing against Kubernetes (EG in CI on Travis, Circle, etc.)
- for “local” clusters on developer machines
- NOT to host workloads serving user traffic etc.
Replacing 🦒 – kind isn’t trying to replace all the things and Phippy is awesome ❤️

Longer Term goals include:

Enabling a suitable local storage provider for testing applications that need persistent storage

1.0 Roadmap