我是Kubernetes的新手，只是从一个示例项目开始学习所有内容。我当前正在运行一个.NET微服务，该服务需要MongoDB作为数据库。将该微服务打包到一个Docker映像中，并且我已经创建了一个Helm图表以正确部署我的微服务和所需的MongoDB。
现在，我已经考虑过版本控制，并发现了这种方法的一个大问题：我不能只安装该头盔图表的多个版本来支持运行同一微服务的多个版本，因为那样一来，每个微服务都会获得自己的数据库，显然不是我想要的。
这是否意味着我必须为我的微服务创建两个头盔图表？因此，一个包含我的.NET服务的1 2图表和一个包含MongoDB的api图表？这样，我可以一次部署MongoDB，并让我的.NET服务的多个版本指向该单个实例。但是，那样的话，每个微服务我没有一个Helm图表，而是多个微服务，这增加了我猜测的部署开销。
这是怎么做的？还是我想念的东西？欢迎所有指向正确方向的线索！
答案 0 :(得分：1)
我建议每项服务提供一张图表。掌舵依赖性很好的地方是您可以嵌入/隐藏其他特定部分的服务。正如@christopher所说，如果您的.NET服务和MongoDB具有不同的生命周期，则不应将它们包装在同一张头盔图中。
使用Helm的最基本方法是拥有一个包含单个应用程序的图表。单个图表将包含您的应用程序所需的所有资源，例如部署，服务等。
Chart versions and appVersions
图表本身的版本（Chart.yaml中的版本字段）。的 图表中包含的应用程序版本（版本中的appVersion字段 Chart.yaml）。这些无关，可以以任何方式提高 你觉得合适。您可以将它们同步在一起或增加它们 独立地。只要您在这里没有对与错的做法 坚持一个。
这里重要的一点是，您需要在团队中就“图表更改”的含义采取政策。
头盔不强制更改图表版本。您可以部署具有与上一个相同版本的其他图表。因此，如果您要这样做，则需要确保所有团队都在同一页面上以进行版本控制。
从好的方面来说，此工作流程使您可以分别对图表和应用程序进行版本控制，对于具有由应用程序源代码分别管理图表的团队的公司而言，此操作非常灵活。
但是，您也可以创建一个依赖于其他图表（称为伞形图）的图表。
使用
requirements.yaml文件，它们完全是外部的。使用此策略是可选的，可以 在多个组织中运作良好。同样，没有确定的 在这里是非对错的答案，这取决于您的团队流程。
换句话说，每个都有各自的软件元素的集合 拥有单独的图表，但出于任何原因（例如，设计选择， 易于部署，版本控制复杂性），必须安装或 已升级为原子单位
总括图引用了Helm图本身的版本， 而不是容器映像的基础版本。这意味着任何 更改图像版本将导致图表修改 各个组件图。
决定选项时要考虑的因素
要考虑两个方面：
在有用的文章中进一步了解：helm-managing-microservices。
谈论微服务的版本控制以实现向后兼容性，请参阅Product Versioning Microservices，通常建议使用Semantic Versioning。
从广义上讲-应该有一个针对主要版本的商定的淘汰路线图，该路线图应与API使用者（以及SLA一起）传达。这就是为什么跟踪谁使用您的API如此重要的原因。看看这个有用的article about versioning management。
请参阅用于跟踪微服务版本的示例工具-DeployHub。