Reputation: 131
I have a kustomize layout something like this:
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]
│ common_cluster_patch.yaml
└──TestVariantB
└──kustomization.yaml; resources=[VariantB]
common_cluster_patch.yaml
My issue is the duplication of common_cluster_patch.yaml
. It is a common patch which I need to apply to the the different base cluster objects. I would prefer not to have to maintain identical copies of it for each test variant.
The 2 unsuccessful solutions I tried are:
A common patch resource
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA, TestPatch]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB, TestPatch]
└──TestPatch
└──kustomization.yaml
common_cluster_patch.yaml
This fails with no matches for Id Cluster...
, presumably because TestPatch is trying to patch an object it doesn't contain.
A common patch directory
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]; patches=[../TestPatch/common_cluster_patch.yaml]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB]; patches=[../TestPatch/common_cluster_patch.yaml]
└──TestPatch
└──common_cluster_patch.yaml
This fails with: '/path/to/test/TestPatch/common_cluster_patch.yaml' is not in or below '/path/to/test/TestVariantA'
.
I can work round this and successfully generate my templates with kustomize build --load-restrictor LoadRestrictionsNone
, but this comes with dire warnings and portents. I am hoping that there is some better way of organising my resources which doesn't require either workarounds or duplication.
Upvotes: 1
Views: 5583
Reputation: 131
Thanks to criztovyl for this answer! The solution is kustomize components. Components are currently only defined in kustomize.config.k8s.io/v1alpha1
and the reference documentation is a stub, but they are included in current release versions of kustomize.
My solution now looks like:
├──release
│ ├──VariantA
│ │ └──kustomization.yaml
│ │ cluster_a.yaml
| └──VariantB
│ └──kustomization.yaml
│ cluster_b.yaml
└──test
├──TestVariantA
│ └──kustomization.yaml; resources=[VariantA]; components=[../TestCommon]
├──TestVariantB
│ └──kustomization.yaml; resources=[VariantB]; components=[../TestCommon]
└──TestCommon
└──kustomization.yaml; patches=[common_cluster_patch.yaml]
common_cluster_patch.yaml
where test/TestCommon/kustomization.yaml
has the header:
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
The crucial difference between a component and a resource is that a component is applied after other processing. This means it can patch an object in the resource which included it.
Upvotes: 3