Kubernetes微服务版本控制

Question

我对Kubernetes还很陌生，只是从一个示例项目开始学习。我目前正在运行一个.NET微服务，它需要一个MongoDB作为数据库。微服务被打包到Docker映像中，我创建了一个单独的Helm图表来正确部署我的微服务和所需的MongoDB。

是这样做的吗？还是我错过了什么？所有给我指明正确方向的线索都非常欢迎！

Answer 1

我建议每种服务一张图表。helm依赖关系工作良好的地方是您有一个嵌入/隐藏特定单个其他部分的服务的地方。正如@Christopher所说的，如果您的.NET服务和MongoDB有不同的生命周期，那么它们不应该打包在同一个helm图表中。

使用Helm的最基本方法是使用一个包含一个应用程序的单一图表。单个图表将包含应用程序所需的所有资源，如部署、服务等。

图表版本和应用版本

图表本身的版本（chart.yaml中的version字段）。包含在图表中的应用程序的版本（chart.yaml中的appVersion字段）。这些是不相关的，可以以任何方式，你认为合适。您可以将它们同步在一起，也可以让它们独立增加。这里没有正确或错误的做法，只要你坚持一个。

这里很重要的一点是，您需要在您的团队中就“图表更改”意味着什么采取一个策略。

Helm不强制更改图表版本。您可以部署与上一个图表版本相同的不同图表。因此，如果这是您想要做的事情，您需要确保所有的团队在版本控制实践上都是一致的。

从好的方面来说，这个工作流允许您单独地对图表和应用程序进行版本化，对于那些拥有将图表与应用程序源代码分开管理的团队的公司来说，这个工作流非常灵活。

伞状图

但是，也可以创建一个与其他图表有依赖关系的图表，称为伞形图表。

它们完全是外部的，使用requirements.yaml文件。使用此策略是可选的，可以在几个组织中很好地工作。再说一遍，这里没有关于对与错的确定答案，这取决于你的团队过程。

看一下：umrella-charts-example。

换句话说，一个软件元素的集合，每个元素都有自己的单独的图表，但是，无论出于什么原因（例如，设计选择、易部署性、版本控制复杂性），都必须作为一个自原子单元安装或升级

伞状图引用的是Helm图本身的版本，而不是容器映像的基础版本。这意味着对图像版本的任何更改都将导致对单个组件图表的图表修改。

在决定一个选项时要考虑什么

有两个方面需要考虑：

• 团队结构：你必须问自己这样的问题：你是否有小型的自治团队来负责每项服务？您是否有了解DevOps的开发人员？
• 依赖性和可复制性：您必须问自己这样的问题：每个服务的依赖性有多大差异？对一种服务的更改会破坏另一种服务的风险是什么？如何再现特定开发的条件？

阅读更多有用的文章：helm-managing-microservices。

在更广泛的意义上--应该有一个主要版本的商定的逐步淘汰路线图，并将其传达给API消费者（以及SLA）。这就是为什么跟踪谁使用您的API是重要的。请参阅这篇关于版本管理的有用文章。

请参见跟踪微服务版本的示例工具-DeployHub。