时间戳

首页 > 解决方案 > 使用多个 Helm 图表管理 ConfigMap、PVC 和 Secret 的最佳方式

kubernetes-helm - 使用多个 Helm 图表管理 ConfigMap、PVC 和 Secret 的最佳方式

问题描述

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

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

实际上，我在每个应用程序中创建了一个图表，每个环境都有一个 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 并共享它。这可能是麻烦的根源。

推荐阅读