Matthew Booth
Matthew Booth

Reputation: 131

Kustomize: how to apply the same patch in multiple overlays without LoadRestrictionsNone

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

Answers (1)

Matthew Booth
Matthew Booth

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

Related Questions