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 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.
  • Enable audit-logging
    • TODO: should this be post-GA? this could probably be an extension
  • 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.