假设我有5个要在Kubernetes集群中部署的api，我的问题就是存储与Kubernetes相关的yaml文件的最佳实践是什么。
在我在线上看到的项目中，Kubernetes yaml文件只是添加到api项目本身中。我想知道在一个完全独立的“项目”中解耦与Kubernetes相关的所有文件是否有意义，并且由VC项目作为与api项目本身完全分离的实体进行管理。
之所以出现这个问题，是因为我目前正在阅读有关Kubernetes的一本书，涉及主题名称空间，并且认为在每个环境中使用单独的名称空间（DEV / UAT / PROD）可能是一个好主意，将这些文件放在一个集中的“ Kubernetes”项目中（除非每个环境有一个单独的群集可能更好（？））。
答案 0 :(得分：2)
是否将Yaml与该应用程序放置在相同的存储库中是一个问题，项目会以不同的方式进行回答。如果您发现经常同时更改两者，或者只是更清晰地看到所有内容，则可能需要将它们放在一起。如果您主要是单独处理Yaml，或者发现它不太整洁或者希望获得不同的可见性（例如，不同的团队来研究），则可以分开。如果事情变得更加复杂，那么您实际上将需要从模板生成yaml，并在部署时将特定于环境的配置注入到其中（无论这些环境是名称空间还是集群）-有关此的更多讨论，请参见Best practices for storing kubernetes configuration in source control。
答案 1 :(得分：2)
根据CI / CD的Production k8s经验：
每个项目一个名称空间
每个项目一个git部署库