Roadmap 🗺️

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

    To reach “beta” grade kind needs to at minimum:

    • Improve documentation (Though this will eternally be “In Progress” !)
      • create a documentation site -
      • 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
    • Certify Conformance
    • Support multi-node clusters -
    • Support offline / air-gapped clusters
      • pre-loaded / offline CNI - #200
    • Support mounting host directories -
    • 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!)
      • x ] 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 debateable 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 [](https://github.com/kubernetes/community/blob/master/sig-architecture/api-review-process.md#voluntary)
    • Support all currently
    • Support non-AMD64 architectures (namely ARM) - #166
      • 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 -
    • Support for runtimes other than docker/default including podman, ignite etc.
      • TODO: moves this to post GA? We can probably do this without breaking anyone and the demand is low-ish.
    • First class support for skewed node (Kubernetes) versions (I beleive 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 notoffer 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 thingsand Phippy is awesome ❤️

    Longer Term goals include:

    • Enabling a suitable local storage provider for testing applications that needpersistent storage
    • setup a regular Zoom meeting for the project
    • achieve certified Kubernetes conformance #245