Kustomize: Parse variables in ConfigMaps

[michalschott]

kustomize 1.0.11

Trying to deploy nginx-ingress-controller with kustomize, I'm facing an issue where I need to be able to dynamically inject namespace name to ConfigMap.

I've tried this:
[REDACTED]

kustomization.yaml

---
namespace: test

vars:
  - name: NGINX-INGRESS-NAMESPACE
    objref:
      kind: Deployment
      name: nginx-ingress-controller
      apiVersion: extensions/v1beta1
    fieldref:
      fieldpath: metadata.namespace

configmapGenerator:
  - name: nginx-ingress-controller
    literals:
      - add-headers=$(NGINX-INGRESS-NAMESPACE)/nginx-ingress-add-headers

Output is:

apiVersion: v1
data:
  add-headers: $(NGINX-INGRESS-NAMESPACE)/nginx-ingress-add-headers
kind: ConfigMap
metadata:
  labels:
    app: nginx-ingress
  name: nginx-ingress-controller-h7f44dhftc
  namespace: test

Adding regular ConfigMap.yaml file to resources gives similar output.

[Liujingfang1]

duplicate as #682

[gysel]

Can you please reopen this bug? I just tested it with a version based on e1420b408c4e20d063433034ca67803c99e5ad40 and the var is still not replaced.

File kustomization.yaml

resources:
- a-deployment.yaml

namespace: bug-demo

vars:
  - name: NAMESPACE
    objref:
      kind: Deployment
      name: my-deployment
      apiVersion: extensions/v1beta1
    fieldref:
      fieldpath: metadata.namespace

configMapGenerator:
- name: variable-demo
  literals:
    - namespace=the namespace is $(NAMESPACE)

File a-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    component: my-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: my-deployment
  template:
    metadata:
      labels:
        component: my-deployment
    spec:
      containers:
        - name: a-container
          image: image

Current output is:

apiVersion: v1
data:
  namespace: the namespace is $(NAMESPACE)
kind: ConfigMap
metadata:
  name: variable-demo-2c2b2d7677
  namespace: bug-demo
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  labels:
    component: my-deployment
  name: my-deployment
  namespace: bug-demo
spec:
  replicas: 1
  selector:
    matchLabels:
      component: my-deployment
  template:
    metadata:
      labels:
        component: my-deployment
    spec:
      containers:
      - image: image
        name: a-container

Expected output is:

apiVersion: v1
data:
  namespace: the namespace is bug-demo
kind: ConfigMap
metadata:
  name: variable-demo-2c2b2d7677
  namespace: bug-demo
# shortened here

[Liujingfang1]

@gysel We don't add ConfigMap to the default vars transformer configurations since we don't think it's the best practices. However, supporting vars in a map field has been solved. For you use case, you can support it by using a custom configuration. First create a base with kustomization.yaml as

configurations:
- varconfig.yaml

where varconfig.yaml has following content

varReference:
- path: data
  kind: ConfigMap

Then include this base in your kustomization.yaml.

[gysel]

Thanks, that worked! I was able to inject the namespace into a config file and get rid of an ugly hack.

I agree that this feature not be active by default - but is it documented somewhere?

[jonathanunderwood]

We don't add ConfigMap to the default vars transformer configurations since we don't think it's the best practices.

@lichuqiang am curious why this is considered bad practice? What should one do instead as best practice? Not challenging the assertion, just trying to educate myself.

[amazingandyyy]

@Liujingfang1 Hi, I have same question, why this is considered bad practice? What should one do instead as best practice? Not challenging the assertion, just trying to educate myself.