如何在K8s中通过Helm实现Configmap与Secret或双Secret的合并

核心实现可行性 #

该需求完全可以通过Kubernetes/Helm原生能力实现，无需开发自定义CRD控制器、无需配置initContainer挂载卷、无需修改Vault侧的Secret配置逻辑，最终产出的就是可直接被CRD引用的独立Secret对象。整个实现无额外组件依赖，所有逻辑均通过Helm模板原生语法完成。

关键实现逻辑 #

• 绕开Vault Secret的保护逻辑：不要直接修改Vault托管的原生Secret对象——Vault控制器会周期性对其进行reconcile校验，手动添加的ConfigMap数据会被同步覆盖。我们的目标是生成一个Helm全权管理的独立合并Secret，仅在渲染时拉取Vault托管Secret的现有数据。
• 用Helm原生lookup能力获取集群现有资源：Helm在渲染阶段可直接调用Kubernetes API拉取集群内已存在的资源对象，无需运行额外的工作负载或控制器。
• 直接复用已编码的data字段合并：Secret与ConfigMap的data字段均为base64编码存储，可直接拼接复用，无需额外做编解码转换。

具体模板实现 #

首先在模板头部增加资源拉取与校验逻辑，避免首次部署时资源创建顺序问题导致生成空Secret：

{{- /* 拉取Vault已创建的托管Secret */}}
{{- $vaultManagedSecret := lookup "v1" "Secret" .Release.Namespace "vault-secret-target-name" }}
{{- /* 拉取Chart中定义的现有ConfigMap */}}
{{- $chartConfigMap := lookup "v1" "ConfigMap" .Release.Namespace (include "chart.fullname" .) }}

{{- /* 资源存在性校验 */}}
{{- if not $vaultManagedSecret }}
{{- fail "未找到指定的Vault托管Secret，请确认Vault同步任务已完成" }}
{{- end }}
{{- if not $chartConfigMap }}
{{- fail "未找到Chart定义的目标ConfigMap，请检查模板配置" }}
{{- end }}

随后渲染供CRD引用的合并Secret：

apiVersion: v1
kind: Secret
metadata:
  name: merged-secret-for-crd  # 供CRD直接引用的独立Secret
  namespace: {{ .Release.Namespace }}
  labels:
    app.kubernetes.io/managed-by: Helm
type: Opaque
data:
  {{- /* 导入Vault Secret的所有键值 */}}
  {{- toYaml $vaultManagedSecret.data | nindent 2 }}
  {{- /* 追加ConfigMap的所有键值，若键名与上方重复，ConfigMap的键会覆盖Vault的键 */}}
  {{- toYaml $chartConfigMap.data | nindent 2 }}

落地注意事项 #

• 同步逻辑触发时机：lookup函数仅在Helm执行install/upgrade操作时实时拉取集群资源。当Vault侧更新了托管Secret的内容时，仅需执行一次Helm升级，合并后的Secret就会同步最新数据，无需主动编写轮询逻辑。
• 键值覆盖规则：若两类资源存在相同键名，模板中靠后的渲染块会覆盖靠前的键值，可根据业务需求调整两个data块的顺序，控制最终的键值优先级。
• 权限校验：确保Helm使用的服务账号拥有对应命名空间下Secret、ConfigMap的get权限，否则lookup函数会无法拉取资源返回空值。
• 资源独立性：该合并Secret由Helm全权管理，不会被Vault的同步逻辑修改，完全符合CRD对单个Secret引用对象的要求。

内容的提问来源于stack exchange，提问作者Kristoph Matthews