在 Kubernetes 中，ConfigMap 可以通过多种方式供 Pod 使用，包括环境变量和文件卷。这两种方式的行为有所不同，特别是在更新配置的实时性方面。
许多人会注意到，当 ConfigMap 作为环境变量使用时，如果在运行时修改了 ConfigMap，Pod 并不会自动获取到这些更新，必须重启 Pod 才能使新配置生效。而如果是通过文件卷的方式，更新后的配置可以实时反映到 Pod 中。这背后的原因与环境变量和文件系统的工作原理有关，也与容器和 Kubernetes 自身的机制相关。
环境变量的设计与限制
在容器技术中，环境变量是一种非常常见的配置方式，因为它们易于使用和理解。通过定义环境变量，我们可以将配置直接注入到容器的进程中。程序在启动时会读取这些环境变量，并根据这些变量的值来设定其运行时行为。然而，这也意味着环境变量的生命周期是从进程启动到进程结束，这一设计使得环境变量在进程运行时无法动态更新。
假设我们有一个 Pod，它的启动命令如下：
command: ["myapp"]
env:
- name: APP_CONFIG
valueFrom:
configMapKeyRef:
name: my-config
key: config.json
在这个示例中，APP_CONFIG 环境变量在 Pod 启动时会从 my-config ConfigMap 中获取 config.json 的值。Pod 中的 myapp 程序会在启动时读取这个环境变量，然后决定如何加载配置。这个过程在容器启动时就已经确定，因为环境变量的值是在进程启动时注入的。
这里的关键点在于环境变量的性质——它们不会在进程生命周期内动态更新。这意味着即使 Kubernetes 中的 ConfigMap 被更新，环境变量仍然是旧的值，因为这个值是在启动时固定下来的。要让应用程序获取到新的配置，唯一的办法就是重启 Pod，使得它再次读取环境变量。
文件卷与挂载的机制
相比之下，ConfigMap 通过文件卷的方式使用时，情况会大不相同。Kubernetes 允许我们将 ConfigMap 挂载到 Pod 的文件系统中，作为一个目录或者文件。使用这种方式时，如果 ConfigMap 被更新，Pod 中对应的文件也会更新。这背后的原因与 Linux 的文件系统机制有关。
比如，有一个 ConfigMap 作为文件卷挂载的示例：
volumes:
- name: config-volume
configMap:
name: my-config
containers:
- name: my-container
image: my-image
volumeMounts:
- name: config-volume
mountPath: /etc/config
在这种设置下，my-config 中的所有键值对会被作为文件挂载到 /etc/config 目录中。程序可以直接读取这些文件内容，作为其配置。在这种情况下，如果我们更新了 my-config，Kubernetes 会检测到 ConfigMap 的变化，并且会通过更新文件系统中的内容，来将这些变化传递给 Pod。由于文件系统的这种机制，应用程序读取文件时就会拿到最新的内容。
为什么文件卷可以做到这一点？这背后是 Kubernetes 的原生机制。在 Kubernetes 中，当 ConfigMap 被更新时，Kubernetes 会更新相应的挂载文件内容，实际上是通过文件符号链接的方式实现。Kubernetes 将文件更新成新的版本，但会保持符号链接路径不变，这样原本读取文件的程序可以不做任何更改。
举个具体的例子，如果我们在 Pod 中执行以下命令：
cat /etc/config/config.json
我们会得到最新版本的 config.json 文件内容。因为 Kubernetes 会在后台自动更新这个文件。当 ConfigMap 内容变更时，它会新生成一个文件并更新符号链接，使得 /etc/config/config.json 指向新的文件版本。
为什么需要重启 Pod 来获取更新的环境变量
通过上面的分析可以理解，环境变量与文件系统的区别在于它们在容器中的生命周期管理。环境变量注入是在容器启动时完成的，并且之后不再改变。即使 Kubernetes 的 ConfigMap 发生了变化，也无法动态更新到已经运行的进程中。这种行为来自于 Unix/Linux 系统的一个基础设计——环境变量仅在进程启动时设定，并且无法通过外部手段在进程运行期间更改。
从 Kubernetes 的角度来看，环境变量的更新涉及到 Pod 模板的变更。Pod 是由 PodSpec 定义的，当 Pod 创建后，PodSpec 是固定的，不会再被动态更新。因此，如果我们希望通过环境变量的方式让应用程序接收到新的配置值，就必须重新创建 Pod，这样 Kubernetes 才会重新按照新的 PodSpec 创建一个带有最新环境变量的 Pod 实例。
再用一个实际的例子来说明。假设我们的应用程序 myapp 是一个 Web 服务，通过读取 APP_PORT 环境变量来决定它监听的端口。如果我们希望更改这个端口号，我们会更新 ConfigMap 并重新应用 Kubernetes 配置。然而，由于 APP_PORT 是通过环境变量注入的，myapp 必须重启，新的进程才能读取到最新的 APP_PORT 值。否则，旧的进程依然使用的是原来的端口。
动态更新的应用场景
文件卷这种方式非常适合需要动态配置的应用场景。假设有一个微服务 myapp，需要频繁读取配置，比如一些实时调整的参数，或者是新的访问控制列表。在这种情况下，应用程序可以直接读取挂载文件，随时获取到最新的配置信息。我们可以通过使用文件系统事件监听的方式（如 inotify 机制），检测到文件内容的变化，并根据这些变化来动态调整应用程序的行为，而不必重启服务。
在生产环境中，有很多服务依赖于这种配置更新机制，比如 Nginx 的热更新配置，监控服务的实时调整参数等。通过文件卷的方式，可以避免服务中断，同时又能保证配置的灵活性。
而环境变量适合那些在启动时确定的、不会频繁变化的配置，比如应用程序的版本信息、服务模式（开发、测试、生产）等。这些信息通常不会在服务运行时频繁更改，因此使用环境变量传递是最为直接和高效的。
Kubernetes 的实现细节
Kubernetes 在设计之初考虑到了这些场景的不同需求，给予了开发者灵活的选择。文件卷的实时更新是通过 kubelet 和 API server 的通信来实现的。每当 ConfigMap 发生变化，kubelet 会监听到这些变更，并自动刷新 Pod 中的文件内容。实现这一点的关键是 Kubernetes 对文件系统挂载的操作。为了确保 Pod 中的文件始终是最新的，Kubernetes 会通过 projected volume 的方式，使用 emptyDir 和符号链接，将文件更新切换到最新的版本。
而环境变量的更新则无法使用相同的机制，因为 Unix 环境变量的不可变性。即使 Kubernetes 更新了 ConfigMap，Pod 内部的环境变量也不会因此改变。这意味着 Pod 必须重新启动，以新的 ConfigMap 数据重建环境。
这一点在大规模分布式系统中尤为重要。想象一下，一个由数百个实例组成的服务群，如果每次配置更新都要求重启实例，这将对系统的可用性造成巨大的冲击。而通过文件卷的方式，应用程序可以在不停机的情况下接受到最新配置，从而大大提高了系统的灵活性和稳定性。
总结与推荐
ConfigMap 作为环境变量与作为文件卷时的不同表现，源自底层系统机制的不同。环境变量是静态的，一旦进程启动就不会改变，而文件卷则是动态的，Kubernetes 可以通过更新挂载的文件内容实现配置的实时更新。这让开发者在设计系统时有了更多的选择，可以根据应用程序的需求选择合适的配置加载方式。
对于需要动态调整的配置，推荐使用文件卷方式来加载 ConfigMap；而对于在启动时固定不变的配置，使用环境变量则更加简洁明了。
