replace dated intial design docs with a clear warning to not depend on implementation details

these were meant for education about how kind is accomplished, but they've mostly been referernced by users attempting to extend and otherwise depend on internals
This commit is contained in:
Benjamin Elder
2025-02-05 08:41:53 -08:00
parent b9be5e5d19
commit ee299771b2
2 changed files with 21 additions and 56 deletions

View File

@@ -6,31 +6,19 @@ menu:
identifier: "base-image"
---
> **NOTE**: This may not completely cover the current implementation.
This page used to host a doc about the initial design, this has been found confusing
so we've updated it to clarify the current expectations. While the sources of the project
are fully open, depending on the specifics of the node image internals is not supported.
The ["base" image][base image] is a small-ish Docker image for running
nested containers, systemd, and kubernetes components.
We only support that base images will create a working node image with `kind build node-image` at the kind release they were shipped with.
To do this we need to set up an environment that will meet the CRI
(currently containerd and runc) and systemd's particular needs. Documentation for each
step we take is inline to the image's [Dockerfile][dockerfile],
but essentially:
The contents and implemlentation of the images are subject to change at any time
to fix bugs, improve reliability, performance, or maintainability.
- we preinstall tools / packages expected by systemd / containerd / Kubernetes other
than Kubernetes itself
DO NOT DEPEND ON THE INTERNALS OF THE BASE IMAGES.
- we install a custom entrypoint that allows us to perform some actions before
the container truly boots
KIND provides [conformant][conformance] Kubernetes, anything else is an implementation detail.
- we set up a systemd service to forward journal logs to the container tty
We will not accept bugs about "breaking changes" to base images and you depend on the implementation details at your own peril.
- we do a few tricks to minimize unnecessary services and inform systemd that it
is in docker (see the [Dockerfile][dockerfile])
This image is based on the `debian-slim` image which starts relatively small for
a Kubernetes node image, has near exclusively packages we need, and has
relatively up to date packages.
We strive to minimize the image size where possible.
[base image]: https://sigs.k8s.io/kind/images/base
[dockerfile]: https://sigs.k8s.io/kind/images/base/Dockerfile
[conformance]: https://www.cncf.io/training/certification/software-conformance/

View File

@@ -6,43 +6,20 @@ menu:
identifier: "node-image"
---
> **NOTE**: This may not completely cover the current implementation.
This page used to host a doc about the initial design, this has been found confusing
so we've updated it to clarify the current expectations. While the sources of the project
are fully open, depending on the specifics of the node image internals is not supported.
The ["node" image][node image] is a Docker image for running
nested containers, systemd, and Kubernetes components.
We only support that node images will create a working Kubernetes node at the advertised version with the kind version they
were released with (and best effort with other releases), see the release notes.
This image is built on top of the ["base" image][base image].
The contents and implemlentation of the images are subject to change at any time
to fix bugs, improve reliability, performance, or maintainability.
Logic for building the ["node" image][node image] can be found in [`pkg/build`][build package],
and it can be built with `kind build node-image` respectively.
DO NOT DEPEND ON THE INTERNALS OF THE NODE IMAGES.
## Design
KIND provides [conformant][conformance] Kubernetes, anything else is an implementation detail.
Other than the requirements that this image inherits from the "base" image, which
provides most of the tools statically needed for a Kubernetes deployment
(eg `systemd`), variants of this image have the following properties:
We will not accept bugs about "breaking changes" to node images and you depend on the implementation details at your own peril.
- `/kind/images/` contains various `*.tar` files which are
[Docker image archives][docker image archives],
these images will be loaded by the cluster tooling prior to running `kubeadm`
- `kubeadm`, `kubectl`, `kubelet` are in the path
- A [systemd service][systemd service] is enabled for `kubelet`, and is
configured to not fail on swap being enabled. (we must do the latter because
swap is inherited from the host and we don't want to force users to disable swap
before using `kind`)
- `/kind/version` is a regular text file containing the `gitVersion` of the
installed Kubernetes build
These properties are used by the [cluster][cluster package] tooling to boot
each "node" container with [kubeadm][kubeadm].
[node image]: https://sigs.k8s.io/kind/images/node
[base image]: /docs/design/base-image
[build package]: https://sigs.k8s.io/kind/pkg/build
[cluster package]: https://sigs.k8s.io/kind/pkg/cluster
[docker image archives]: https://docs.docker.com/engine/reference/commandline/save/
[systemd service]: https://www.freedesktop.org/software/systemd/man/systemd.service.html
[kubeadm]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
[conformance]: https://www.cncf.io/training/certification/software-conformance/