1.0 Roadmap 🗺

New year, new roadmap 🎉

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

Contents 🔗︎

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 1 or greater) for managing clusters in test harnesses
• move API types / labels from *.k8s.io into *.x-k8s.io
• 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 …

Non-Goals 🔗︎

• 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

Misc 🔗︎

• setup a regular Zoom meeting for the project #244
• achieve certified Kubernetes conformance #245

Other goals / tasks not listed here can be found both in the 1.0 project and more generally triaged for rough-priority in the GitHub issues.