Why won't it kustomize the node already visited

Question

I am using kubectl kustomizecommands to deploy multiple applications (parsers and receivers) with similar configurations and I'm having problems with the hierarchy of kustomization.yaml files (not understanding what's possible and what's not).

I run the kustomize command as follows from custom directory: $ kubectl kustomize overlay/pipeline/parsers/commercial/dev - this works fine, it produces expected output defined in the kustomization.yaml #1 as desired. What's not working is that it does NOT automatically execute the #2 kustomization, which is in the (already traversed) directory path 2 levels above. The #2 kustomization.yaml contains configMap creation that's common to all of the parser environments. I don't want to repeat those in every env. When I tried to refer to #1 from #2 I got an error about circular reference, yet it fails to run the config creation.

I have the following directory structure tree:

custom
├── base
|   ├── kustomization.yaml
│   ├── logstash-config.yaml
│   └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│   └── pipeline
│       ├── logstash-config.yaml
│       ├── parsers
│       │   ├── commercial
│       │   │   ├── dev
│       │   │   │   ├── dev-patches.yaml
│       │   │   │   ├── kustomization.yaml    <====== #1 this works
│       │   │   │   ├── logstash-config.yaml
│       │   │   │   └── parser-config.yaml
│       │   │   ├── prod
│       │   │   ├── stage
│       │   ├── kustomization.yaml  <============= #2 why won't this run automatically?
│       │   ├── logstash-config.yaml
│       │   ├── parser-config.yaml
│

Here is my #1 kustomization.yaml:

bases:
- ../../../../../base
namePrefix: dev-
commonLabels:
  app: "ls-7.8-logstash"
  chart: "logstash"
  heritage: "Helm"
  release: "ls-7.8"

patchesStrategicMerge:
- dev-patches.yaml

And here is my #2 kustomization.yaml file:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
# generate a ConfigMap named my-generated-configmap-<some-hash> where each file
# in the list appears as a data entry (keyed by base filename).
- name: logstashpipeline-parser
  behavior: create
  files:
  - parser-config.yaml
- name: logstashconfig
  behavior: create
  files:
  - logstash-config.yaml

I should add that running #2 kustomization directly on its own works just fine. — JamesD, Aug 03 '20 at 17:57
To be clear, the #2 `kustomization.yaml` is being ignored, right? — Wytrzymały Wiktor, Aug 04 '20 at 09:00
OhHiMark - yes, that's correct. I know it 'visits' that node, but it's not creating the config files that are in that #2 kustomize.yaml — JamesD, Aug 04 '20 at 14:43

score 1 · Accepted Answer · answered Aug 05 '20 at 11:34

The issue lays within your structure. Each entry in base should resolve to a directory containing one kustomization.yaml file. The same goes with overlay. Now, I think it would be easier to explain on an example (I will use $ to show what goes where):

├── base $1
│   ├── deployment.yaml
│   ├── kustomization.yaml $1
│   └── service.yaml
└── overlays
    ├── dev $2
    │   ├── kustomization.yaml $2
    │   └── patch.yaml
    ├── prod #3
    │   ├── kustomization.yaml $3
    │   └── patch.yaml
    └── staging #4
        ├── kustomization.yaml $4
        └── patch.yaml

Every entry resolves to it's corresponding kustomization.yaml file. Base $1 resolves to kustomization.yaml $1, dev $2 to kustomization.yaml $2 and so on.

However in your use case:

├── base $1
|   ├── kustomization.yaml $1
│   ├── logstash-config.yaml
│   └── successful-vanilla-ls7.8.yaml
├── install_notes.txt
├── overlay
│   └── pipeline
│       ├── logstash-config.yaml
│       ├── parsers
│       │   ├── commercial
│       │   │   ├── dev $2
│       │   │   │   ├── dev-patches.yaml
│       │   │   │   ├── kustomization.yaml $2 
│       │   │   │   ├── logstash-config.yaml
│       │   │   │   └── parser-config.yaml
│       │   │   ├── prod $3
│       │   │   ├── stage $4
│       │   ├── kustomization.yaml $???
│       │   ├── logstash-config.yaml
│       │   ├── parser-config.yaml
│

Nothing resolves to your second kustomization.yaml.

So to make it work you should put those files separately under each environment. Below you can find sources with some more examples showing how the tipical directory structure should look like:

That's helpful - need to study it to wrap my mind around it.... but I'm starting to see my folly. — JamesD, Aug 05 '20 at 14:38
I was not aware of the "Components" that promote the Composition model. I did notice reading that section that by default the kustomize solution favors inheritance model which I was trying to implement but couldn't. Is there an example of simple inheritance model, which I feel may fit our needs? — JamesD, Aug 05 '20 at 15:11
My only other twist with inheritance is that I need to have at least a three tier structure with variants at each level: i.e. logstash base > logstash parser common configs > logstash parser dev unique settings. To me that structure represents inheritance, I just don't know how to achieve that setup. — JamesD, Aug 05 '20 at 15:22
@JamesD I think it would be best if we address your concerns in a separate question to avoid mixing topics. Here you asked why your structure doesn't work and we have covered that. Let's close this topic and open a new one where you could describe what exactly you want to achieve. It will be easier and more clear for you and rest of the community that want to help you out. — Wytrzymały Wiktor, Aug 06 '20 at 13:14

Why won't it kustomize the node already visited

1 Answers1