我们有几个选项可以正确管理kubernetes delcaration文件和dockerfiles。目前，服务开发可视为完全独立，无需任何跨服务通信。
哪种方法更好，并提供更大的灵活性？我们有2个服务，很快，内部网络配置复杂的服务柜台将增加到8个，而第3个选项看起来并不好看。
第二个选项更好，但我不太确定k8s单独的回购是不是一个好选择。虽然本地docker镜像也可能为本地开发带来一些困难，因为开发团队并不完全需要与其他服务交互并启动所有服务。
第一个选项看起来很好，因为它提供全面的责任奉献并解决了仅限devop的任务，但是当团队需要启动整个k8s集群时，将来可能会出现问题。但是，即使在这种情况下，这个回购可能会被拉到并执行minocube。
但这些选项对我来说都不是很好。我错过了什么吗？
我建议＃3。到目前为止，我与之合作过的所有公司都是这样做的。
一些Kubernetes本机开发工具如DevSpace（https://github.com/covexo/devspace）和Draft（https://github.com/Azure/draft）建议将Dockerfile和Kubernetes资源定义（或Helm图表文件）放入包含代码的存储库中。
使用＃3，开发人员将能够更好地重现生产环境以修复错误，并且CI / CD工具通常设置为使用与代码相同的repo中包含的定义作为代码的基础架构。
有例外，例如GitLab的Auto DevOps CI / CD工具。它非常适合与Kubernetes合作并使用外部图表。但是，他们这样做是因为他们希望简化到Kubernetes的CI / CD管道的设置，并希望从底层的Helm图表中抽象出来。但是，它们也允许自己定义Helm图表，并暗示它与代码位于同一个存储库中。
＃3是有利的，因为您可以确保在捆绑代码和“基础架构”定义时始终可以运行可重复的构建。假设您想要及时返回并使用旧版本的代码，您将使用哪个版本的非相关其他代表？将所有内容放在一个仓库中，将允许您签出任何修订或分支，并始终确保您可以构建和实例化您的代码。
示例：您更改了依赖关系管理工具，需要运行另一个命令来安装依赖关系。此更改将使您相应地更改Dockerfile。同时拥有代码+ k8s + Dockerfile，将确保您仍然可以实例化使用旧的依赖关系管理工具的旧版本。
在我看来 - 第二个选项是最有意义的选项 - 您可能希望在更改存储库的代码时更改Dockerfile，因此您可以通过一次推送来触发CI管道。在CI上，您还需要构建容器。此外，Dockerfile是一种资源，您经常希望DevOps和Dev团队能够访问并经常一起处理它们。
另外，如果你有CI集成，你想在每次更改Dockerfile后触发管道，当它与代码在同一个地方时会相当容易。
然后，您还将所有Kubernetes / Helm文件放在不同的（单个）存储库中，以便您可以管理它们并在必要时将它们组合到不同的微服务中（如果您有更复杂的部署）。在CI中，您只需要绘制图表/文件。
我认为将Dockerfiles及其部署文件（k8s YAML）全部放在其服务的同一个repo中更有意义，这使得构建和部署服务变得容易，因为CI / CD工具可以只提取新代码，构建然后部署图像。您也可以使用Helm方式退出服务存储库中的所有部署文件，它们可以在一个单独的helm图表中。 Helm路径使得应用程序整体易于查看。如果你不想在开发者机器上运行所有服务，你应该使用Telepresence。