Score:1

Server

How to expose image names to pod for use a version tag? Kubernetes

Tim Richardson

10/28/23, 8:35 PM

Is there an easy way to use container image name or tag as a ENV variable so that I can use it to provide the image name and tag in a pod (for version information). I am new user. This idea is to work-around my lack of knowledge in how kustomization.yaml can source "variables" from a config-map.yaml

Currently I set up an environment variable which I envsubt into kustomization.yaml, and from there I use that value twice: once for the image name change, and once to make a config map.

The actual objective is to enter this one piece of information only once, and have it be used in those two ways. If the image name was available to the container via the environment, that is one way since I would not need to inject the string into a config map to fill the container env; I could deduce it from the image metadata and therefore enter the value only once in kustomize, in the image name replacement. This would meet my objective, although it is not a general solution, it is a workaround specifically related to assuming image name metadata is available for free in the container. But this is not possible.

So another way is to template kustomization.yaml, which is what I have done: this is my current workaround. The philosophy of kustomize is no templating. However, avoiding duplicate entry of key literals is a higher priority for me.

In each "site" folder, I have something like this:

file: kustomization_pre_subst.yaml



resources:
  - site-namespace.yaml
  - site-config-map.yaml
  - site-secret.yaml
  - site-ingress.yaml
  - ../base
namespace: test


images:
  - name: django_api_sync-image
    newName: "...dkr.ecr.aws.com/django_api_sync:image_prefix-${version}"

configMapGenerator:
- name: version-configmap
  literals:
  - django_api_sync_version="${version}"

So I have a configmap just with the version string. In the base file this is used as part of the environment.

... fragment from a container spec:

  envFrom:
    - configMapRef:
        name: site-configmap
    - configMapRef:
        name: common-configmap
    - configMapRef:
        name: version-configmap
    - secretRef:
        name: common-secret
    - secretRef:
        name: site-secret

This so far is the easiest solution that I can understand which lets me define the version string once, and have it select the image I want, and be passed to the container in env.

What I was hoping for is that I could instead define it literally in the site-configmap and then used this to provide the correct image name, that is, use the site-configmap as a source for kustomization.yaml rather than having to inject it like this.

pseudo code fragment of kustomization.yaml showing how it can source from a config-map (instead of injecting into a config map), like:

images:
  - name: django_api_sync-image
    newName: "...dkr.ecr.aws.com/django_api_sync:image_prefix-${version}"
    env:
        source-from: site-configmap
        name: version
        key: version

The point of the being that the version needs to defined only once. However, even then it won't be as nice as doing envsubst.

I am surely missing something.

668

1 + 4

kubernetes

mdaniel

10/29/23, 2:11 AM

It appears that `spec.containers[0].image` isn't one of the ones [exposed by the downwardAPI](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/#downwardapi-fieldRef); would you be able to set a `label` or `annotation` with that information?

Tim Richardson

10/29/23, 2:16 AM

The real "problem" is that I want to publish a version string for the front end. The version is also part of the image name. Right now, I have the version as a config map string, and then I again update kustomization.yaml to provide the image name. And worse, my ansible build script also needs to know the version. There are "templatey" ways of doing which would take a minute but I hoping there is a "better" way (native kustomize or kubernetes).

mdaniel

10/29/23, 5:28 PM

*Right now, I have the version as a config map string, and then I again update kustomization.yaml to provide the image name.* well, then that sounds like your problem is already solved since kustomize can for sure inject env-vars from a ConfigMap, as can Deployments natively via `envFrom:`. Since your question is basically 2 sentences, we can only speak in generalities. Maybe edit your question to show a "hello world" of your kustomize setup?

Tim Richardson

10/29/23, 7:28 PM

I have tried to explain better.

Score:1

Server

mdaniel

10/29/23, 9:57 PM

As best I can tell, kustomize believes that replacements: are the future of that process and I just tried it with the example below and "it works on my machine" (kubectl kustomize . with v1.25.3)

In this scenario, I went from the Pod's image: out to the ConfigMap because kustomize is good at decomposing things (that is, splitting the tag from the repository) but joining them seemed like a lot more work. It's like all things in software, there's likely several ways to accomplish this, each with their own tradeoffs

Given

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: version-configmap
data:
  something-else: showing that we can append keys

# pod.yaml <-- just using it to make the example less verbose
apiVersion: v1
kind: Pod
metadata:
  name: the-pod
spec:
  containers:
  - image: example.com:3.14.15
    name: the-container

# kustomization.yaml
namespace: test
resources:
  - configmap.yaml
  - pod.yaml
replacements:
- source:
    kind: Pod
    name: the-pod
    fieldPath: spec.containers.0.image
    options:
      delimiter: ":"
      index: 1
  targets:
  - select:
      kind: ConfigMap
      name: version-configmap
    fieldPaths:
      - data.django_api_sync_version
    options:
      create: true

Produces

apiVersion: v1
data:
  django_api_sync_version: 3.14.15
  something-else: showing that we can append keys
kind: ConfigMap
metadata:
  name: version-configmap
  namespace: test
---
apiVersion: v1
kind: Pod
metadata:
  name: the-pod
  namespace: test
spec:
  containers:
  - image: example.com:3.14.15
    name: the-container

+ 2

Tim Richardson

10/30/23, 7:09 AM

thanks for an interesting answer. I think you have made replacements a lot more understandable.

Tim Richardson

11/1/23, 3:54 AM

I have used replacements to rewrite ingress host name based on a configmap entry, very handy, thanks again.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: How to expose image names to pod for use a version tag? Kubernetes

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.