1.0 Roadmap 🗺
New year, new roadmap 🎉
This document outlines some goals, non-goals, and future aspirations for kind as a project.
Beta Requirements 🔗︎
To reach “beta” grade 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 pass the Kubernetes conformance tests
- Certify Conformance
- Support multi-node clusters - #117
- Support offline / air-gapped clusters
- pre-loaded / offline CNI - #200
- Support mounting host directories - #62
- Improve Windows support
- add Windows binaries to releases - #155
- improve instructions for KUBECONFIG in particular
- 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
-v 1or greater) for managing clusters in test harnesses
- move API types / labels from
- Support all currently upstream-supported Kubernetes versions
- come up with a plan for stable node image <-> KIND compatibility
GA Requirements 🔗︎
To reach “GA” grade kind needs to at minimum:
- Support non-AMD64 architectures (namely ARM) - #166
- 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 Phippy 🦒 – 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