我们可以为所有微服务提供集中式 helm 图表存储库吗

Question

我们的团队正在开发基于微服务架构的应用程序。并将使用 helm chart 部署在 Kubernetes 上。

我们将使用 Azure DevOps 来管理项目以及管道。
并参考以下 URL 管理 CI/CD：https://learn.microsoft.com/en-us/azure/architecture/microservices/ci-cd-kubernetes

我们有以下两种情况来管理 Helm 图表：

1. 我们是否应该有一个用于 helm 图表的集中存储库，我们将在其中拥有每个微服务的子图表？
   • 在这种情况下，我们只能有一个发布管道，它将使用这个集中的 Helm 图表存储库来升级 Kubernetes 中的更改。
   • CI 管道的Helm package 作业中存在问题，它只允许我们在为其创建管道的微服务存储库中选择图表。
     我认为我们可以通过为Helm package and Push 作业创建单独的管道来解决这个问题，这样我们就可以从集中的 Helm 存储库中选择图表。并且这条管道对于所有微服务都是通用的，并且会在 CI 管道之后触发。

   或者

   2. 我们应该在相应的微服务存储库中有一个图表吗？
   • 在这种情况下，我们需要为每个微服务有一个单独的发布管道。
   • 还可以单独管理舵图。
   • 如果 2 个或更多微服务发生更改，如何在 QA 环境中管理集成测试部署。由于每个服务都将单独部署，这将如何同步？

   请向我们建议最好/推荐的方式，以便我们继续前进。

   提前致谢。

Answer 1

如果你的微服务有常用配置和细微差别，那么集中存储库是有意义的。但我不建议为每个微服务使用带有子图的父掌舵图。

最好构建一个 helm 图表作为模板，以便您可以为每个微服务部署引入不同的值。当微服务具有数据库或键值存储服务等共同需求时，子图表通常很有用。

另一方面mono-repo将通过过滤具有如下目录结构的微服务更改来简化您的发布管道：

./微服务：

• 付款
• 运费
• ...

对于 QA 环境，我会同时保留同一个微服务部署的多个版本，这样在执行测试时就不会出现瓶颈。这也适用于生产环境，因为无法确定所有依赖项始终是最新的。

作为替代 helm 图表可以位于不同的存储库中。微服务仓库只构建和推送容器镜像。当 helm chart 版本更新时，像 Flux/ArgoCD 这样的 Gitops 运算符会触发部署。

如果您选择金丝雀部署，Flagger 和 ArgoCD 都提供内置的冒烟测试功能。