Kustomize: vars not applying correctly according to documentation

Created on 10 Feb 2020  路  4Comments  路  Source: kubernetes-sigs/kustomize

The documentation of vars suggests that any instance of a variable in an object will be replaced

    // Vars allow things modified by kustomize to be injected into a
    // kubernetes object specification. A var is a name (e.g. FOO) associated
    // with a field in a specific resource instance.  The field must
    // contain a value of type string/bool/int/float, and defaults to the name field
    // of the instance.  Any appearance of "$(FOO)" in the object
    // spec will be replaced at kustomize build time, after the final
    // value of the specified field has been determined.

however this is not accurate. Considering the following file: (removed unnecessary bits)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: manager
  labels:
    app: $(SERVICE_ACCOUNT_NAME)
spec:
  template:
    spec:
      serviceAccountName: $(SERVICE_ACCOUNT_NAME)

yields the following output:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: prefix-manager
spec:
  template:
    spec:
      serviceAccountName: $(SERVICE_ACCOUNT_NAME)

Above shows that the app label was properly replaced however the serviceAccountName was not properly replaced.

kustomize version:
{Version:kustomize/v3.5.3 GitCommit:5ba90fe5ef1dc4599e359edd41d1d0e6373b247d BuildDate:2019-12-17T21:57:37Z GoOs:linux GoArch:amd64}

This is also a problem with ClusterRoleBinding subjects for me as well.

Most helpful comment

@drekle, @govinda-attal Vars are not supported for arbitrary fields. There is a default of fields where a var can be replaced. The metadata.labels is in that default list. To make other field work, you can add them in kustomization.yaml.

# kustomization.yaml
configurations:
- config.yaml

# config.yaml
varReference:
- path: spec/template/spec/serviceAccountName
   kind: Deployment

You can read more on the transformer configurations.

All 4 comments

Same we are facing same issue and are currently using kustomize version 3.5.4.

We would like to use kustomize to hydrate resources which will later be used to provision GCP resources.
With our observation, it looks like variable substitution works only for labels and annotations but not inside spec.

patch-partial.yaml

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/remove-default-node-pool: "true"
    location: $(LOCATION)
  labels:
    location: $(LOCATION)
  name: dummy
spec:
  initialNodeCount: 1
  location: $(LOCATION)

Currently kustomize build results in:

apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/remove-default-node-pool: "true"
    location: australia-southeast1
  labels:
    location: australia-southeast1
  name: xxx
  namespace: xxxx
spec:
  initialNodeCount: 1
  location: $(LOCATION)

Also, we have cases where we would like to have variable substitution as:

subnetworkRef:
    external: projects/$(HOST_PROJECT)/regions/$(LOCATION)/subnetworks/$(SUB-NET-ID)

@drekle, @govinda-attal Vars are not supported for arbitrary fields. There is a default of fields where a var can be replaced. The metadata.labels is in that default list. To make other field work, you can add them in kustomization.yaml.

# kustomization.yaml
configurations:
- config.yaml

# config.yaml
varReference:
- path: spec/template/spec/serviceAccountName
   kind: Deployment

You can read more on the transformer configurations.

Many thanks @Liujingfang1, works like a charm :-)

Only intended to highlight an issue with the documentation. I believe this part of documentation may be misleading:

https://github.com/kubernetes-sigs/kustomize/blob/master/api/types/kustomization.go#L61

Any appearance of "$(FOO)" in the object
    // spec will be replaced at kustomize build time

however I do not know enough about how this works to make a PR on the docs.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

TechnicalMercenary picture TechnicalMercenary  路  3Comments

Liujingfang1 picture Liujingfang1  路  6Comments

nabadger picture nabadger  路  4Comments

karlmutch picture karlmutch  路  5Comments

surki picture surki  路  4Comments