0

I'm currently trying to create a job in Kubernetes in a project I've just joined.

This job should wait until 2 other pods are up and running, then run a .sh script to create some data for the testers in the application.

I've figured out i should use initContainers. However, there is one point i don't understand.

Why should i include some environmental values under env tag under initContainers in job description .yaml file ?

I thought i was just waiting for the pods to be initialised, not creating them again. Am i missing something ?

Thanks in advance.

Emre Acar
  • 920
  • 9
  • 24

1 Answers1

2

initContainers are like containers running in the Pod, but executed before the ones defined in the spec key containers.

Like containers, they share some namespaces and IPC, so it means that the Scheduler will check if the declared initContainers are successful, then it will schedule the containers.

Keep in mind that when you create a Pod, basically, you're creating an empty container named pause that will provide a namespace-base for the following containers: so, in the end, the initContainer is not really creating again a new Pod, like its name suggests, it's an initializer.

prometherion
  • 2,119
  • 11
  • 22
  • OK, thank you so much for your detailed answer, i understand pods better. However, my main question is still unanswered - why do i need to specify env values, if the scheduler will see the existing container anyways ? Am i overriding the existing ones ? – Emre Acar Sep 06 '19 at 07:19
  • Containers are processes and they have their own ENV variables, this mean that each container got its list of variables. Nothing is shared so you have to declare twice or more – prometherion Sep 06 '19 at 11:18
  • So even if i'm not recreating them, and just waiting for them to be up under initContainers, i still have to specify those env values, right ? – Emre Acar Sep 06 '19 at 11:19
  • 1
    It depends if they're needed or not: most apps rely on ENV cars but they're not mandatory – prometherion Sep 06 '19 at 12:02
  • To avoid duplication one can define the shared ENVs into a *configMap* and import it via `envFrom.configMapRef` in both `initContainers` and `containers`. – Kamafeather Aug 16 '21 at 12:31