Kustomize: base -- or -- include

Created on 13 Sep 2018 · 13Comments · Source: kubernetes-sigs/kustomize

i split kubernetes resources by a lots of dirs which contains kustomization.yaml.
every time we upgrade image tags, we have to modify several kustomization.yaml files just for imagetag.
so, can all kustomization.yaml include one special file just maintain the image tags for whole kubernetes environment?

In a word, i want "include" directive just like nginx, apache, sysctl.conf etc.
If not impractical, just for image tag batch modify, have any suggestions?
thanks.

lifecyclrotten

Source

liuhuiping2013

👍9

Most helpful comment

I agree with @khrisrichardson that an option to inherit things like namespace and commonLabels would help avoid duplication and the eventual out-of-sync issues that will occur. This is especially important because the answer from the Kustomize maintainers to questions about edge cases is almost universally "this can be accomplished with a more sophisticated layout."

larslevie on 11 May 2019

👍4

All 13 comments

Do you use the base overlay workflow? If you mean adding imagetags in multiple overlays, you can do that in base instead.

Liujingfang1 on 13 Sep 2018

something i forget is, deployment image registry in overlays diff from base. just like:

base: registry1/usersvc:0.1-rc
overlyas/alpha: registry2/usersvc:0.1

so, imagetag for registry2 appear in base have no effect.

liuhuiping2013 on 14 Sep 2018

👍1

I've encountered this myself, and had expected that the base attributes (common labels, image tags, namespaces) would be inherited in the overlay's resources, which is not the case. The need to duplicate the data in complex layouts makes me wonder whether or not there ought to be an option to inherit the base attributes in the overlay, with anything explicitly set in the overlay taking precedence.

khrisrichardson on 18 Sep 2018

👍1

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 25 Apr 2019

larslevie on 11 May 2019

👍4

/remove-lifecycle stale

thecopy on 20 May 2019

This is also an issue for us. We would like to have a kustomize.yml at the root of our repo containing common labels like git-repository, project-name etc.

thecopy on 20 May 2019

Agree on this - would love commonLabels (even commonAnnotations perhaps) to get merged here.

There's an awful lot of duplication we have in place at the moment.

nabadger on 16 Jul 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 14 Oct 2019

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot on 13 Nov 2019

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot on 13 Dec 2019

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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-ci-robot on 13 Dec 2019

I don't know what the purpose of having a base kustomization.yaml file is if nothing actually gets inherited? I'm having to duplicate pretty much everything into all my kustomization files.

If I didn't want commonLabels, namespace and images to be propagated I simply wouldn't put them in base. Or if I wanted them in half my resources but not the other half, I could do that with multiple bases.