我应该为每个环境变量使用 configMap 吗？

Question

我现在正在使用头盔。我的项目是这样的：

值.yaml：

environmentVariables:
  KEY1: VALUE1
  KEY2: VALUE2

configmap.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "myproject.fullname" . }}
data:
{{- range $k, $v := .Values.environmentVariables }}
  {{ $k }}: {{ $v | quote }}
{{- end }}

部署.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ template "myproject.fullname" . }}
spec:
  template:
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          env:
{{- range $k, $v := .Values.environmentVariables }}
            - name: {{ $k }}
              valueFrom:
                configMapKeyRef:
                  name: {{ template "myproject.fullname" $ }}
                  key: {{ $k }}
{{- end }}
...

但是现在，我真的很困惑。我真的需要这个配置图吗？对环境变量使用 configmap 有什么好处吗？

Answer 1

除了将 config 与 pod 分离的要点之外，ConfigMap 的一个优点是它允许您使变量的值可供其他 Pod 或应用程序访问，这些值不一定属于您的图表的一部分。

不过，它确实增加了一些额外的复杂性，并且可能有很多关于何时使用 ConfigMap 的偏好元素。由于您的 ConfigMap 键是环境变量的名称，因此您可以使用“envFrom”稍微简化您的部署

Answer 2

即使您不使用 configmap 它也能工作，但它有一些优点：

• 您可以在运行时更新值，而无需更新部署。这意味着您可能不需要重新启动应用程序（pod）。如果您不使用配置映射，则每次更新该值时，您的应用程序（或 pod）都会重新创建。
• 关注点分离，即部署配置和外部值分离

Answer 3

我觉得这很大程度上是一个品味问题；但对于此类情况，我通常会避免使用 ConfigMap。

env:
{{- range $k, $v := .Values.environmentVariables }}
  - name: {{ quote $k }}
    value: {{ quote $v }}
{{- end }}

您通常需要单一的事实来源，而 Helm 可能是这样的：您不希望出现这样的情况：有人在 Helm 之外编辑了 ConfigMap，并且重新部署会破坏本地更改。因此，与 Deployment 规范相比，ConfigMap 的“可编辑性”并没有多大价值。

原则上（如 @Hazim 指出），您可以在不重新启动容器的情况下更新 ConfigMap 内容，但这本质上无法更新正在运行的容器中的环境变量，并且重新启动容器是如此例行公事，因此执行一次应该没有多大关系。