Question

在创建部署时，我目前正在尝试找出将容器的环境变量外部化为configmap的原因。因此，与其使用

定义环境变量，

    env:
    - name: LANGUAGE
      value: "English"

在deployment.yaml中使用

    env:
    - name: LANGUAGE
      valueFrom:
        configMapKeyRef:
          name: language
          key: LANGUAGE

或

      envFrom:
      - configMapRef:
          name: env-configmap

带有一个额外的configmap.yaml，如下所示：

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-configmap
data:
  LANGUAGE: English

当然，当使用机密值时，应从机密中读取它们，但这不适用于非机密变量。我看到的唯一好处是我可以重用这些configmap，但除此之外，这只会使图表变得更加复杂，因为我现在必须确保重新启动Pod等。

因此：使用ConfigMaps读取环境变量时，还有哪些其他优点？

Answer 1

如您所指出的，您可以重新使用ConfigMap，以便图表的其他部分可以easily re-use the same environment variables。这项功能的实用性取决于您拥有多少变量以及在多少变量中使用它们。

在群集中，其他Pod可以使用ConfigMap作为对象，其他Pod也可以使用，包括那些不在图表中的对象。这可能意味着您的configmap被安装在同一群集中的其他应用程序引用，或者可能是您选择发布图表，然后将其打包为另一个图表中的依赖项。如果将您的图表用作另一个图表中的依赖项，那么对于在您之上构建的图表以从ConfigMap引用配置的某些部分，它会使事情变得更容易/更干净。因此，有用性还取决于您打算如何使用图表。 official charts使用大量的ConfigMap，但有时确实直接使用环境变量，它们use ConfigMaps in a variety of ways for different purposes。

Answer 2

通过使用configmap，您可以将配置与容器定义分开。 ConfigMap的一个优点是，它使您可以使变量的值可供不一定要包含在图表中的其他Pod或应用访问。

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

它确实增加了一些额外的复杂性，并且在何时使用ConfigMap方面可能会有很大的偏好。由于您的ConfigMap键是环境变量的名称

您可以使用envForm轻松完成部署，如图here

在Kubernetes / Helm中为环境变量使用configmaps的优势

2 个答案: