Mastering Kubernetes Environment Variables: Static, Dynamic, and ConfigMap Strategies

1. Static Environment Variables

Explicit Definition

You can define environment variables directly in a Dockerfile using the syntax ENV <key> <value>. For example, to set the container timezone you might use ENV TZ=Asia/Shanghai, or define JVM options such as:

ENV JVM_OPTS="-Xms1024m -Xmx1024m -Xmn386m -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Xss256k"

Implicit Inclusion

Besides explicit definitions, environment variables can be sourced from other files within the image. For instance, the official Tomcat image runs catalina.sh, which sources setenv.sh where additional variables can be defined.

2. Dynamic Environment Variables

Static variables lack flexibility, so dynamic environment variables are often required. Their semantics must not conflict with static ones; for example, a static APP_NAME variable can be overridden but its meaning should remain consistent. Two typical dynamic use cases are presented:

1. Application in Microservice Deployment

Using a release platform combined with Helm, you can inject variables such as JVM_OPTS with different values per environment (e.g., 512M for testing, 2G for production). The process involves defining variables in a Jenkins pipeline and passing them to Helm via helm set to achieve unified configuration across environments.

In the Jenkins pipeline, variables are defined with def syntax and injected into the Kubernetes deployment via Helm templates. Example snippets include multi‑branch pipeline configuration, Helm template injection, and usage in a docker-entrypoint.sh startup script.

2. Application in Microservice Logging

When processing logs, you often need Kubernetes metadata such as the pod namespace, which cannot be handled by static variables. Dynamic injection at pod startup via Helm templates enables this capability.

3. Environment Variables Based on ConfigMap

The Kubernetes documentation defines a ConfigMap as an API object that stores non‑confidential data in key‑value pairs, which pods can consume as environment variables, command‑line arguments, or configuration files.

To use a ConfigMap, reference its key with configMapKeyRef and inject it into env. You can also mount a ConfigMap as a file and treat its contents as dynamic variables. For example, a Log4j2 ConfigMap can be mounted and referenced in a Helm template, allowing the logging configuration to be managed centrally without requiring developers to maintain individual config files. However, it is recommended to keep business configuration in dedicated configuration centers (e.g., Nacos, Apollo) rather than ConfigMaps.

4. Summary

Proper use of Kubernetes environment variables helps unify operational logic, reduce complexity, and maximize reuse of existing standards, achieving minimal configuration overhead.