问题描述
在迁移到Kubernetes环境时，用户面临一个问题：每个应用程序的配置yaml文件应该放在存储应用程序源代码的仓库中，还是应该有一个专门用于存放所有配置文件的中央仓库。用户认为应该有一个中央仓库来管理所有配置，因为在不同版本的应用程序/服务之间的依赖关系可以在其中进行管理。另一个问题是，对配置文件的更改不应触发应用程序本身的重新构建，如果配置和应用程序仓库不同，这也会更容易实现。
解决方案
在选择方案时，请考虑你的组织需求和团队的实际情况。
在选择将Kubernetes配置文件放置在哪里时，没有绝对正确的答案，因为每种方法都有其优缺点。以下是两种常见的方法，供你参考。
方法1：每个应用程序仓库一个配置文件
在这种方法中，每个应用程序或服务都有其自己的仓库，其中包括了该应用程序的所有源代码以及与之相关的Kubernetes配置文件。这种方法的优点和缺点如下：
优点
- 紧密集成：配置文件直接与应用程序的代码存储在同一个仓库中，开发人员可以在同一地方管理代码和配置。
- 独立性：每个应用程序的配置相互隔离，更容易维护和测试。
- 清晰可见：应用程序的配置文件与应用程序代码紧密相关，更容易理解和跟踪。
缺点
- 重复配置：相同的配置可能在多个仓库中重复出现，增加了维护的复杂性。
- 版本控制：当多个应用程序共享相同的配置时，可能需要额外的工作来确保它们保持同步。
方法2：中央仓库管理所有配置文件
在这种方法中，有一个中央的仓库，用于存放所有应用程序和服务的Kubernetes配置文件。这些配置文件与应用程序的源代码分开存储。这种方法的优点和缺点如下：
优点
- 集中管理：所有配置文件都在一个地方，更容易统一管理和更新。
- 共享配置：多个应用程序可以共享相同的配置，避免了重复的劳动。
- 版本一致性：当一个配置文件发生变化时，可以确保所有使用它的应用程序都更新到同一版本。
缺点
- 耦合问题：更改配置可能会影响多个应用程序，需要小心管理以避免意外中断。
- 可见性降低：配置文件与应用程序代码分开存储，可能导致开发人员对配置的变化不够敏感。
无论选择哪种方法，都需要考虑你的组织的需求和团队的实际情况。你还可以根据实际情况，结合这两种方法的优点，制定适合你团队的混合方案。
Helm的建议
另外，如果你正在使用Kubernetes，我建议考虑使用Helm。Helm是一个Kubernetes包管理工具，可以帮助你更好地管理应用程序的配置。你可以在应用程序的源代码仓库中创建Helm图表定义，这样可以将应用程序的代码和配置集成在一起。如果你的服务数量不断增加，你可以考虑使用”monorepo”策略，将所有部署的Helm图表和其版本信息集中在一个仓库中，以便更轻松地跟踪不同版本的服务。
你可以在Helm的官方文档中了解更多信息：Helm官方文档
无论你选择哪种方式，都需要在团队内部做好沟通和协调，以确保配置文件和应用程序的管理能够高效且无缝地进行。