原则

在开发 kind 时，应考虑以下原则。

内容 🔗︎

尽可能地，kind 应该不会失败，因为它将用于测试。部分降级状态仍然有用，并且仍然可以调试。

作为一个具体的例子：我们通过将它们打包到“节点镜像”中来“预加载”集群依赖的镜像。如果这些镜像无法加载或节点镜像中不存在，kind 将回退到让“节点”的容器运行时尝试拉取它们。

同样，我们至少必须支持所有官方支持的 Kubernetes 版本，这可能意味着对旧版本优雅地降级功能。

目前，kind 仅支持 containerd，并对 podman 提供实验性支持。它直接使用这些容器运行时来创建“节点”容器。

随着支持多个容器运行时的长期目标，并避免不必要的耦合，我们尝试将功能定位到 Kubernetes CRI（容器运行时接口）所涵盖的功能。

在可能的情况下，我们应该不要重新发明轮子。

示例包括

重新实现一定程度的功能是预期的，特别是在语言之间以及对于内部/不够通用的组件，但总的来说，我们应该在可能的情况下进行协作。

展望未来，kind 将避免对命令行界面和配置进行破坏性更改。

接下来，我们将将其扩展到一组记录在案的可重用包（待定，但可能是 IE pkg/cluster）。

虽然我们目前处于 alpha 级别，但我们将转向 beta 并尊重 Kubernetes 弃用策略。

面向外部的功能应考虑长期可支持性和可扩展性。

作为一般经验法则，kind 倾向于使用 Kubernetes 风格的配置文件来实现配置。

在执行此操作时，我们应该尊重 Kubernetes API 约定。

此外，我们应该尽量减少使用的标志数量，并避免在标志中使用结构化值，因为这些值无法进行版本控制。

避免做出任何不必要的假设。目前，我们假设

docker 安装在主机上，并且当前用户有权与 dockerd 通信。
- 除非使用对 podman 或 nerdctl 的实验性支持。
- 将来，我们可能只假设 CRI 可用。参见上面。
“节点”镜像遵循我们的格式。
- 但是，无论何时进行更改，我们都不会假设更新的内容一定存在。
- 假设镜像中的元数据是正确的。
在构建 Kubernetes 时，我们对上游做出相同的假设和要求。

作为最小化假设的扩展，kind 应该尽可能地保持封闭性。换句话说

状态以标签、容器文件系统中的文件以及容器中的进程的形式卸载到“节点”容器中。集群本身存储所有状态。不使用外部状态存储，唯一有状态的进程是容器运行时。kind 本身不存储或管理状态。

这简化了许多问题，并简化了可移植性，同时强制集群交互保持一致。

虽然 kind 努力为用户在其本地机器上提供愉快的 UX，但端到端测试的自动化是最初的和主要用例。应考虑对所有功能进行自动化使用。