放置 kubernetes 和 dockerfile 的位置

Question

我们有多种选择来正确管理 kubernetes decaration 文件和 dockerfile。目前，服务开发可以被认为是完全独立的，没有任何跨服务通信。

1. 设置单独的存储库，其中包含所有 k8s 和 docker 说明以及构建/部署脚本。
2. 为 k8s 声明设置单独的存储库，并将 docker 文件保留在适当服务的存储库中。
3. 所有 k8s 声明和 docker 文件都放置在服务代码附近（与代码相同的存储库）

哪种方法更好并且提供更大的灵活性？我们有 2 个服务，很快具有复杂内部网络配置的服务计数器将增加到 8 个，而第三个选项看起来一点也不好看。

第二个选项更好，但我不太确定 k8s 单独的存储库是否是一个不错的选择。虽然本地 docker 镜像也可能会给本地开发带来一些困难，因为开发团队并不完全需要与其他服务交互并启动所有服务。

第一个选项看起来不错，因为它提供了全责奉献并仅解决 DevOps 任务，但将来当团队需要启动整个 k8s 集群时可能会导致问题。但是，即使在这种情况下，这个存储库也可能会针对 minikube 被拉取和执行。

但这些选择对我来说都不是很好。我错过了什么吗？

Answer 1

我会推荐#3。到目前为止，我合作过的所有公司都保持这种状态。

从 Kubernetes 原生的角度来看

一些Kubernetes 原生开发工具，如 DevSpace ( https://github.com/covexo/devspace )和 Draft ( https://github.com/Azure/draft ) 建议将 Dockerfile 和 Kubernetes 资源定义（或 Helm 图表文件）放入存储库中也包含代码。

从DevOps 的角度来看

使用#3，开发人员将能够更好地重现生产环境以修复错误，并且 CI/CD 工具通常设置为使用基础设施即代码，例如包含在与代码相同的存储库中的定义。

但也有例外，例如 GitLab 的 Auto DevOps CI/CD 工具。它的设计非常适合与 Kubernetes 配合使用，并可与外部图表配合使用。然而，他们这样做是因为他们希望简化 Kubernetes 的 CI/CD 管道的设置，并希望从底层 Helm 图表中进行抽象。但是，它们还允许您自己定义 Helm 图表，并暗示它与代码位于同一存储库中。

从版本控制的角度来看

#3 是有利的，因为您可以确保在捆绑代码和“基础设施”定义时始终可以运行可重复的构建。假设您想回到过去并使用旧版本的代码，您会使用哪个版本的不相关的其他存储库？将所有内容都放在一个存储库中，将允许您签出任何修订或分支，并始终确保您可以构建和实例化您的代码。

示例：您更改了依赖项管理工具，需要运行另一个命令来安装依赖项。此更改将使您相应地更改 Dockerfile。将代码 + k8s + Dockerfile 放在一起，将确保您仍然可以实例化使用旧依赖管理工具的旧版本。