1.0 路线图 🗺
新年新路线图 🎉
本文档概述了 kind 作为项目的一些目标、非目标和未来愿景。
目录 🔗︎
Beta 要求 🔗︎
要达到“beta” 级别，kind 至少需要
- 改进文档（尽管这将永远是“进行中”！)
- 创建一个文档网站 - #268
- 扩展使用 kind 的示例（我们总是可以使用更多，但我们现在有更多这样的示例）
- 涵盖已知问题、调试、解决方法等。
- 可靠地 通过 Kubernetes 一致性测试
- 认证 一致性
- 支持多节点集群 - #117
- 支持离线/隔离集群
- 预加载/离线 CNI - #200
- 支持挂载主机目录 - #62
- 改进 Windows 支持
- 将 Windows 二进制文件添加到发行版中 - #155
- 改进 KUBECONFIG 的说明，尤其是
- 支持作为适当版本化、支持和记录的库使用。这包括遵循 semver，而不是每次发布都是对 API 的重大/破坏性更改（API 必须可扩展且不会破坏），确保 CLI 仅使用合适的公共库表面，库的文档和示例，公共 API 的版本化类型（例如配置格式）等。
- 待办事项：我们在这里到底想要什么？这真的应该成为 beta 阻塞吗？
- 应该能够对 kind 进行故障排除，而无需修改 kind ~或使用外部调试工具~（如果还不完美，现在应该可以做到！）
- 一致的日志记录（记录什么，何时记录，使用什么级别）（现在已经比较一致了，如果还不完美）用于在测试工具中管理集群
- 错误具有适当的上下文（这存在争议，永远不会完美，但已经改进很多，尤其是如果您使用
-v 1或更高版本）
- 将 API 类型/标签从
*.k8s.io移动到*.x-k8s.io - 支持所有当前 上游支持的 Kubernetes 版本
- 制定一个关于稳定节点镜像 <-> KIND 兼容性的计划
GA 要求 🔗︎
要达到“GA” 级别，kind 至少需要
- 支持非 AMD64 架构（即 ARM） - #166
- 自动发布基于 Kubernetes 版本的 kind“节点”镜像 - #197
- 支持除 docker/default 之外的其他运行时，包括 podman、ignite 等。
- 对倾斜的节点（Kubernetes）版本的一流支持（我相信现在已经相对一流了，如果您指定不同的节点镜像，事情应该可以正常工作）
- … 待定，这里将添加更多内容 …
非目标 🔗︎
- 支持所有可能的 Kubernetes 配置
- 为了最好地支持离线/隔离集群，我们可能不会开箱即用地提供许多 CNI 等选项。我们可能会在以后重新审视这一点。
- 成为“生产工作负载就绪” - kind 的用途是
- 用于测试 Kubernetes 本身
- 用于针对 Kubernetes 进行测试（例如在 Travis、Circle 等 CI 上）
- 用于开发人员机器上的“本地”集群
- 不适用于托管为用户流量提供服务的负载等。
- 替换 Phippy 🦒 – kind 并没有试图取代所有东西，而且 Phippy 很棒 ❤️
长期目标包括
- 为测试需要持久存储的应用程序启用合适的本地存储提供程序