Using Kubernetes envFrom for environment variables

deployment.yml

# Use envFrom to load Secrets and ConfigMaps into environment variables

apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: mans-not-hot
  labels:
    app: mans-not-hot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mans-not-hot
  template:
    metadata:
      labels:
        app: mans-not-hot
    spec:
      containers:
        - name: app
          image: gcr.io/mans-not-hot/app:bed1f9d4
          imagePullPolicy: Always
          ports:
            - containerPort: 80
          envFrom:
          - configMapRef:
              name: env-configmap
          - secretRef:
              name: env-secrets

env-configmap.yml

# Use config map for not-secret configuration data

apiVersion: v1
kind: ConfigMap
metadata:
  name: env-configmap
data:
  APP_NAME: Mans Not Hot
  APP_ENV: production

env-secrets.yml

# Use secrets for things which are actually secret like API keys, credentials, etc
# Base64 encode the values stored in a Kubernetes Secret: $ pbpaste | base64 | pbcopy
# The --decode flag is convenient: $ pbpaste | base64 --decode

apiVersion: v1
kind: Secret
metadata:
  name: env-secrets
type: Opaque
data:
  DB_PASSWORD: cDZbUGVXeU5e0ZW
  REDIS_PASSWORD: AAZbUGVXeU5e0ZB

@olso

cool!

Does a change to the config-map/secret referenced in envFrom trigger a rolling update to the deployment?
What if that variable is reused in the actual env section:

envFrom:
- configMap: foobar-mode
env:
- name: ACTIVE_PROFILES
  value: "a,b,c,${FOOBAR_MODE}"

And I would like to know, whether that is in the spec or just undefined behavior.

AFAICT it does not restart by itself

Does a change to the config-map/secret referenced in envFrom trigger a rolling update to the deployment?

No

What if that variable is reused in the actual env section.

env has precedence over envFrom. See https://stackoverflow.com/a/54398918/581584

Interesting! I am currently debugging an application where exactly this configuration will not update the variable inside the container despite deleting and recreating the deployment.

I didn't use the valueFrom/configMapKeyRef, but envFrom and used ${VAR} inside env section (deployment).
The env in the pod-env was updated after deleting the pod (it will automatically be recreated from the deployment).

env has precedence over envFrom
Not directly related, but I have NestJS app, and as I as I see there are two variables (PORT and NODE_TLS_REJECT_UNAUTHORIZED) which I cannot move to my configmap. I mean - app accepts them only from "env", not from configmap.
I'm curious why? Is there a chance that "env" and envFrom/configMapRef injected on different stages of pod creation?

does anyone know how to set envFrom of config.yaml like this:

apiVersion: v1
kind: ConfigMap
metadata:
  name: conf-1

data:
  config.yaml: |
    hello: config-map3
    key1: value1

does anyone know how to set envFrom of config.yaml like this:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables

does anyone know how to set envFrom of config.yaml like this:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/#configure-all-key-value-pairs-in-a-configmap-as-container-environment-variables

this doc just talk about <ConfigMap containing "multiple key-value pairs".>
like :

data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

, but what i want is

data:
  config.yaml: | 
    hello: config-map3
    key1: value1

the doc doesn't work with config.yaml's format

I'm not sure what exactly you want.
Do you want to use a config map to store the yaml as is?
Or do you want to create a config map that contains the key value pairs from an existing yaml?

I'm not sure what exactly you want.
Do you want to use a config map to store the yaml as is?
Or do you want to create a config map that contains the key value pairs from an existing yaml?

i want to expose all keys&values (like export key1=value1 and so on ... ) from my-conf'config.yaml as a pod's environment variables

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-conf

data:
  config.yaml: | # note this is a file 
    key1: value1
    key2: value2

### not this 
#data:
#  key1: value1
#  key2: value2

Well, if you wish to use envFrom, then

data:
  key1: value1
  key2: value2

will expose it as if you were doing export key1=value1 && export key2=value2.

Whereas:

data:
  config.yaml: | # note this is a file 
    key1: value1
    key2: value2

Is equivalent to export config.yaml=$(cat config.yaml) (if we ignore that env variables may not have a . in their name)

thk for ur explain, actually in my case with envFrom.configMapRef , only one env exist and its name is config.yaml , value is .yaml ,i seem to know about how configMapRef works

Never hot

Or for loading explicit values from a secret:

env:
- name: PASSWORD
  valueFrom:
    secretKeyRef:
      name: my-credentials
      key: password