kind (Kubernetes in Docker)

This image packages the Rancher local-path-provisioner (https://github.com/rancher/local-path-provisioner) specifically for use with kind.

Key characteristics of this package include:

• It is not based on Alpine Linux (to avoid specific compatibility issues).
• It provides control over the build process using a currently patched Go version.

kind (kubernetes in docker) is a suite of tooling designed for running local Kubernetes clusters where each "node" is a Docker container. It is primarily targeted at testing Kubernetes.

The project consists of:

• Go packages (implementing core functionality, intended to be reusable by other tools like kubetest).
• A command-line interface (CLI) for users to manage clusters.
• A "node" base image containing necessary utilities (systemd, certificates, mount, etc.).

kindnetd is a simple networking daemon used to implement KIND's standard CNI (Container Network Interface) and cluster networking configuration. Its primary responsibilities include:

• IP masquerade: Handling traffic leaving the nodes that is headed out of the cluster.
• Route management: Ensuring netlink routes to pod CIDRs are directed via the host node IP for each node.
• CNI Configuration: Ensuring a simple CNI configuration based on the standard ptp and host-local plugins and the node's pod CIDR.

The kind node image is a specialized container image used as the foundation for Kubernetes nodes in a kind cluster. It is built programmatically using docker run, exec, and commit to efficiently handle large artifacts.

Conceptually, the node image is based on the base image and includes the following additions:

• Installation of Kubernetes packages and binaries.
• Kubernetes docker images stored in /kind/images/*.tar.
• A /kind/version file containing the Kubernetes semantic version (semver).

kind manages clusters by using Docker containers as nodes.

Key management concepts:

• Identification: Each cluster is identified by a specific Docker object label. The cluster name/ID is stored as the value of this label on every node container. This allows kind to select nodes via labels rather than brittle container names.
• State Management: Cluster state is offloaded into the containers and Docker itself, avoiding the need to manage state on the host filesystem.
• KUBECONFIG: The KUBECONFIG is bind-mounted to a temporary directory. The kind tooling can detect this mount to provide helpers for accessing the cluster.

When creating custom base images for kind, you must ensure that the image can produce a working node image using the kind build node-image command at the specific kind release version it was shipped with.

Warning: Do not depend on the internal implementation details or specific contents of the base images. kind provides conformant Kubernetes; any other behavior or structure within the image is considered an implementation detail and is subject to change without notice to improve reliability, performance, or maintainability. The project will not accept bug reports regarding breaking changes to base image internals.

kind prefers to use Kubernetes-style configuration files for its settings. When creating configurations or extending kind, follow these guidelines:

• Respect Kubernetes API Conventions: Use standard Kubernetes patterns for configuration structures.
• Minimize CLI Flags: Avoid using a large number of flags. Specifically, avoid using structured values in flags, as these cannot be easily versioned.
• Stability: kind aims to follow the [Kubernetes Deprecation Policy] as it moves from alpha to beta, ensuring that CLI and configuration changes are stable and documented.

In kind, the node image is a black box used to create a working Kubernetes node. While the source code is open, the internal implementation and contents of these images are subject to change without notice to improve reliability, performance, or maintainability.

The Supported Contract: kind only guarantees that a node image will:

1. Create a working Kubernetes node at the advertised version.
2. Be compatible with the kind version it was released with (and best effort with other releases).

Warning: Do not depend on the specific internals, file paths, or implementation details of the node images. kind provides CNCF-conformant Kubernetes; anything inside the image that is not part of the Kubernetes conformance specification is considered an implementation detail and is not supported.