Helm 有两个部署

Agu*_*tro 5 kubernetes kubernetes-helm

我是使用 Helm 的新手,当您有两个部署时,我不确定哪种方法是最佳方法。我为我的应用程序创建了一个图表。它包含两个部署:

  1. app-nginx-phpfpm.yaml
  2. 应用程序-mysql.yaml

我应该将它们保留在同一个图表中还是应该为 app-mysql.yaml 创建一个子图表?

ssi*_*ice 5

您可以同时拥有两者,具体取决于您希望如何构建部署。

你应该记住以下几点

注意事项

单一图表的好处

  • 更易于部署:仅部署一次,单一差异化
  • 单一版本,因此回滚/升级发生在单个元素上
  • 您可以使用功能标志卸载部件
  • 在不接触其余元素的情况下安装新组件可能会很棘手

单一图表警告

  • 更难部署解耦服务,例如,升级数据库时用于数据访问的模拟服务
  • 更难解耦和测试每个实例
  • 更难命名和理解每个组件(在不同的版本中,您{{.Release.Name}}已经为每个“应用程序”更改了)。
  • 更难提供/跟踪不同组件的不同发布周期
  • 存储在单个 ConfigMap 中的版本,如果您的图表包含例如嵌入的测试数据,则可能会导致大小限制问题

版本控制注意事项

您可以拥有一个用于测试所有子图表的主图表,并独立打包子图表,但仍将所有内容放在同一个 repo 中。

例如,我通常会保留以下内容:

. / helm / charts / whatever / charts / subchart1
. / helm / charts / whatever / charts / subchart2
. / helm / charts / whatever / values.yaml
Run Code Online (Sandbox Code Playgroud)

或者

. / helm / charts / whatever-master / values.yaml
. / helm / charts / whatever-master / requirements.yaml
. / helm / charts / whatever-subchart1 / values.yaml
. / helm / charts / whatever-subchart2 / values.yaml
Run Code Online (Sandbox Code Playgroud)

并使用主图表上的 requirements.yaml 从file://../whatever-subchartx.

通过这种方式,如果需要whatever-stress-test,我可以并且whatever-subcomponent-unit-test仍然可以灵活地部署具有不同发布周期的单独组件。

这最终还取决于您的升级策略。金丝雀升级可能需要您以比使用单个图表更具体的方式处理有状态的微服务,因此请相应地进行计划。


Ric*_*ico 3

您可以将单个图表与两个部署一起使用,也可以将一个主图表与两个子图表(一个用于app-nginx-phpfpm.yaml,一个用于 )结合使用app-mysql.yaml。如果您的整个应用程序不会增长那么多,您可以使用单个图表。但是,如果您计划继续向应用程序添加组件(更多部署等),建议您使用子图。更多信息请参见此处。