Using configmap as environment value - when to use the list operator '-'

Lab Support
#1

Under application lifecycle module for the CKA course

I have completed the lab for practicing using configmaps for env. Looking at the docs on kubernetes.io the envFrom: is used without a ‘-’ but in the lab, it is required. I’m attempting to understand why. The ‘-’ should indicate a list if I am correct.

Kubernetes.io doc example:

apiVersion: v1
kind: Pod
metadata:
  name: env-configmap
spec:
  containers:
  - name: envars-test-container
    image: nginx
    env:
    - name: CONFIGMAP_USERNAME
      valueFrom:
        configMapKeyRef:
          name: myconfigmap
          key: username

Lab Example:

apiVersion: v1
kind: Pod
metadata:
labels:
name: webapp-color
name: webapp-color
namespace: default
spec:
containers:

  • env:
    • name: APP_COLOR
      valueFrom:
      configMapKeyRef:
      name: webapp-config-map
      key: APP_COLOR
      image: kodekloud/webapp-color
      name: webapp-color
#2

Hi @rehdwolfe

The ‘-’ should indicate a list if I am correct.

Yes, you are correct the - in a YAML indicates its a list.

Coming to the difference between env and envFrom. Both are lists. env is a list of Env Variables, and envFrom is a list of ConfigMaps defined by - configMapRef .

The main difference between these two is how do you need to use the EnvVAriables in you containers.
with env you can name the Env Vars as required in you containers using the .env.name.

The env block allows you to specify environment variables explicitly, naming them as you wish. This provides flexibility in how you reference these variables within your application. For example, if you have a ConfigMap that contains a key like DB_PASS, you can choose to expose it as DB_PASSWORD for one pod and as DATABASE_PASSWORD for another. This means you can tailor the variable names to fit the specific requirements of each container

In contrast, the envFrom block is used to import all key-value pairs from a ConfigMap or Secret directly into the container’s environment. This means that if your ConfigMap contains a key like DB_PASS, it will be available in the container with the same name. While this method is more straightforward for importing multiple variables at once, it lacks the flexibility of renaming or selectively choosing which variables to expose.

For more on this you can refer to Kubernetes docs here.

Hope this helps.

#3

Thanks for the response.

What was throwing me was the use of ‘-’ in the lab solution and the non-use of ‘-’ preceding env in the kubernetes doc. I was messing with the AI bot and it seems that the first element of a container definition will be preceded by ‘-’ even if the object itself is not a list.

image
image545×639 65.4 KB

kind Pod

#4

The YAML image you have posted, is it from the solution tab?

If yes, can you please share the URL of the lab ?

#5

Sure thing:

https://learn.kodekloud.com/user/courses/cka-certification-course-certified-kubernetes-administrator/module/2ddcf79b-abb0-4aeb-ad0c-3d54c7b4fc64/lesson/10eca8cd-5c55-4dbf-83a5-4a67a46de080

Seems the AI explanation is correct. The first element of the containers field is a list so it gets a ‘-’ regardless if the first object isn’t a list. ENV is a property but because its the first line in the container definition it gets the list operator. I was able to repeat the lab where I put env farther down the line and it worked. I wanted to make sure on the exam I could use the docs appropriately.

#6

Yes, As you can see the container.name and containers.image are moved down. Which affects readability, but it’s a valid one.

#7

containers is a list of objects. The keys within the container object may be in any order, so

containers:
- name: abc
  image: nginx

is the same as

containers:
- image: nginx  
  name: abc

Please also read this