使用多个Helm图表管理ConfigMap，PVC和Secrets的最佳方法

Question

我致力于在IaaS模型上运行的具有多个后端，前端和微服务的完整数字解决方案。 我们在基于Kuanetes和Helm的基于CaaS的基础架构上进行部署。

许多应用程序共享可以在ConfigMap和Secrets中找到的信息，并且它们共享相同的数据或tmp PVC。

实际上，我在每个应用程序中都创建了一个图表，每个环境的值都为env.yaml，但是我不知道将configmap，pvc和secrets文件放在何处。

使用根目录中的单个configmap.yaml，pvc.yaml和secrets.yaml文件创建带有每个图表（如“子图表”）的项目是否正确？

最适合您的方法是什么？

Answer 1

实际上有两种方法可行：将实际值传递到每个图表中，或为这些事物创建共享对象（在Helm中或使用kubectl apply，或通过CI /部署工具或。）。 ），并将其名称传递到每个图表中。

如果您拥有最终共享的主数据库登录名之类的东西，则可以创建一个保存这些凭据的秘密（再次，手动或通过其他工具）。每个图表的values.yaml都有对此的引用

databaseSecretName: db-credentials

然后将基于此设置环境变量

env:
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: {{ .Values.databaseSecretName }}
        key: username

最大的局限性在于，机密必须与引用该机密的Pod位于同一命名空间中。

另一种方法是将其直接传递到Helm值：

env:
  - name: DB_USERNAME
    value: {{ .Values.databaseUsername | required "databaseUsername is required" }}

部署时，您可以使用helm install -f参数提供其他覆盖值的YAML文件，该文件提供每个环境的凭据。

这两种方法都可以用于您描述的任何Kubernetes对象类型。对于Secrets，任何可以访问Helm状态的人都可以轻松地检索它们。在Helm 2中，这是有权使用Tiller吊舱的任何人；在Helm 3中，保护普通机密的RBAC控件也可以保护Helm内部使用的Secret对象。

---

一个标准的微服务规则是每个服务应具有 isolated 数据；没有服务直接访问另一个服务的数据，并且所有通信都是通过API。在您谈论共享PVC的地方，或者我上面的示例谈论共享数据库凭据的地方，通常不是最佳实践。

Helm的依赖机制以一种图表的方式使事情变得平淡无奇。假设您拥有依赖Redis的服务A，也依赖Redis的服务B，并且这两个服务期望各自具有自己的Redise。如果您尝试获取同时依赖于A和B的顶级图表，Helm将仅安装一个Redis并共享它。这可能会带来麻烦。