How to override images stanza from base in any overlay?

[pentago]

I'm figuring out a gitops workflow and want to know if it's possible to define a set of images in the base but to be able to override those images in any or all overlays, like this:

base:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - deployment.yaml

images:
  - name: BACKEND_IMAGE
    newName: ghcr.io/user/backend
    newTag: wwwwwww
  - name: FRONTEND_IMAGE
    newName: ghcr.io/user/frontend
    newTag: xxxxxxx

dev overlay:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

images:
  - name: BACKEND_IMAGE
    newName: ghcr.io/user/backend
    newTag: yyyyyyy
  - name: FRONTEND_IMAGE
    newName: ghcr.io/user/frontend
    newTag: zzzzzzz

Currently, it's possible to have different images stanzas in each overlay but it must not be present already in the base. Not sure why is that but wouldn’t it be useful to be able to override images stanza from the base in any overlay too?

[k8s-ci-robot]

@pentago: This issue is currently awaiting triage.

SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[pentago]

/remove-lifecycle rotten

[annasong20]

I'm not quite sure what your setup is and how you want kustomize to behave differently. To the best of my understanding, your setup is:

./base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  template:
    spec:
      containers:
      - name: backend
        image: BACKEND_IMAGE:8
      - name: frontend
        image: FRONTEND_IMAGE:1.7.9

./base/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - deployment.yaml
images:
  - name: BACKEND_IMAGE
    newName: ghcr.io/user/backend
    newTag: wwwwwww
  - name: FRONTEND_IMAGE
    newName: ghcr.io/user/frontend
    newTag: xxxxxxx

./overlay/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base
images:
  - name: BACKEND_IMAGE
    newName: ghcr.io/user/backend
    newTag: yyyyyyy
  - name: FRONTEND_IMAGE
    newName: ghcr.io/user/frontend
    newTag: zzzzzzz

for which I get the following output using kustomize v4.5.7

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  template:
    spec:
      containers:
      - image: ghcr.io/user/backend:wwwwwww
        name: backend
      - image: ghcr.io/user/frontend:xxxxxxx
        name: frontend

I believe this is the expected output because by the time you reference base with overlay, you've already changed the names of the images from BACKEND_IMAGE and FRONTEND_IMAGE to ghcr.io/user/backend and ghcr.io/user/frontend, respectively. The overlay kustomization will not find any images with the names you specify, and thus we see the output of base.

[annasong20]

If you want kustomize to further modify the tags in overlay, you can change overlay/kustomization.yaml to specify the new names in the base as follows:

overlay/kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../base
images:
  - name: ghcr.io/user/backend
    newTag: yyyyyyy
  - name: ghcr.io/user/frontend
    newTag: zzzzzzz

and your output will be

apiVersion: apps/v1
kind: Deployment
metadata:
  name: the-deployment
spec:
  template:
    spec:
      containers:
      - image: ghcr.io/user/backend:yyyyyyy
        name: backend
      - image: ghcr.io/user/frontend:zzzzzzz
        name: frontend

If I'm misinterpreting your question, please provide more information including all inputs, expected output, and actual output.

[natasha41575]

/kind support /triage resolved

If @annasong20's response doesn't resolve your issue, please reopen with more details.

[argarinpauljohn]

/reopen

[k8s-ci-robot]

@argarinpauljohn: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[argarinpauljohn]

I've encountered the same problem. This time, the scenario is I'm creating an overlay for an overlay. Image stanza cannot be replaced unless it's not specified in the base overlay.

[annasong20]

@argarinpauljohn The behavior you're describing sounds identical to that seen in this issue, just 1 layer above. If so, I believe this is intended behavior rather than a bug.

If my responses above don't help, I'd recommend asking in the Slack channel. If you believe the observed behavior wrong, please file a new bug with a comprehensive description and example.