Principles

While developing kind the following principles should be considered.

Degrade Gracefully

As much as possible kind should not fail, because it is to be used for testing.Partially degraded states can still be useful and still be debugged.

As a concrete example: We “pre-load” images that the cluster depends on bypacking them into the “node image". If these images fail toload or are not present in the node image kind will fall back to letting the“node"s container runtime attempt to pull them.

Similarly we must at least support all officially supported Kubernetes releases,which may mean gracefully degrading functionality for older releases.

Target CRI Functionality

Currently kind only supports docker and uses it directly to create “node” containers.

In order to aid supporting multiple container runtimes going forward andavoid unnecessary coupling, we should target functionality covered by theKubernetes CRI (Container Runtime Interface).

Leverage Existing Tooling

Where possible we should not reinvent the wheel.

Examples include:

• kubeadm is used to handle node configuration, certificates, etc.
• kustomize is used to handle merging user provided config patches with ourgenerated kubeadm configs
• k8s.io/apimachinery is used to build our own configuration functionality
• In general we re-use k8s.io utility libraries and generators

Re-implementing some amount of functionality is expected, particularlybetween languages and for internal / insufficiently-generic components, but in generalwe should collaborate where possible.

Avoid Breaking Users

Going forward kind will avoid breaking changes to the command line interfaceand configuration.

Next we will extend this to a documented set of re-usablepackages (To be determined, but likely IE pkg/cluster).

While we are alpha grade currently, we will move to beta and respectthe Kubernetes Deprecation Policy.

Externally facing features should consider long-term supportability andextensibility.

Follow Kubernetes API Conventions

As a general rule of thumb kind prefers to implement configuration usingKubernetes style configuration files.

While doing this we should respect the Kubernetes API Conventions.

Additionally we should minimize the number of flags used and avoid structuredvalues in flags as these cannot be versioned.

Minimize Assumptions

Avoid making any unnecessary assumptions. Currently we assume:

• Docker is installed on the host and the current user has permission to talk to dockerd
  • In the future we may instead only assume that a CRI is available. See above.
• “node” images follow our format
  • However whenever we make changes we do not assume the updated contents definitely exist
  • Metadata in the images is assumed to be correct
• When building Kubernetes, we make the same assumptions & requirements as upstream

Be Hermetic

As an extension of minimizing assumptions, kind should be as hermetic as possible.In other words:

• Strive for reproducibility of operations
• Avoid depending on external services, vendor / pre-pull dependencies

No External State

State is offloaded into the “node” containers in the form of labels, files inthe container filesystem, and processes in the container. The cluster itselfstores all state. No external state stores are used and the only statefulprocess is the container runtime. kind does not itself store or manage state.

This simplifies a lot of problems and eases portability, while forcing clusterinteractions to be consistent.

Consider Automation

While kind strives to present a pleasant UX to users on their local machines,automation for end to end testing is the original & primary use case.Automated usage should be considered for all features.