初始设计

本文档介绍了 kind 的一些初始设计。

注意：其中一些内容相对于当前实现已经过时。这主要用于历史目的，原始提案 包含更多详细信息。

展望未来，设计原则 可能更相关。

概述 🔗︎

kind 或 kubernetes in docker 是一套用于本地 Kubernetes “集群” 的工具，其中每个“节点”都是一个 Docker 容器。kind 针对 Kubernetes 测试。

kind 分为实现大多数功能的 go 包、供用户使用的命令行和“节点”基础镜像。目的是，kind 包套件最终应该可以被其他工具（例如 kubetest）导入和重用，而 CLI 提供了一种快速使用和调试这些包的方法。

有关 原始提案，请参阅 kubernetes-sig-testing 帖子（注意：本文档与 kubernetes-sig-testing 共享）。

简而言之，kind 针对用于测试目的的本地集群。虽然并非所有测试都可以在没有“真实”集群的情况下进行，但我们希望能够在“云”中使用提供商启用的 CCM，但我们可以进行足够的测试，因此我们需要一些东西

• 运行非常便宜的集群，任何开发人员都可以本地复制
• 与我们的工具集成
• 有充分的文档记录和可维护性
• 非常稳定，并具有广泛的错误处理和健全性检查
• 通过所有一致性测试

在实践中，kind 看起来像这样：

集群 🔗︎

集群由 pkg/cluster 中的逻辑管理，kind cli 封装了该逻辑。

每个“集群”都由一个内部但众所周知的 docker 对象标签 键标识，每个“节点”容器的值为集群名称/ID。

我们最初将这种类型的状态卸载到容器和 Docker 中。类似地，容器名称由 kind 自动管理，尽管我们将选择标签而不是名称，因为标签更不容易出错，并且被正确地命名空间化。这样做还可以避免我们管理主机文件系统上的任何内容，但不会降低使用率。

KUBECONFIG 将被绑定安装到一个临时目录，工具能够从容器中检测到这一点，并提供帮助程序来使用它。

镜像 🔗︎

要在容器中运行 Kubernetes，我们首先需要合适的容器镜像。使用单个标准 基础层，其中包含基本实用程序，如 systemd、证书、挂载等。

在该镜像之上安装 Kubernetes 等，并可能在预构建的镜像中缓存。我们预计将提供已安装版本的镜像，用于与 Kubernetes 集成。

有关更多信息，请参阅 node-image.md。

集群生命周期 🔗︎

集群创建 🔗︎

每个“节点”都作为 Docker 容器运行。每个容器最初启动到一个伪“暂停”状态，入口点 等待 SIGUSR1。这使我们能够在启动 systemd 和所有组件之前使用 docker exec ... 和其他工具来操作和检查容器。

此设置包括修复挂载和预加载保存的 Docker 镜像。

一旦节点准备就绪，我们就向入口点发出信号，使其真正“启动”节点。

然后，我们等待 Docker 服务在节点上准备就绪，然后再运行 kubeadm 来初始化节点。

一旦 kubeadm 启动，我们就导出 KUBECONFIG，然后应用一个 覆盖网络。

此时，用户可以使用导出的 kubeconfig 测试 Kubernetes。

集群删除 🔗︎

集群中的所有“节点”容器都使用 Docker 标签进行标记，这些标签通过选择的集群名称（默认值为“kind”）标识集群，要删除集群，我们只需列出并删除具有此标签的容器即可。