我致力于开发一个完整的数字解决方案，该解决方案包含多个后端、前端和微服务，并在 IaaS 模型上运行。 我们使用基于 CaaS 的基础架构，使用 Kubernetes 和 Helm 进行部署。
许多应用共享可在 ConfigMap 和 Secrets 中找到的信息，并且它们共享相同的数据或 tmp PVC。
其实我在每个app里都创建了一个chart，每个环境都有一个values-env.yaml，但是不知道configmap、pvc和secrets文件放在哪里。
创建一个包含每个图表的项目是否正确，例如“子图表”，根目录有单个 configmap.yaml、pvc.yaml 和 secrets.yaml 文件？
对你来说最好的方法是什么？
【问题讨论】：
标签： kubernetes-helm
实际上有两种方法可以工作：将实际值传递到每个图表中，或为这些东西创建共享对象（在 Helm 中，或使用 kubectl apply，或通过您的 CI/部署工具，或...）并将他们的名字传递到每个图表中。
如果您有类似主数据库登录名之类的东西最终被共享，您可以创建一个包含这些凭据的 Secret（同样，手动或通过其他工具）。每个图表的values.yaml 都会引用它
databaseSecretName: db-credentials
然后它会根据这个设置环境变量
env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: {{ .Values.databaseSecretName }}
key: username
最突出的限制是 Secret 必须与引用它的 Pod 位于同一命名空间中。
另一种方法是直接将其传递给 Helm 值：
env:
- name: DB_USERNAME
value: {{ .Values.databaseUsername | required "databaseUsername is required" }}
部署时，您可以使用 helm install -f 参数提供一个额外的 YAML 覆盖值文件，该文件提供每个环境的凭据。
这两种方法都适用于您描述的任何 Kubernetes 对象类型。在 Secrets 的情况下，任何可以访问 Helm 状态的人都可以轻松地检索它们。在 Helm 2 中，这是任何有权访问 Tiller pod 的人；在 Helm 3 中，保护普通 Secret 的相同 RBAC 控件也可以保护 Helm 内部使用的 Secret 对象。
一个标准的微服务规则是每个服务都应该有独立的数据；没有服务直接访问另一个服务的数据，所有通信都是通过 API 进行的。如果您谈论共享 PVC，或者我上面的示例谈论共享数据库凭据，这通常不是最佳实践。
Helm 的依赖机制以一种图表形式不能很好地工作的方式使事情变得扁平化。假设您有依赖于 Redis 的服务 A 和也依赖于 Redis 的服务 B，并且这两个服务都希望各自拥有自己的 Redis。如果你尝试拥有一个同时依赖 A 和 B 的顶层图表，Helm 只会安装一个 Redis 并共享它。这可能是麻烦的根源。
【讨论】：