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

Posted 2023-01-23

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

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

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

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

最适合您的方法是什么？

答案

确实有两种方法可以起作用：将实际值传递到每个图表中，或为此创建共享对象（在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中，用于保护普通Secrets的相同RBAC控件也可以保护Helm内部使用的Secret对象。

---

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

Helm的依赖机制使图表变平，以至于图表实际上无法正常工作。假设您拥有依赖Redis的服务A，也依赖Redis的服务B，并且这两个服务期望各自具有自己的Redise。如果您尝试获取同时依赖于A和B的顶级图表，Helm将仅安装一个Redis并共享它。这可能会带来麻烦。