How to Inject Environment Variables into a Kubernetes Pod and the Priority Issue

1. Several Ways for a Kubernetes Pod to Reference Environment Variables

1.1 Directly Key/Value

You can set the Value directly, and you can also use the current Pod’s information as the Value.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: Pod
metadata:
  name: envar-demo
  labels:
    purpose: demonstrate-envars
spec:
  containers:
    - name: envar-demo-container
      image: gcr.io/google-samples/node-hello:1.0
      env:
        - name: DEMO_GREETING
          value: "Hello from the environment"
        - name: DEMO_FAREWELL
          value: "Such a sweet sorrow"
        - name: MY_NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: MY_POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name

1.2 Referencing from a Secret

There are two ways to reference variables in a Secret:

Reference all variables in the Secret via envFrom
Reference a specific variable in the Secret via valueFrom

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
    - name: mycontainer
      image: redis
      envFrom:
        - secretRef:
            name: secret-config
      env:
        - name: SECRET_USERNAME
          valueFrom:
            secretKeyRef:
              name: secret-config
              key: username
        - name: SECRET_PASSWORD
          valueFrom:
            secretKeyRef:
              name: secret-config
              key: password

1.3 Referencing from a ConfigMap

There are two ways to reference variables in a ConfigMap:

Reference all variables in the ConfigMap via envFrom
Reference a specific variable in the ConfigMap via valueFrom

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: k8s.gcr.io/busybox
      envFrom:
        - configMapRef:
            name: configmap-config
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: special.how
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: env-config
              key: log_level

2. Priority of Variable References

From the source code, the implementation logic is that a Map is initialized to hold the environment variables, and then processing proceeds as follows:

Iterate in order over the Key/Value pairs of the ConfigMaps and Secrets referenced by envFrom
Iterate in order over the Key/Value pairs set in env
Since Pods enable EnableServiceLinks by default, Service-related variables must also be injected at the end

The priority is: Service variables > Env > EnvFrom, where for EnvFrom the later ones override the earlier ones.

Let me talk separately about the Service-related variables injected into the environment:

Injection scope. All Services in the namespace where the Pod resides.
Injected content. All service addresses, ports, and protocols under the same namespace.
Injection format. Uppercase letters with underscores, for example ADMIN_WEB_PC_TEST_PORT_80_TCP=tcp://10.233.45.183:80, ADMIN_WEB_PC_TEST_PORT=tcp://10.233.45.183:80, ADMIN_WEB_PC_TEST_PORT_80_TCP_ADDR=10.233.45.183, ADMIN_WEB_PC_TEST_PORT_80_TCP_PORT=80, ADMIN_WEB_PC_TEST_PORT_80_TCP_PROTO=tcp . If a large number of services are deployed under the same namespace, each Pod may accumulate several hundred such variables.